MD5 Encryption Question

[Titan85]

I am using the md5 method of encrypting my passwords stored in my users database and it works fine and all, but I found an issue while trying to make an edit function for the passwords. Since the password is entered into the database as an md5 hash, when I echo it for editing, it show the hash. Is there any way to reverse the encryption to display the password as what it is?

[apollo]

Basically md5() is not reverible, the standard practice is to issue a new replacement password, rather than attempting to edit it! The user can edit the password by changing it!

More Info...
http://archives.devshed.com/forums/php-108/reverse-md5t-101197.html

[thetestingsite]

With md5, there is no decryption that is avalible. That is what makes md5 encryption so secure. At least what I am aware of. TYou could make two columns in the user table that has the md5 hash of the password as well as the plain text password, or you could use your own ecryption (not recommended).

Hope this helps.

EDIT: Sorry apollo, posted at the same time I guess.

[Titan85]

Thanks guys, I guess I'll have to figure another way of doing this.

[thetestingsite]

Well, the way I made some of my "somewhat secure" programs was by making the user type in the old password (as well as the new passwords and a confirmation of the new password) and compare against my database, if the username/password (md5 for the password) combination was correct, as well as the new password and confirm password were matching, I would update the mysql database.

Hope this helps.

EDIT: This is in the change password part of the "program", if not understood from first reading the entire post.

[Titan85]

Well, the way I made some of my "somewhat secure" programs was by making the user type in the old password (as well as the new passwords and a confirmation of the new password) and compare against my database, if the username/password (md5 for the password) combination was correct, as well as the new password and confirm password were matching, I would update the mysql database.

Hope this helps.

EDIT: This is in the change password part of the "program", if not understood from first reading the entire post.Thanks, thats basically all I really need to do :)

[Twey]

You could make two columns in the user table that has the md5 hash of the password as well as the plain text password... thus completely defeating the point of having the passwords hashed in the first place? :p

[boxxertrumps]

there's also the Prospect Of Adding another value to increase the security, like generating a hash value with the combined username and password.

So... Its twice As impossible To decrypt....

[Titan85]

there's also the Prospect Of Adding another value to increase the security, like generating a hash value with the combined username and password.

So... Its twice As impossible To decrypt....Yeah, I heard about that, but haven't tried it yet because for what I am doing, its kinda overkill :)

[alexjewell]

Yeah, that'd be overkill.
Go with thetestingsite's idea

[Twey]

It's hardly overkill when it's so easy to implement. I quite like the idea.

I'm toying with a couple of different possible security schemes at the moment: the first is graphical user authentication, in which the user picks a series of images in sequence (as described here (http://csrc.nist.gov/publications/nistir/nistir-7030.pdf) [PDF]), and the second is file authentication. File authentication involves uploading a whole file as identification. A file will, obviously, be much more secure than a password and practically impossible to guess: not only would a 1kb file (quite an acceptable size to upload even on a dialup connection) hold the equivalent of 1,024 ASCII characters, a small pass-essay, but each byte also needn't be in the ASCII range: anything between 0 and 255 is acceptable, allowing for (unless my mathematical ability has decayed completely) 256 ^ filesize possible combinations. Of course the file could be of a variable size, introducing even more combinations, but I'm not gifted enough to work that out without a lot of thought. :)

The disadvantage to passfiles, of course, is that each user must store the passfile somehow. However, a combination of passfile and password could be required, countering both guesswork and unauthorised access to an insecure medium, taken individually.

I really must see about getting that titanium bunker installed... :p

[Titan85]

was the suggested idea just to take the password and add some code to it, like $pass = (md5($_POST['password'] + 1234)); ? Or would it be more secure if it had random numbers added to it? If so, how would I go about adding random numbers? This would definitely be useful for some of my scripts that need more security.

[djr33]

Twey, that's interesting, but MANY users would have trouble creating such a file. One option would be to use a (small) image. That's kinda cool. Anyway, though, they could lose it and have problems.

