Reply to: Web developers

[Sysman]

As for exploits of MD5 and SHA1 - if you read in details they are pretty much theoretical, this kind of attack can only be mounted by Govt entities and those guys would prefer to use simple methods - a few broken fingers and person in question will give all passwords they want.

Ah yes, "social engineering"

[AtW]

Indeed, there is really no excuse. As for exploits of MD5 and SHA1 - if you read in details they are pretty much theoretical, this kind of attack can only be mounted by Govt entities and those guys would prefer to use simple methods - a few broken fingers and person in question will give all passwords they want.

[Sysman]

This is how database itself stores user passwords - which is certainly reasonably secure, where as I am talking about developers who in my view would more often than not choose to store password in plain text in their own designed tables.

Given the available information on the subject, they have no excuse really.

Oh, since you mentioned MD5 and SHA-1, here's a snippet for you

http://dev.mysql.com/doc/refman/5.0/...functions.html

"Note: Exploits for the MD5 and SHA-1 algorithms have become known. You may wish to consider using one of the other encryption functions described in this section instead."

[AtW]

This is how database itself stores user passwords - which is certainly reasonably secure, where as I am talking about developers who in my view would more often than not choose to store password in plain text in their own designed tables.

[Sysman]

My guess that in most systems password is stored in plain text in database.

I haven't seen that in years.

Here's some info on Oracle passwords:

http://www.red-database-security.com...passwords.html

Oracle brute force attacks / Oracle Password Decryption

It is not possible to decrypt a hashstring but (with) the simple Oracle salt (=Username) it is possible to do a brute force or dictionary attack. There are several Oracle brute force or dictionary attack tools available. These tools encrypt the username/password and compare the hashkeys. If the hashkey are identical the password is known. From simple SQL based tools (<500 pw/second) up to special C programs like checkpwd. The fastest tool calculates 1.100.000 passwords/second. On a Pentium 4 with 3 GHz it takes (26 ascii characters only, e.g. 26^5)

10 seconds to calculate all 5-ascii-character-combinations
5 minutes to calculate all 6-ascii-character-combinations
2 hours to calculate all 7-ascii-character-combinations
2,1 days to calculate all 8-ascii-character-combinations
57 days to calculate all 9-ascii-character-combinations
4 years to calculate all 10-ascii-character-combinations


You should always use strong and long passwords to avoid brute force or dictionary attacks.

[Bovvered]

Most talented developers these days work in web developement due to the complex nature of the various levels one needs to think about. e.g. sessions/stateless nature/ajax/web services/caching.

Mmmmm. Most talented developers are all rounders and don't box themselves into 'web' or 'Windows' or 'middleware' or 'database' labels.

When you're working on a 24 hour, real time, global trading system, you'll find that, "I'm a web developer" won't cut it.

[Emperor Dalek]

yes, in a table named passwords in a database name db, located in the root of C:\

HTH

That's right. It is password protected but login name 'admin' (password 'admin') will let you in.

[DimPrawn]

My guess that in most systems password is stored in plain text in database.

yes, in a table named passwords in a database name db, located in the root of C:\

HTH

[Emperor Dalek]

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.

On Skaro we overcame this problem quite easily. My password is exterminate1, the Supreme Dalek's is exterminate2, and so on.

[AtW]

My guess that in most systems password is stored in plain text in 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.

[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.

[DimPrawn]

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

[scotspine]

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

[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.