Forum Moderators: coopster
Passwords stored in md5 can't be converted back into their original form can they?
If this is the case, how do I give the user a password reminder, or will I have to make some script that allows the user to change the password themselves?
W.
Alternate option is to add a field called reminder and let them enter a key word(s) that they can have sent to them to jog their memory.
You really shouldn't let users change their own passwords UNLESS they login with the current password. Otherwise your security is a moot point.
There -is- a way to "decode" the hash back into what it was before, but it's a nasty piece of code.
There's a 10,000 dollar prize being offered to anyone develop a method for finding collisions in md5 (not the same as decoding, of course, but it's still considered a strong one-way hash as far as I know).
I thought that brute force attacks were the only real way to get at md5 hashes.
The decode section can be found in the validate password section - it's not that bad really.
I couldn't find the decode section. All I could find is where you take a password in plain text, do an md5 hash and compare it to another md5 hash.
Thanks for advice, I will sort it now.
W.
For more info on md5 collisions and the $10K prize, see
[md5crk.com...]
[rsasecurity.com...]
A strongly collision-free hash function H is one for which it is computationally infeasible to find any two messages x and y such that H(x) = H(y).
Fundamentally, this is the same problem as finding a message x that will result in a message digest hash y, such that H(x) = y, in the case where you don't know what message was used to create y.
AFAIK most md5 attacks are brute force - just start checking keys. Since most passwords will only be say 4-10 chars and will be alpha-numeric plus underscores, I guess that would allow something like
37^4 + 37^5 + 37^6 ... + 37^10
possibilities.
Tom
All I could find is where you take a password in plain text, do an md5 hash and compare it to another md5 hash.
Spot on ergophobe.... boy do I have bad aim when I try to shoot from the hip. Sorry folks. :o
However, a brute force attact with a password that requires 6 characters, alphanumeric, case sensitive, would require billions of attempts.
What kind of security to offer depends upon what is being protected. It has been said that anyone with a few hundred thousand dollars to spend could break codes similar to MD5 and others. For many things that is not enough security. However, if you were trying to break into my bank account you would be a loser :-)
Who created the wonderful md5? Or was it created such that nobody knows how the transformation works?
W.
Hmm... only 10000, If a sitation arose where I somehow got a rich guy's bank card, and also worked in a bank (quite convenient) - Could I not just try the card out like 20 times a day. A maximum of 10 weeks later you win.
If you are using the physical card, after the first 3 or 4 attempts the card is swallowed and canceled. Using other methods a few errors in entering the PIN will cause the account to be frozen and security to be notified.
But if you have complete control of a computer program, (for example, if you have the hash on your computer and can run many attempts to find a collision) you will quickly find it with a four number PIN, but will have much more difficulty with an 8 character case sensitive alphanumeric password.
All of this is based on brute force attacts, that is, just entering one number after another. It doesn't matter what method of encryption you use, brute force will take, at most, 10,000 attempts to find a collision with a 4 digit pin.
With long alphanumeric passwords brute force is not practicable, and other methods must be used. This is where the difference between MD5, less secure methods, and more secure methods, matter.
W.
depends upon the length of the password.
It depends on
1. the length of the password
2. the number of allowable characters
3. whether or not the password can be variable in length
That's what I was driving at with this
37^4 + 37^5 + 37^6 ... + 37^10
In fact, if you make passwords case sensitive and allow "word characters" (letters, numbers and underscore) and allow any length between 4 and 10 chars, then you get:
63^4 + 63^5 + 63^6 ... 63^10.
That's a LOT of combos to crack. Of course, if you password happens to be "admin" it's likely to go in the first minute.
Tom
It depends on 1. the length of the password
2. the number of allowable characters 3. whether or not the password can be variable in length
Exactly. That's how I computed the "billions" I referred to in an earlier post. I use one brokerage system that allows!@#$%^.... (shift number keys) and a minimum of eight characters (as well as case sensitive alpha and numbers. That will produce some large numbers. (722,204,136,308,736 if everyone used only eight characters. That's over 700 Trillion) They required that at least one lowercase, one uppercase, one number, and one symbol be in the password. A brute force attack on that would be unlikely. Only if there were a weakness in the encription algorithm could a hash be converted (or collision found).
Of course, if your password happens to be "admin" it's likely to go in the first minute.That's the problem. Anyone first attempting to break in would first use a "dictionary" attack in which a list of a thousand or so common passwords would be tried. And "admin" is high on the list. It's like the case where a new voice mail system was installed with the initial default PIN being the phone extension number. Someone guessed that the CEO would not quickly setup his mail box and change the PIN, with predictable results. ("hello, this is the chief ****; I don't want to talk to you, call someone less important you ****")
Another problem with long passwords is that people won't remember them and will write them down. The FDA cited a pharmaceutical plant when an inspector saw a pass word written on the desk next to a keyboard.
It is possible that a bank employee with access to the hash data could obtain a stolen ATM card, quickly on a home computer find a password that will work, and try to use it. The banks rely on the fact that there is not usually a large amount of money in the checking accounts (and a limit to the amount of money in any given ATM) and with the cameras there is a high probability that someone trying that will be caught.
A password like
ÃЦ\/¦¶Ñ
Will be REALLY HARD to decode.
(execept if a colision is made with a simpler pasword but the chances are really low.)
OK, I know, it's a twister game to type this on a keyboard...
Good reading: Cuckoo's Egg by Clifford Stoll. It's old (1980s), but it's the story of a guy tracking down a "student" hacking into the Lawrence Berkeley Labs computers. Turns out they were Germans working for the East German Stasi and they were gaining access to computers at nuclear labs around the country. The point of access? MITRE's national computer security center! How did they get into all of these computers? By logging in as "admin", "admin".
When Stoll called these labs to tell them they had intruders, their reaction was "We're secure and locked down. We don't have intruders."
Back to the original question.... I think the best way is to generate a random password that you send via email and then allow the user to use it to log in and change the password to some value he likes.
