Web developers

[AtW]

Passwords should never be kept in database - proper implementation would calculate MD5 or SHA1 hash of given password and store it, thus in case of successful attack it won't be so easy to obtain lists of passwords. Thus password storage space from database point of view will be fixed.

In terms of input field length, then requiring 6-8 chars minimum is reasonable, but maximum should be set to value that would never allow people to find it, ie 127 or 255 chars. There is no good reason to set maximum to 12-16 chars.

[BobTheCrate]

Excuse my naivity AtW.

So what is MD5 & SHA1 doing then ? Padding out, according to an algorythmn a user's password to say 127 chars, then recording on file in an encrypted format ?

[AtW]

So what is MD5 & SHA1 doing then ?

MD5 is 128bits or 32 hex chars (16 bytes), SHA1 is 160 bits.

These hashes are one way functions - you can't recover plain text password from them (if you just have hash) so long as password itself is not a simple word that would allow dictionary attack: this is the user's responsibility to choose long and complex enough password.

The benefit of using hashes is that in case of intrusion such hashes will be pretty much useless (again for those users who choose long non-simple passwords, those who use simple word passes deserve to get all the troubles), thus minimising risk to the end users.

There are some attacks on MD5 and some people don't think its secure enough, but in my view such attacks were very exotic, and one can always use bigger hashes of SHA family.

[BobTheCrate]

What if a max 15 char password. Server side this is padded out to a longer string and then encrypted using a key combination of a constant meaningless string + the embedded user Id.

Presumably any 'additional' client side encryption of password could be rev engineered ?

[TheMonkey]

Rubbish - one way hash only. If a user is stupid enough to forget their password, you can always regenerate one and email it to them. If they log in with the temporary one, they will be told to change it again.

With encryption, your password is only as safe as the key. With hashes, your passwords are only as safe as the hashing algorithm. The people who write the algorithms are cleverer than the people who generate and store they keys.

[AtW]

Presumably any 'additional' client side encryption of password could be rev engineered ?

These hashes are one way functions, its basically CRC - you can't recover whole file from 32 bits of CRC, but you can check if given file has got same CRC (ie its same password). Of course 32 bit CRC has got lots of collisions so its not very secure, but MD5 and SHA1 are very secure. The only way you can get out the original password from such hash is to try dictionary attack - ie lots of passwords to see if calculated hash of those will match, but this is the user issue - if they chose weak password its their problem, the most important thing is not to allow easily compromise main database with ALL passwords: storing them as hash is the only way, and thus it means fixed database field size and no point on making any upper limit to password.

[scotspine]

i often use a combined username [unique] and password fed into a one-way hash...

[DimPrawn]

You should add a "salt" to the hashing to prevent dictionary attacks.

[AtW]

I think "salt" is the same as adding some known random values before main key gets hashed: this fails if attacker gets source code, which he/she will certainly have after having reached database.

[Sysman]

i often use a combined username [unique] and password fed into a one-way hash...

Yep, and with a salt too. Remember that if you rename or copy a user record you need to ask for a new password and regenerate the hash.

Since Daleks have a limited vocabulary, more than one might choose a password of "exterminate". Using this method, Dalek1, Dalek2 etc would end up with different hash values.