Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Salt, anyone?
Posted by: EWSec
Date: January 30, 2008 12:45PM

I'm posting this under CSRF and Sessions, because I didn't know where else. :/



I don't get it. What's the point of salting passwords, in the context of webappsec? Client-side salting makes no sense, and server-side is pointless because it has to be stored somewhere, associated with the password, so if anyone breaks into the server, they can see the salt, so it breaks the purpose...

Personally, I believe enforcing strong passwords (longer than 6 chars, combination of lowercase, uppercase and numbers) is much better solution that actually does some protection.

Or am I missing something blatantly obvious? :)

Options: ReplyQuote
Re: Salt, anyone?
Posted by: kuza55
Date: January 30, 2008 02:38PM

Salting stops precomputed attacks such as Rainbowtables.

----------------------------------------------------------
Don't forget our IRC: irc://irc.irchighway.net/#slackers
[kuza55.blogspot.com]

Options: ReplyQuote
Re: Salt, anyone?
Posted by: EWSec
Date: January 30, 2008 05:32PM

Yeah if you had just a hash and nothing else, which is an "ideal" lab condition. But in the context of web apps and their interaction with databases, there are (at least) two channels to "attack" a password:

1. Using the login form processor -- but whatever you supply there will be combined with salt anyway, so having it or not having it is all the same for this channel.

2. Using a stolen database with encrypted passwords to crack. But, eh, those usually come with the salt itself stored in the tables, and combination algorithm is most likely known.

In other words, someone will either attempt to guess a password, or bruteforce it somehow through your login form, or they will attempt to gain access to your db and fetch the hashes (along with the salts).

No?

Options: ReplyQuote
Re: Salt, anyone?
Posted by: tx
Date: January 30, 2008 05:55PM

Even if it is known that the hash is salted and how it is combined, salting adds the burden of generating a custom rainbow table specifically to take into account the salt(s), which really hurts the TMTO advantage that rainbow tables give.
That being said, I've seen a number of applications that salt with only a couple alphanumeric characters and have a trivial minimum password length (like 5 chars), which definitely minimizes the value of salting at all.

-tx @ lowtech-labs.org



Edited 1 time(s). Last edit at 01/30/2008 05:56PM by tx.

Options: ReplyQuote
Re: Salt, anyone?
Posted by: EWSec
Date: January 30, 2008 06:24PM

Yeah... that's true. But if anyone has access to the hashes, s/he is in position to inflict far greater damage, rendering the salt a trivial protection.

Options: ReplyQuote
Re: Salt, anyone?
Posted by: Anonymous User
Date: January 31, 2008 12:55AM

You are right, it basically is a big problem in cryptography. Because like you pointed out, where do you leave the key? hashsing a priori doesn't need a key, which is great because it only leaves you with a hashsum and not the original file or data. Drawback is that they can be computed via rainbows. Key management is something that is hard to solve, and if you have access to the hashes already, the salt can be located in some cases, But it depends on where the salt is deployed. Since it's possible to read out PHP files with SQL injection, it can be found. But that scenario is difficult to achieve but not impossible. Never ever store the salt into a database, because then your screwed. The best method is to store the salt --or key-- below the html folder, just like database connection settings with PHP safe_mode turned on, which means that no-one other than the owner can view the salt in case of an attack, or when PHP simply fails and everything is rendered as plaintext. Given that, if someone has root it completely renders away all security.

Options: ReplyQuote
Re: Salt, anyone?
Posted by: Karon
Date: March 03, 2008 07:08AM

edit *forget it*



Edited 1 time(s). Last edit at 03/03/2008 08:49AM by Karon.

Options: ReplyQuote
Re: Salt, anyone?
Posted by: majak
Date: March 03, 2008 02:45PM

