passwords ; to encrypt or not?

BEFOR

I'd much appreciate if someone could review my thoughts to help shed a little light on this thread, about handling passwords. I've debated whether I should, on the initial registration form;

A) Let new users select their own usernames/passwords and encrypt passwords in to the database OR

😎 Let users only select usernames and email them a generated password (in which case they can change password after first login) OR

C) A combination of both; let users select their own usernames/passwords and not encrypt into the database. This assumes an SSL is applied for security (my understanding is that encyption basically protects the user against whoever has access to the tables - namely the site admin, since users likely have the habit of using the same passwords on multiple sites.

I beleive that emailing the password (generated ) at least provides some level of assurance against those simply wanting access beyond registration (in that the process is somewhat cross-verified by an email receipt of an assigned password. at the minimumum the registrant would have to have a working email, which needs to be verified anyway for future correspondances).

However with so many sites changing to let users choose their own password on registration, and seeing the hessitancy of users to enter the scrambled generated passwords back into a form, myself, I can't seem to settle on whicih way this should be done.

I'll admit one reason for my hessitancy is if I ever want or need to change software platforms from the one I'm currently using for encryption. My software firm says" we are using the php crypt function" What are the chances I could continue with the same encryption technique that would be needed for all prior users?

Another point is that for lost passwords, don't encrypted passwords require an extra step ? ; a new password has to be established - I can't simply email a lost password back to a user. They need to be sent a temporary password and then after login pick another.

Any help appreciated.

mtmosier

Encrypting passwords (or more specifically, hashing them) is not only so that the admin can't see it. Its also to stop attackers from getting their hands on them. Like you say, users tend to use the same password on multiple sites, so an attacker getting acess to them is still a very bad thing, even if your site has nothing too critical on it. If an attacker were able to compromise the server, or even just find a sql injection attack against the website, they may be able to gain access to your password list. You want to make it as difficult as possible for them to get the real passwords.

As far as changing environments, as long as you use a well known algorithm you should be able to find implentations of it for any platform. If you're using a web hosting environment then it'll be more difficult. You may have to shop around. But in that case sticking to the very common algorithms, such as sha1, or at worse md5, should keep you safe.

Of course as advances in computing continue hashing algorithms will become outdated. I believe it won't be long before md5 needs to be phased out. Upgrading encryption after the fact is a huge annoyance, but it is possible. (I'm currently rolling out sha512 hashing with a nice long salt, and iterating it. I deal with sensitive information though.)

Users are terrible about entering generated passwords. I get bothered all the time because a user will hit forgotten password, then call up customer support claiming it doesn't work. I really wish the general population understood the concept of "copy & paste".

If you're going to generate passwords and email them to your users make sure that you have the ability to force them to change their password immediately upon logging in. Email is an insecure method of communication, and users tend to just leave their generated passwords sitting in their inbox. The longer that password remains unchanged, the more likely it is for an attacker to find it.

As an alternative to generating passwords you can email them a link (which will expire in x amount of time) where they will be able to change their password.

Oh, one more thing. Don't underestimate the importance of SSL. SSL will protect the passwords in transit to your site, so hashing them in the database has no relation to SSL at all.

Lots of good security information can be found on the OWASP website.

BEFOR

Any feedback on article claiming md5 hash function has been broken?:

http://www.cryptography.com/cnews/hash.html

re: http://us4.php.net/md5 'Mathieu'

mtmosier

First off, I'm not a cryptography expert, so take everything I say with a large grain of salt. If a cryptography expert does happen by, I will read his or her reply with much interest. 🙂

Anyway, here's my take on it all.

I personnaly recommend everyone not to use this function as it could generate the same value for many different strings.

