Encryption, hashes, and general security. 1

[max2474]

I have been reading up a lot on hashing and site security recently.

I have always had a few doubts about hashing though most likely just due to lack of understanding...

1. If a database is stolen, then surely all of a users information (except the password) is readily available for an attacker to view..they wouldn't need a password in the first place....?

2. If an attack is performed on the site itself, then no matter how much hashing is done, 1 guess of the right password using rainbow tables will allow access.

That said, here are my thoughts for the security of the site I am currently developing.

1. Take the chosen users password and split it - probably in half. If you know there is a minimum of 6 letters in the password, split it 6 times (the 6th time being the remainder of the password)

E.G. "pass" +"word", or even "p", "a", "s", "s","w","o","r","d".

2. Use different hashes and salts with each part.

$part1=sha1(userid+"p");
$part2=md5(datejoined+"a");
$part3=whirlpool(mysitesalt+"s");
etc
etc

3. save each of these in the database, and then combine them when checking login.

if ($password <> $part1+$part2...)

I do understand that this is potentially overkill and could slow down login, but my belief is that you cant be too secure.

I am also considering making members to have a number code as well (like banks often do) as this essentially means that an attacker has two passwords to crack. (my site does need to be extra secure )

Finally, to address my first point, am thinking of encrypting all data stored in the database too.

Would appreciate your thoughts!

 

[jpadie]

1. if the database is stolen, and nothing else, then the data should still be integral and secure unless the database is successfully submitted to a hack vector (brute force or otherwise). Assuming the database is secured, that is; and the data store is not plain text.

2. yes. unless the hash consists of more than one element, depending on the data segment. in which case only the relevant data segment is compromised.

a. hashes are difficult to reverse engineer. but not impossible. the more complex the hash (assuming no vulnerabilities) the more difficult to reverse engineer.
b. your system does not increase the protection against a remote brute force attack as the hashing mechanism itself remains the same and is based on raw text (not pre-hashed) input.
c. if your database can be stolen probably the server side code is also compromised; in which case a hacker can just take the algorithm (although this would not really help hack a password, but it would make it easy to replace the password for a known string without needing to bother with the brute force - assuming that the database password were stored in the application layer or another compromised location)

if you need to improve the authentication and authorisation layer of your application then a nonce (number used once) and user password is good (something you have and something you know). the nonce might be sent by text message for extra authenticity.

however this does not improve the physical and logical security of your presentation, application and storage layers. and nor (imo) would the complex hashing that you have suggested as it would not alter the behaviour of a remote hacker (plain text attack vectors against the application layer, or the normal vectors against the OS or WS layers). nor would it alter the behaviour of a hacker with access to the OS or WS layers, as then your file system is compromised and the rest is relatively easy.

 

[max2474]

Thanks for your explanation.

So, if I understand correctly, this wouldn't really be much more secure than if I just used 1 algorithm with one hash? (With a number too)

I didn't realize how difficult it would be to make a secure website...from what you have said, it seems there is very little in fact that can be done other than the salt and nonce.

 

[jpadie]

i suppose the starting point is to determine what you mean by secure. it is always a trade off between usability and security.

in determining security you must consider

physical access to the hardware
logical access to the hardware at the operating system layer

drilling down from there you need to consider whether the services and applications running on your hardware are secure.

but there is little point in installing a great lock on a wall made of paper. don't spend inordinate time securing an application layer if the rest of the infrastructure is not secured.

 

[max2474]

Good point. Am reasonably happy with the security I have in mind and when I get to publishing stage, will look at security offered by the host too. Many thanks again.

 

[Olaf Doschke]

Actually you make the most important note last:

Finally, to address my first point, am thinking of encrypting all data stored in the database too.

Just not storing passwords is only securing the surface better, but if the site or (my)sql server is hacked, unencrypted data is as unsecure with or without passwords stored.

Your idea of splitting passwords and generating several hashes is quite contraproductive, because each single hash is then just made from a single letter or char. There are only 256 md5 hashes of the single chars. Adding salt makes that better in creating a larger variety of hashes again. But in general the length of data you hash also contributes to the irreversibility of a hash.

Adding fields as in $part1=sha1(userid+substr(...)); is not making that much safer, because in case of a hack your code will be revealed and so that part of the password could be determined by generating 256 hashes of userid+'a' to userid+'z'.

A single hash is really a good thing to do. To add the userid is still a good thing to do, as even two users with the same password then will not get the same hash.

Or think of this situation: A hacker creates a normal account and then hacks the database and copies the hash stored in his user record to other users records, then he can log in with his password as another user, do stuff and finally revert the data.

That's not possible, if the hash is done on userid+password. So that part of the idea is really good for that reason.

Bye, Olaf.