Here's the solution to the question:
1. Store the md5 of the password.
2. To login, they type the pass, and compare the md5 of that to the has in DB.
3. To change pass, have 3 fields: old pass, newpass1, newpass2 (verification). Compare the md5 of the old pass to the database (to make sure it's ok to change), then they can enter new1 and new2. If they match, change it.

Note that no one ever wants to edit a password anyway. They want to change it. If your password was "123" no one would want to just decide to change it to "1234"... not smart or as secure as it could be, and... how many people would want to, anyway? Even if they did, they could just type it out... how long is a password going to be, anyway? 20 characters? Remember, they have to type it to log in anyway....

[Titan85]

Twey, that's interesting, but MANY users would have trouble creating such a file. One option would be to use a (small) image. That's kinda cool. Anyway, though, they could lose it and have problems.

Here's the solution to the question:
1. Store the md5 of the password.
2. To login, they type the pass, and compare the md5 of that to the has in DB.
3. To change pass, have 3 fields: old pass, newpass1, newpass2 (verification). Compare the md5 of the old pass to the database (to make sure it's ok to change), then they can enter new1 and new2. If they match, change it.

Note that no one ever wants to edit a password anyway. They want to change it. If your password was "123" no one would want to just decide to change it to "1234"... not smart or as secure as it could be, and... how many people would want to, anyway? Even if they did, they could just type it out... how long is a password going to be, anyway? 20 characters? Remember, they have to type it to log in anyway....Yeah, for the user cp, thats what I would have. The only reason that I wanted to edit it was so that I could have an option in the admin panel in case it was ever needed.

But, for a more secure login, would adding some numbers to the password make it more secure or no?

[Twey]

was the suggested idea just to take the password and add some code to it, like $pass = (md5($_POST['password'] + 1234)); ? Or would it be more secure if it had random numbers added to it?No, not random numbers. The only way you could compare a user-input password to it in that case is if you stored the random number in the database with it, which would defeat the point :p

You can concatenate it with a static, unguessable string, yes. That way an attacker would need to compromise both the script and the database before being able to brute-force your passwords.
Twey, that's interesting, but MANY users would have trouble creating such a file.No, there'd be no need to create a file. When creating an account, they simply upload a copy of any file, and the file is stored, or to save disk space, just a few bitsum hashes (SHA1, MD5, CRC32) and a filesize. The only thing that's then necessary is to remember which file was used, and make sure the same file is uploaded when logging in.
Anyway, though, they could lose it and have problems.Certainly, in which case they'd request a reset through the same avenues that are usually used if one has lost a password.

[djr33]

You shouldn't have access to their passwords. That's a security issue, because you could access anything else they use the password for. Yes, it's stupid, but most users don't have unique passwords for everything. And... you don't need to edit it. If nothing else, just do a random password like was suggested earlier. (If you want to know how to generate one with PHP, I wrote a script that will do it, and I could link to the thread.)

For a password, there are several factors that make it 'more' or 'less' 'secure'... all in quotes, because it's not secure, and only as secure as the weakest link. If you tell someone your password... that's the weakest link, etc.
1. Guessability (fun word, no?).... if it's obvious (like your username), or somewhat obvious (like a dictionary word), then that makes it easier to either: guess or find using a list of words (like a list of dictionary words), etc.
2. Length... a one character password means just checking 26 times. 2 chars is 26^2, X chars is 26^X, AND that just assumes 26 characters.. see below. Having tested brute force (just running through every possible combination) with PHP to see how fast it could run, I'd say anything under 5 chars is laughable, and quickly found with PHP. 6 chars can take a significant amount of time (dependds on the system... an hour? 2 days?) but nothing amazing. 7 gets to be a while, and 8 was up to a year or something. So, to be safe, use at least 8, and hopefully 10 characters.
Note also that variable lengths help.. it's easier to guess if you KNOW it's 8 characters, than if it was 8 or 7, or... etc. Though, not that the highest number of characters will take the longest and the next highest number only a fraction of that (like 1/26th, or 1/num_of_chars).
3. Characters used. If you just use the 26 lower case letters, it's easier to run through with brute force. Using all (er.. most of the) 256 possible characters is best, but at least try to use a number or capital letter or both. That drastically increases the time used (like 26^X vs. 46^X... try the math). Also, using a weird character like œß∂∆˚¬∑®† or ç, etc. can really be great because it's unexpected (though not secure, in itself).

If you have a long, random, and odd-character-containing password, you'll be fine.

so.. adding a couple numbers... not sure why you would be doing this, but, sure, could make it more secure. Numbers are better than just letters and length helps.
If you just mean for the database/hash, then that's not a bad idea because then the hash is unique, so if someone found it and tried to crack it (using brute force, or if there was a reverse algorithm found (there almost certainly won't be, though)), then they couldn't crack it because of not knowing about your extra code. Then again, they'd find "mypass1234" and "anotherpass1234" and know fairly quickly...
The best option here would be to simply encrypt it twice, perhaps with two different algorithms. But if they can undo it once, they could again... but it would take longer.