but one salt for all passwords stored in file means that you need only one rainbow table... it loses it's main feature.
or i get you wrong and you mean one salt for each user in one file?
(it doesn't sound good for me, but maybe there is nothing wrong about it)

Options: ReplyQuote
Re: Salt, anyone?
Posted by: fragge
Date: March 03, 2008 03:51PM

I have one question - how simple is it for somebody to get a hold of the php file itself. ie: login.php, is it possible to read the php code for this? This is the only thing that has ever confused me about this subject. If no, then I have no clue why on earth anyone is storing salts in a db which is much easier to crack than the server itself. -_-

Options: ReplyQuote
Re: Salt, anyone?
Posted by: tx
Date: March 03, 2008 07:14PM

@majak: I believe that Ronald ('Anonymous User' as it were) is referring to creating a unique salt for each password hash that is to be generated, and then storing them in a file outside of webroot.

@fragge: That's a complex question, the answer is: it depends. Sometimes it's very easy, as ronald said you can load php files and read them with an sql injection. This isn't true in all cases, it depends on how the network is set up.

-tx @ lowtech-labs.org

Options: ReplyQuote
Re: Salt, anyone?
Posted by: fragge
Date: March 03, 2008 08:16PM

@tx: but if your sql isn't injectable, it is impossible to view the php short of hacking the server itself, correct?

Options: ReplyQuote
Re: Salt, anyone?
Posted by: RyanTheGreat
Date: March 04, 2008 01:54AM

Well, it could be read a few ways, not necessarily 'hacking' the server if I follow your meaning of 'hacking' anyway ;)

My suggestion for salts would be to use a different salt based on the user-supplied input. For example, a 12 char salt for a short password (5 char password, for example) and a 6 char salt for a longer password (12 char password, for example). Variable length and content salts means they would need to know the original length of the input to know which salt was used.

This means, even in the case that they are able to read your salt-generating algorithm, they'd need to also figure out what length your original input was.

(This means not storing the salt anywhere in the db itself associated with the password)

Options: ReplyQuote
Re: Salt, anyone?
Posted by: fragge
Date: March 04, 2008 03:58PM

Yes, that's the method I use, although calculating it by length is probably overkill. When it boils down to it, if your hashes are taken, it's only a matter of time before theyre cracked, if only 1 at a time. But even so, as far as salt goes, I calculate a random length salt between 15-25 characters which is an md5 salt + a double md5ed hash of the whole or part of the username given, which is like the salt to the salt. Then I decrypt it by taking the preset length of my salt salt (which itself has a 4 bit salt) and decrypting twice, checking against user. If they match, then he has the correct salt salt. Next, check of rest of pw against that in the db to confirm entry. Done deal. Overkill? Just sexy salts.

Options: ReplyQuote
Re: Salt, anyone?
Posted by: kogir
Date: March 08, 2008 05:30AM

It seems I'm late to the party here, but I wanted to try and contribute anyway.

The only purpose salts serve is to force an attacker to brute force each password individually. Given enough time and effort, any password can be cracked.

See http://sla.ckers.org/forum/read.php?15,19557#msg-20896 for a detailed writeup :)

-kogir

Options: ReplyQuote
Re: Salt, anyone?
Posted by: Mordred
Date: March 25, 2008 05:54AM

Use two salts:
- one per login, kept in the database
- one per site, kept outside the database (i.e. hardcoded in the source, or whatever)

A successfull attack on the login credentials would require obtaining the per-site salt as well (hopefully harder than getting the database); the per-user salts protect accounts with the same passwords.

Here's a (still draft) article I wrote more than a year ago:
http://forums.devnetwork.net/viewtopic.php?t=62782

-----

P.S.
I notice that many people think that rainbow tables are the only attack there is agains hashes. There are other optimisations of the generic bruteforce attack besides RTs: dictionary lookups, reduced alphabets, online bruteforcing of known "weak" accounts (depending on the hashing scheme, you can know if an account is "weak" even if you don't know the password). One can also use known plaintext attacks against the salts, so it is imperative that they are sufficiently strong (i.e. LOOOOONG).

Options: ReplyQuote


Sorry, only registered users may post in this forum.