This is completely non-sensical. Of course md5 can generate the same value for different strings. So can sha1 and every other hash algorithm normally used. (Can't say anything about quantum computing, about which I know nothing, but I'm fairly certain you don't have that available to you, so...)

Md5 only provides, at most, 2¹²⁸ unique values. Sha1 could only provide 2¹⁶⁰ values. Considering that you could give it an infinite number of different input values, of course there are going to be collisions. The trick is how likely it is for a modern computer to be able to find a collision.

My understanding is that the current attacks against md5 are being able to take a known value, and being able to make specific changes to it while having it still calculate to the same hash. I believe at the moment they have to control the starting value though. This more affects things like files you download on the internet, and then check the md5 hash of it to make sure its authentic. A person could offer one program with the hash, then later swap it with a malicious program which has the same md5 hash. If they widen this attack so that they can take any known value and modify it to get the same md5, then this will make md5 all but useless for verifying software you download.

For passwords that means that (if an attacker knew the md5,) even though your user's password is "12345678", an attacker could enter "lj234j5hjHOIUj#$2kjlkjsdfi*7ksj", and gain access to the website as if that were the correct password. It doesn't mean the attacker will be able to figure out the real password from that. (For such a simple password the attacker would find it much faster through brute force then s/he would via collisions, but thats aside the point.) Of course if you use plain (non-salted) md5 on your site, and one or more other sites also uses plain md5 for password checking, an attacker could use the collision they found with your site to log in to the other website(s). Salting your hash should make it unique to your site in this case, as well as help protect against dictionary attacks.

All that said, today, in this moment, I think md5 is still good enough. But I wouldn't deploy it in any new installations. I expect in the not too distant future more and different attacks are likely to be found which may be much more serious than what we've seen so far.

BEFOR

Thank you for that detailed reply. That document wasn't exactly what I wanted to find. Wanted to do some checking around, that's all.

This is a new installation, another source of hessistancy on my part.

if an attacker knew the md5

If I change shared hosts, are there variations of md5 that may have to be matched by the new host?

I've been inclined to hold off and wait (site users do have the ability to update tables, perform edits, I take it this should really be done as Inserts on seperate temporary tables, to be later added to permamanet live tables by site admin).

Maybe I'm better off concentrating in other areas for now until a sounder solution arrives? Existing passwords could always be encrypted at a later date (manually).

ex: restrict access by username/password/user access-levels & with table prefixes, apply ssl's, log ip addresses (though don't know how much record of ip logs may play, given dynamic ip's)

mtmosier

Sorry, what I meant in that quote was "if the attacker knew the md5 value you have stored in your database". In general the md5 algorithm is standard.

One thing to note. In your original message you mentioned using php's crypt function. I've never used crypt, but from what I understand it's nice in that it automatically adds a salt to your hash for you, so you don't have to worry about it. Crypt has "an MD5-based encryption algorithm", but looking at it here I don't believe its compatible with the normal md5 command. I may be wrong. Like I said, I've never used crypt.

Weedpacket

Originally posted by BEFOR
Any feedback on article claiming md5 hash function has been broken?:

http://www.cryptography.com/cnews/hash.html

re: http://us4.php.net/md5 'Mathieu'

Good commentary on these results is given in http://www.schneier.com/crypto-gram-0409.html
The results with regard to weakening MD5 also apply to SHA-1.

Roger_Ramjet

Just a postscript. Most hacking is not that sophisticated, nor does it need to be. The weakness in any password system was always the user, and it will continue to be whatever algorithms or encrytion is developed in the future. Most users want a password that is short and easy to remember, so most hacking is just brute force: cycle through all the possible combinations untill you hit the right one, often starting with an english dictionary as most people use a real word they can remember.

Even worse is the kind of password one of our staff got from Barclays online banking 5 DIGITS ??? . That means only 10,000 possible combinations, a trivial hack.

Forcing people to use non-words and leter number combinations is the systems admins nightmare, because the users just write it down somewhere, or leave it in their inbox as mtmosier points out.

Roger_Ramjet

My bank uses the triple entry system: user, password + any 1 from 5 possible questions. The best part is that the answers to the questions are ones you specify, so I lie when they ask for my mother's maiden name etc. That way anyone who knew the real answer would be wrong.

BEFOR

I'm in a quandary. Whether to even use md5 on one site (shared server) and Sha-1 on another (shared too)

My concern is that, as these two show further signs of losing their strength, and I have several thousand registrants (realistic) that there will be not only two different types of hash algorithyms on two seperate sites(meaning, that I could never join the two sites if need be -- these are related sites) but that I will be asking users who have recently migrated to new usernames/passwords on one site to change their usernames/passwords yet again. Keep in mind there are four pages of registration forms, so this has become more than tedious for many. I'm currently changing users over to the site (offering md5) for the first time onto mysql tables.

Given the current situation, more importantly, the foreseeable trend, wouldn't it be wise to hold off on encryption altogether for now, especially with the md5 host?

I understand assigning an access level which I do for restricted access can place a higher hurdle for a hacker.

Roger_Ramjet

If people are prepared to go through all that to sign up, and if security represents a significant threat to them as well as you, then they will appreciate your efforts to be as secure as possible. I don't mind any effort my bank requires, it's my money after all. Given that, have you thought about digital certificates and the like. I don't know anything about them myself, except that they exists, or I would have more advise for you on the subject.

laserlight

My concern is that, as these two show further signs of losing their strength, and I have several thousand registrants (realistic) that there will be not only two different types of hash algorithyms on two seperate sites(meaning, that I could never join the two sites if need be -- these are related sites) but that I will be asking users who have recently migrated to new usernames/passwords on one site to change their usernames/passwords yet again.

If you do decide to use a cryptographic hash function on such sensitive data (and I think you should), then use SHA1 with a random (or at least a reliable, or securely hashed pseudo-random) salt of significant length.

You could always request the change of passwords for security reasons, which in fact is true.
At the same time you could remind users to choose a long password that avoids dictionary and other common words and phrases.

mtmosier

The weakness in any password system was always the user, and it will continue to be whatever algorithms or encrytion is developed in the future.

Wow, is that ever true. During a recent security audit of a site (not mine), I found that 70 users had the password "12345678". Quite annoying.

Anyway, your users don't even have to know when you're migrating. Shouldn't be a problem to have both sha1 passwords and whatever new type of hash in the database at the same time, with some sort of flag (length of hash, separate fields, a boolean field, whatever) to tell you if the hash stored is in the old format or the new. Whenever a user logs in while they have the older hash in the db, quitely migrate them to the newer hash.

I would keep this setup running for a decent period of time, 6 months or a year perhaps, then either delete all accounts which never logged in (and are probably inactive), or do a mass "forgotten password" on all non-migrated accounts.

Roger_Ramjet

I found that 70 users had the password "12345678".

How about a sys admin who set the superuser passwaod to 'qwerty'? The mind just boggles sometimes 😕

Weedpacket

Originally posted by Roger Ramjet
How about a sys admin who set the superuser passwaod to 'qwerty'? The mind just boggles sometimes 😕

According to Cracklib and its dictionary my system came with, that counts as a "strong password". Points up for Cracklib! 😃

I had to think about passwords to a new hash a while back. The system wasn't implemented (for unrelated reasons) so I don't know how effective it would have been.

It rolled out in stages. First the database has its hash field's type altered, and a new boolean field "uses_new_hash" (default FALSE) was added.

Then, email notices are sent out to all customers that the site is undergoing a security overhaul and new passwords are necessary. Looks and sounds like phishing I know, but each email is personalised with the recipient's name, and does not give them a link to the site (we expect them to already know the site's address!). The email also invites the customer to request confirmation via other channels (again, they are left to their own devices to look up the phone number).

The email also mentions that they will be required to check in at the site or their account will be retired and they'll be locked out.

When they log in to the site, the uses_new_hash field is true. If it is, the new hash algorithm is used when checking the validity of the password. If it is not then the password is checked against the old hash. If that passes, then the password is rehashed to the new algorithm, replacing the old hash, and the boolean field is set true.

A week prior to the deadline, reminder emails are sent out to all users whose uses_new_hash field is still false. And again 48 before; if the number is small enough, an attempt is made to use their other contact details to remind them.

When the deadline arrives, all the records with uses_old_hash still false are retired (removed from the table of active users). The login code has the extra checks and retests removed (so that it is substantially as it was before the migration), and finally the uses_old_hash field is dropped.

Life continues as normal.