EDIT: Twey and I posted at the same time... might overlap some.

And, Twey, as for resetting it, it defeats the point of a more secure system because it would still have that as the weakest link.

[Twey]

And, Twey, as for resetting it, it defeats the point of a more secure system because it would still have that as the weakest link.Yes, but if somebody compromises the person's email account and then uses it to request a passfile reset, it's the email provider's problem, not mine ;)

Also, if using the password-and-passfile idea, it would be reasonable to require the person to provide one in order to reset the other. Beyond a set of likely circumstances, it's reasonable to require human intervention to reset a password; once this stage is reached, all sorts of new and interesting manual checks can be introduced, such as asking the person questions about their account usage, the answers to which haven't been sent to that email address. If you wanted to be really paranoid, you could refuse to allow them to reset their access details at all, and force them to create a new account, with the option of nuking the old one for additional security. This would protect whatever sensitive data was stored in that account, although at the cost of quite some inconvenience to the user.

It's obviously not unbreakable (nothing is), but logging in requires possessing one of the following pairs:Both the passfile and the password; the passfile and access to the user's email account; the password and access to the user's email account; access to the user's email account and detailed knowledge of the person's account usage.Of those, any requiring the email account to be broken first are officially not my problem.

As you said, even the best security can be compromised by a weak link in the chain; thus, all an individual provider can do is try damn hard not to be that weak point.

Another factor to be taken into account is detectability. Almost any account can be broken by sheer brute-force, although time may be required. However, someone launching password length ^ 52 failed requests one after the other (not including non-alphabetical characters) is very likely to be picked up by a competent network admin.

I should write up an implementation and have it thoroughly tested by usability and security experts. Perhaps when I have some more time.

[djr33]

Interesting. Seems like a hassle. Just protecting the password seems like the best idea, considering that's what even the most trusted sites do. Unless this is classified government stuff, or something, doesn't seem all that worth it. Typing a few characters takes long enough... locating your passfile is a pain. Also, having that file on hand, not in memory, is just as bad as a list of passwords sitting on the desktop.


"passlen^52".... nope. it's 52^passlen.

[Twey]

Seems like a hassle.Hardly. It might take slightly longer than a traditional password, yes, but it's not a crippling problem, I don't think. Like I said, I'd have to get it thoroughly tested to be sure.
Just protecting the password seems like the best idea, considering that's what even the most trusted sites do.It works, for the most part, yes, but I see no reason why the system shouldn't be improved when there's so great a benefit and so little a cost. You're right, though: it does puzzle me slightly that no-one else has done this, so I'm waiting for someone to come along and point out the gaping hole I've missed :p
Typing a few characters takes long enough... locating your passfile is a pain.Well, the passfile could be located somewhere very accessible; for example, I could type "/pass" in the file-selection box to access my (theoretical) 5kb passfile. The effort of entering five characters, with the security of entering more than five thousand. You're also forgetting form autocompleters.
Also, having that file on hand, not in memory, is just as bad as a list of passwords sitting on the desktop.Not quite. It's not possible (for most people) to memorise the contents of a binary passfile, for example; to gain access to the file and download (or upload) it would take no less effort than to install a keylogger to steal a normal password. This is still a crucial weak point, though, which is why I suggested it in combination with a traditional password.
"passlen^52".... nope. it's 52^passlen.Ah! Yes, my error. Sorry.

[djr33]

I'm waiting for someone to come along and point out the gaping hole I've missedI don't think there's a gaping hole... just that users are used to passwords. This will confuse and annoy them, take more time, and they'll just not bother. (Perhaps.) And if the file is lost, it's a hassle.


I could type "/pass" in the file-selection box to access my (theoretical) 5kb passfile. The effort of entering five characters, with the security of entering more than five thousand. You're also forgetting form autocompleters.To explain that to a beginner computer user would take forever. Imagine the help emails you'd get.


to gain access to the file and download (or upload) it would take no less effort than to install a keylogger to steal a normal password. No.... put in floppy. Drag. Drop. Take out floppy. Nothing to it.


No problem about the math... just wanted to mention it because you said you weren't sure.

[Twey]

No.... put in floppy. Drag. Drop. Take out floppy. Nothing to it.As opposed to insert floppy, double-click icon, take out floppy?
I don't think there's a gaping hole... just that users are used to passwords. This will confuse and annoy them, take more time, and they'll just not bother. (Perhaps.)Initially, yes, but that's just because it's a different idea. It's not intrinsically much more of a bother than a password.
And if the file is lost, it's a hassle.It needn't be any more of a hassle than a lost password, as I said above.
To explain that to a beginner computer user would take forever. Imagine the help emails you'd get.Well yes, but that sort of beginner probably types so slowly that finding the file by clicking the big "Browse..." button and pumping the mouse a bit would be faster than entering a password anyway :)

[djr33]

As opposed to insert floppy, double-click icon, take out floppy?Yes. You fail to mention the entire part about finding/buying/installing, setting up and using keystroke logging software. As well as knowing about it. Everyone knows how to copy a file to a floppy. How many people know about keystroke loggers?

[Twey]

There's plenty of freeware keylogger software out there, and I daresay that anybody capable of using a floppy these days knows about keyloggers.

[mburt]

Offtopic: TWEY SOUNDS BRITISH IN THAT POST
I pictured an old british movie were newfieland was just starting and the people from britain were deciding whether to come over and take a haul or not... LOL. Inside joke.
Sorry, I'm having a freakishly bold day.

[djr33]

You're wrong, Twey. I knew about floppies a long time before I had heard of keyloggers. Most casual computer users know how to use a floppy out of necessity. Not keyloggers.

[mburt]

^^ You Got Burned, Yo.

[Twey]

You're wrong, Twey. I knew about floppies a long time before I had heard of keyloggers. Most casual computer users know how to use a floppy out of necessity. Not keyloggers.And would those people be able to gain and abuse access to a logged-on local terminal or unencrypted hard drive of the user? Bearing in mind, of course, that with a normal password it's possible to shoulder-surf, and also that the passfile would be useless without access to the user's password and/or email inbox. Incidentally, these days hardly anyone uses floppies -- none of the newer PCs in my house even have floppy drives :p USB keys are all the rage nowadays.
Offtopic: TWEY SOUNDS BRITISH IN THAT POSTTwey sounds British in most posts, if you look for it, old chap :p
^^ You Got Burned, Yo.Offtopic: MBURT SOUNDS AMERICAN IN THAT POST

:)

[djr33]

Haha. Funny.

Sure, you've got a point there. I wasn't saying that floppies are in any way a crucial part of this... they are just a simple example. With the popularity of music on computers, nearly everyone can burn a CD. Or just email to themselves.
I wasn't suggesting hacking or anything complex... just, for example, someone's sibling messing around. It isn't a huge security threat to have someone with access to your house have access to your computer, but, still, you might as well have the passwords on your desktop.

[mburt]

Offtopic: MBURT SOUNDS AMERICAN IN THAT POST
Hmm.. Well that's funny, I'm not from america LOL

Wow, this is getting really off topic. I'll stop now :)

[Twey]

Canadian English and certain American accents sound fairly similar to us foreigners :) Apparently Americans find English and Irish accents difficult to differentiate between in the same way.
I wasn't saying that floppies are in any way a crucial part of this... they are just a simple example.Yes, I was just mentioning that in passing :)
It isn't a huge security threat to have someone with access to your house have access to your computer, but, still, you might as well have the passwords on your desktop.Apart from the necessity of the memorised password and the inability to memorise the contents of the password file, yes.

[mburt]

Apparently Americans find English and Irish accents difficult to differentiate between in the same way.
Okay: I'm from Newfoundland, my grandfather, uncle, second-uncle, sisters'-brothers'-aunts'-dogs'-baby's twice removed, all speak like Irish (although it's not, people often think it is). When people first came to Newfoundland it was generally a mix of English and Irish people, which in turn invented a new accent.
Sorry for the history shpeel :)

[Twey]

Heh, interesting :) I'm mostly Irish, but my grandfather lived in Canada for a good portion of his life before settling down here with my grandmother, so a trace of a Canadian accent has made its way through the family.

[mburt]

So we're across the bay from eachother :p

[djr33]

As for memorizing the password, think about 9jkdf478k as a password... you COULD try, but still not easy. Same thing, I guess.
Anyway, you could just print out the file or send it, etc.
But... yeah... it IS harder to duplicate than just a shorter password.
In the end, you could just use a long password... require users having a 100 character password (by cutting and pasting, perhaps).
:p

[BLiZZaRD]

I came accross this forum a bit late, and I don't want to really get into it (or get burned, yo ;)

But this caught my eye:


With md5, there is no decryption that is avalible. That is what makes md5 encryption so secure. At least what I am aware of.

However, one of my online acquaintances runs a site that specializes in encryption/decryption techniques for the online riddle sites (like mine) And there is a linkon their site (http://purplehell.com/riddletools/index.htm) that links to an external decryption tool (http://www.md5decrypter.com/) for md5.

Based on this, there must be some internal way to do it, yes?

[tech_support]

And there is a link on their site that links to an external decryption tool for md5.


Better create a difficult password then.

[thetestingsite]

I came accross this forum a bit late, and I don't want to really get into it (or get burned, yo ;)

But this caught my eye:



However, one of my online acquaintances runs a site that specializes in encryption/decryption techniques for the online riddle sites (like mine) And there is a linkon their site (http://purplehell.com/riddletools/index.htm) that links to an external decryption tool (http://www.md5decrypter.com/) for md5.

Based on this, there must be some internal way to do it, yes?

What they do is take whatever text is encrypted using their MD5 encryption tool and save it into a database (regular text and md5 hash). Then in the decryption tool, they find the md5 hash (if it is in the db) and displays the plain text for it. I found a couple of my md5 encrypted passwords not to have matches until I used the encryption tool.

[BLiZZaRD]

Ahhh, I see. Well, as that site grows MD5 will lose some flavor. But until then... I was just sharing.

[djr33]

What does this tool do?
MD5Decrypter.com allows you to input an MD5 hash and search for its decrypted state in our database.

Yes. Very interesting. Evil site... :p
It's cheating it's way to killing the algorithm... not even using brute force... just picking at it, one by one. Ew.

[tech_support]

That's why you don't use a word in the dictionary.

[djr33]

Partly that, but it's all based on what people enter to "encrypt"... they don't get that by doing so, they're making their password worthless. Stupid, really.
So... if someone used "294sadflj34sjflk34jl" as a password and encrypted there, it would undo it as well.

[Twey]

As for memorizing the password, think about 9jkdf478k as a password... you COULD try, but still not easy. Same thing, I guess.The key point is that it's possible, whereas 5kb of binary would require a Memory Man.
Anyway, you could just print out the file or send it, etc.Send, yes; print, no, unless it's a text file. If it's an image, a word-processing document, or anything even vaguely complex, it'll have meta-data that's impossible to reconstruct from a print-out.
But... yeah... it IS harder to duplicate than just a shorter password.Considerably.
In the end, you could just use a long password... require users having a 100 character password (by cutting and pasting, perhaps).But that's still roughly 50× less secure than a 5kb file, has a limited range of values for each byte, and is also a lot more hassle.


There are quite a few MD5 "rainbow tables" around. There was a distributed one (sort of like Folding@Home or SETI@Home) making waves last year.

[djr33]

'rainbow tables'?

[Twey]

Big databases of every possible MD5 hash.

[djr33]

Ok, thought so, but wasn't sure. Interesting. Another reason to use something weird. I have a script that uses images through md5 (to create thumbnails and save space if two images, not filenames, match), and running those hashes through it did nothing ;)