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
salted MD5 / SSL / ??
Posted by: gunwant_s
Date: December 20, 2008 08:32AM

Hi,

There was this application which I was auditing last week which had no SSL implementation. I recommended of salted MD5 hashing besides SSL for a multi-tier protection.

Now my question is, if for a site you do not have SSL but salted MD5 implemented, you can protect authentication credentials but not session credentials. If SSL is not acceptable for an application due to some reason (heavy load or frequent building and tearing down the code for updation), what possible way(s) can be used to protect the session credentials or protect against session attacks?

Thanks,
Gunwant S

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: thrill
Date: December 20, 2008 10:53AM

Using MD5 to store the password hashes on a site that doesn't use SSL is like putting a lock on your front door where you need to use the key on the inside, but the outside has the knob you just turn to unlock.

You are sending the passwords in clear text and then comparing hashes. Save yourself the time, if they don't want SSL might as well store the passwords in clear text.

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: December 20, 2008 12:50PM

You are not getting. The application is using salted MD5 hashing which means the passwords are going in a salted MD5 hashed form (different string each time) as the salt changes each time.

So the passwords are safe in the transit and they are safe (in one way) on the server itself i.e. stored as MD5 hashes. But...

What I was talking about in the first place is that if the passwords are safe with the salted MD5 hashing, still the session credentials (Session IDs, cookies, etc) are not if the application is on non-SSL channel. A malicious user gets the clear text session-credentials in this case which exposes the application to Session attacks.

Sorry if I was not that comprehensible. Let me know if I am missing anything.

Thanks.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: zatoichi
Date: December 22, 2008 03:41AM

is the password hashed at the client side before being sent to the server side( is MD5 implemented in client side), in that case replay attacks are a good possibility even if the salt is changed everytime.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: December 22, 2008 04:45AM

Can you explain how is that possible if the salt varies each time?

The way it is implemented currently is as follows:

Client side:

Password ---> MD5 = Temp
Temp + Random salt ---> MD5 = Result
Result is sent to the server.

Server side:

MD5 stored password + Same random salt ---> MD5 = Result

Both results are then compared before access is granted.

I think Replay attack is not possible if a highly random salt is generated for each request.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: zatoichi
Date: December 22, 2008 05:58AM

if that is the procedure then we can rule out the replay attack, but can't the password be recovered since we already know the salt value we can create a rainbow table for the password hashes in 5-6 days if going with a dictionary based attack then even less time is needed, exposing the salt is a bad practice. are u using any criteria for preparing passwords , for ex. it shd have a numeral,capital letter, and must have atleast six characters long etc.??

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: December 22, 2008 06:19AM

The salt (which is stored temporarily in the session object for the particular session instance) is unset after the authentication is successful. So, if you log out and log in again, the salt will be different. No use of rainbow table or even you know the salt for that instance.

I read another post on the salt thing which mentioned that the salt is always the same at the server which is insecure. In my case, whenever you visit the login page, the salt will be different each time. Its gonna change the string in transit each time when submitted to the server. In plain words, you can't get the MD5 hash of the password due to the highly random salt concatenated to the MD5 hash.

I have the code with me, if you (or anyone) like please check it out. Here you go:

http://gunwantsingh.blogspot.com

Sure, password complexity is being followed.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: December 22, 2008 06:23AM

My original question still remains: What mitigatory measures can be taken to protect the session credentials on a non-SSL channel?



Edited 1 time(s). Last edit at 12/22/2008 06:30AM by gunwant_s.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: Malkav
Date: December 23, 2008 04:58AM

the only remote authentication protocol who protects credentials both during transport, AND on the remote server is SRP. [http://srp.stanford.edu/]
if you only care about the transport level credential security, you can use many non-plaintext protocols like CRAM-MD5, CRAM-SHA or whatever suits your needs and requirement.

zero knowledge proof is a quite complex mathematical problem. don't take it too lightly, and from what i have seen, you're homebrewing crypto. this is *bad*
bad like in 'if i took a webdev doing that kind of stuff, he would soon hope for the relief of id's wrath'

you're not a cryptographer, get your fucking hands out of this. now. use standard protocols, use standard library functions, follow guidelines, read the corresponding RFCs, GROK the corresponding RFCs. and at any point, make absolutely *sure* that all points of your authentication procedure obey low guidelines, read the corresponding RFCs, GROK the corresponding RFCs. and at any point, make absolutely *sure* that your authentication procedure obey Kerckhoffs' principle. obscurity protected schemes : we break it.

oh, look, was that a rant ?

----------------------------------------------------------------------------------------------------------------

Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
--Benjamin Franklin

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: id
Date: December 23, 2008 02:24PM

OPIE!

-id

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: December 23, 2008 10:18PM

@Malkav

Thanks for your reply.

Oh well, do you really think its a homebrewn cryptology?

http://www.owasp.org/index.php/OWASP_AppSec_FAQ#How_does_the_salted_MD5_technique_work.3F

http://www.owasp.org/index.php?title=Hashing_Java&setlang=es#Complete_Java_Sample

http://en.wikipedia.org/wiki/Digest_access_authentication

This scheme is being implemented in many government and other applications. Give me one flaw in this scheme. I do not know of any at the moment. May be there is which You know or has not been discovered yet. That's why we say Security is not a characteristic but a measurement. Same holds true for SRP, etc.

I agree with you when you say SRP protects credentials both at transport level and server level. But are we talking about only authentication credentials which are already secure with salted MD5 hashing? Does SRP protects session credentials? If not why should I overload my server with SRP if it going to provide me nothing more than salted MD5 hashing? (I am talking about insecure session credentials here.)

Thank you for the other wealth of information.

P.s: Yes, your talks were exaggerated which could have been said a bit courteously.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: December 23, 2008 10:36PM

If we put a unique value (nonce) on each page behind authentication and validate the same at the server side for each request akin as in mitigating CSRF, would it mitigate attacks like Session Fixation or Session hijacking ?

Thoughts?

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: Malkav
Date: December 26, 2008 11:02AM

ok let's be more polite this time.

of course, hash salting is a known technique. its only purpose is to make bruteforcing of a huge number of hash difficult by inserting a nonce. so far so good.

it's still homebrew crypto, as in 'your own implementation'. as you seem to know, algorithms maybe structurally sound on a mathematical PoV, and still friable in their implementation (see : countless example of good algorithms implemented by drunk monkeys)

i maintain that the only way to provide a little assurance about the security of your whole authentication scheme is to use not only well known, well reviewed algorithms, but using this algorithms through well known, well reviewed implementations.

you seem to use the theoritical scheme of the two tokens RSA system (one fixed, one random, concatenation is password). so far so good. how do you synchronise between client side and server side ? do you rely on time for pseudo randomness ? if yes, how do you ensure nanosecond synchronization between client and server. and if not, do you transmit the one time random ? you of course realize that if you were to transmit the nonce over the wire, either from client side or server side, ssl or not, it would be a simple matter to reconstruct and bypass the scheme ?
if the clients generates the nonce, how do you prevent transmission of a null string as a nonce, thus defeating the salting ?
if the server generates the nonce, how do you prevent interception on the client side by eve ?

either you're assuming a secure transport, thus rendering the complexity of this scheme useless, permanent per-user salt storage still defeating precalculated attacks, or you're not assuming that transport is secure, and this scheme is worst than static salt, because of the higher probability of interception and/or alteration by attacker.

my point, expressed politely or not, still holds. assuming that there is no guarantee of secure transport, plaintext, salted hashs won't hold, and assuming there is no secure storage, non-plaintext traditional schemes won't hold.

of course, this is all theoritically speaking, and i have used per-user salt with SHA256 for ages without complaint that the password was stored in weak form. it's all a matter of trust after all.

----------------------------------------------------------------------------------------------------------------

Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
--Benjamin Franklin

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: December 29, 2008 12:24AM

Thanks for your considerate reply. My this reply does not portray that I am arguing on anything but it is just a normal discussion.

I could have agreed to your concept of the 'homebrewn cryptology' if you could have given me some logic behind that. Something like "I say it's insecure because it has *this* flaw".

I happily accept the fact that in ideal environments one should implement a well-reviewed, well-implemented and well-tested algorithms. However, practically the invulnerable alternatives can't be overlooked, of course if one uses the patched or flawless versions of the scheme till the point when someone finds a flaw.

I also agree with the fact that if you are using a well-reviewed system, you should implement it in a secure way. If you have reviewed the source code of my implementation (gunwantsingh.blogspot.com), you wouldn't have asked the questions. To answer your questions, see below.

1. how do you synchronise between client side and server side?

- The random salt (nonce) is generated on the server i.e. on a server-side file which is not sent to the client. The random value generated is included in another file which is sent to the client. This salt is valid only for some very little time (if you think this is a flaw, keep on reading) or till the user logs in.

2. if the clients generates the nonce, how do you prevent transmission of a null string as a nonce, thus defeating the salting ?

- the salt is not generated at the client side.

3. if the server generates the nonce, how do you prevent interception on the client side by eve ?

- If the adversary gets the salt during the transmission from the server-side to the client-side, there are 2 possibilities:

* either the legitimate user will log in
* or he won't

* If the user logs in (of course with salted MD5 hashing ON), the salt will be unset after the successful authentication i.e. it would not be valid for any other subsequent transaction, thereby bypassing the replay attacks.

* If the user does not log in (may be because he's suffering from Internet addiction disorder or something)- only the captured salt will have no use to the attacker.

Having said that, I am not saying this is an ideal proposition but this can be implemented in practical terms until someone finds a flaw in it. A flaw - not in the algorithm but the implementation. Of course to further harden the algorithm used we can use SHA-1 , SHA-256, etc as a substitute for the MD5 which is used in the current implementation.

Waiting for the reply.

Thanks.



Edited 2 time(s). Last edit at 12/29/2008 02:41AM by gunwant_s.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: NickWilliams
Date: January 10, 2009 12:57PM

It is difficult to ascertain what you are trying to say, gunwant. I hope that in the future people replying to this thread will be patient and helpful rather than volatile like that of Malkav.

Firstly, what you've mentioned sounds an awful lot like HMAC (http://en.wikipedia.org/wiki/HMAC). HMAC will ensure that the message is coming from an authentic source and it will also ensure the message has not been tampered with but it will do nothing to protect the message contents itself. With the addition of a timestamp as more salt in the hash, it will also serve as protection from replay attacks.

HMAC is only suitable in situations where the data being transmitted itself is not sensitive, but a secure authorization system is required.

If there was a man-in-the-middle that did obtain the SessionID contained in the cookie, it should be inconsequential as the HMAC procedure (in combination with a username added before/after the hash in plain text) will also identify which trusted source the message is coming from. Even if the man-in-the-middle was a trusted source and he replaced his own SessionID with the one he intercepted from the communications of another trusted source, you would still be able to tell that the SessionID he provided is not his own. Server-side you would need only to associate the username/password with a given SessionID - once the message being sent is verified to be from a trusted source, the next step would be to ensure that the SessionID provided belongs to *that* trusted source.



Edited 5 time(s). Last edit at 01/10/2009 02:38PM by NickWilliams.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: January 12, 2009 03:45AM

@ NickWilliams
Thanks for replying.

You said:
"With the addition of a time-stamp as more salt in the hash, it will also serve as protection from replay attacks. "

You mean besides concatenating the salt, I should also append the time-stamp to it before sending the credentials to the server. You don't think it's already mitigating replay attacks. Any scenario you can provide to show how a replay attack can take place w/o the time-stamps appended? I am curious how exactly can time-stamps help me in this scenario?

You also said:
" Server-side you would need only to associate the username/password with a given SessionID - once the message being sent is verified to be from a trusted source, the next step would be to ensure that the SessionID provided belongs to *that* trusted source."

Linking the assigned SID (Session ID) to the credentials is a good idea in case user has to provide the credentials for each page behind authentication. Consider a scenario wherein a user provides his credentials and then the server links a particular SID to his username/password after successful authentication. Subsequently, to access all other pages behind authentication the client only provides *SID* (and no credentials) which is consequently validated at the server-side. If a trusted source captures the SID and tries to access some behind-authentication page (just by replacing his SID with the captured one), don't you think he will definitely be granted access to the other trusted source's page since he don't have to provide his username/password?

P.s:
>"It is difficult to ascertain what you are trying to say"

In plain words, my little research question is how to secure the *Session credentials* on a non-SSL channel.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: January 12, 2009 05:02AM

@Malkav

I looked over SRP lately and I think its a very good implementation technique for *authentication* purposes (yes, better than salted MD5 apparently) but I am not sure if it will work on a non-SSL session. Meaning: Will it protect against impersonating someone's SID on a non-SSL?

If the adversary imitate the master session key (generated via SRP) to access a behind-authenticated page, what is going to happen? I think SRP provides a good authentication mechanism w/o in relevance to an implementation in an application. I think we can get an answer only after implementing this thing in some application.

Thoughts?



Edited 3 time(s). Last edit at 01/12/2009 05:42AM by gunwant_s.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: NickWilliams
Date: January 12, 2009 12:46PM

gunwant_s Wrote:
-------------------------------------------------------
> You mean besides concatenating the salt, I should
> also append the time-stamp to it before sending
> the credentials to the server. You don't think
> it's already mitigating replay attacks. Any
> scenario you can provide to show how a replay
> attack can take place w/o the time-stamps
> appended? I am curious how exactly can time-stamps
> help me in this scenario?

Timestamps change on their own, removing the need to invalidate any previous salt used on a message. So long as I couldn't be a man-in-the-middle and resend one of your messages exactly as the client sent it and it be accepted by the service, then you're fine.

> Linking the assigned SID (Session ID) to the
> credentials is a good idea in case user has to
> provide the credentials for each page behind
> authentication. Consider a scenario wherein a user
> provides his credentials and then the server links
> a particular SID to his username/password after
> successful authentication. Subsequently, to access
> all other pages behind authentication the client
> only provides *SID* (and no credentials) which is
> consequently validated at the server-side. If a
> trusted source captures the SID and tries to
> access some behind-authentication page (just by
> replacing his SID with the captured one), don't
> you think he will definitely be granted access to
> the other trusted source's page since he don't
> have to provide his username/password?

If, at any point, you send only the SessionID without message or transport level security then you will be susceptible to forgeries/session hijacking. You will need to perform your hash every time a message is sent. The key to security here is comparing the hash to one you calculate for the given credentials, and then comparing the authenticated username with the SessionID previously assigned to that particular username.

> In plain words, my little research question is how
> to secure the *Session credentials* on a non-SSL
> channel.

This is for-sure possible. I will assume that you are not talking about a simple web page but instead a thick client and, perhaps, a webservice or similar server side situation. This process should work with a web page and javascript but it's not ideal as the hashing in JS would probably be pretty CPU intense for the client.

Before communications start, the client and server should both have a password relating to the particular client. The client should obtain the password through an out-of-band method such as email, phone, fax, etc. The whole point here is that we're rendering eavesdropping ineffective - not impossible.

The client will first send a message to the server attempting to authenticate/log in. To do this, the client will take the message body it has compiled, a timestamp, and his password and concatenate them together, performing a hash on the resulting string. The client then combines this hash and its username to form the authentication header - such a header might look like this if using SHA1 "ClientUsername:9ce3ea4d6fac2165933b3971e6d5a13753c7d878"

When the server receives this message, it sees that it is ClientUsername who is attempting to authenticate. The server looks up its password on file for this user, and performs the exact same procedure on the client's message that the client did. If the client and server have the same password, and the server's time is equal to that of the client's, then the server should calculate the message's hash to be "9ce3ea4d6fac2165933b3971e6d5a13753c7d878" - if it didn't then the client has the incorrect password and the server should ignore the message entirely or return an exception.

If the hashes did match, then we know it is really ClientUsername, and we generate a SessionID and return it to the client while making note server-side that this SessionID belongs to ClientUsername. From that point forward, the client will be providing its SessionID *in addition to* the authentication header described above.

Now, since we aren't using SSL, a man-in-the-middle could easily obtain the SessionID and the client's username from any of the messages - but since the password is never sent in the message, it can not create an authentic message because its hash would be wrong.

We must also consider a malicious client who does have a valid username/password combination. If you had two clients and one stole the other client's SessionID, it would be able to provide a valid SessionID *and* a valid hash for its message. But, since we are ensuring that the SessionID provided by ClientUsername is actually the SessionID we provided him, we can still throw the message out and remain secure.

If a man-in-the-middle recorded a series of messages and sent them to the server at a later date, the timestamp of the server should be different than the timestamp that the client had when the message was created (and thus the server's calculated hash would not match the one in the message) so we can more or less eliminate the possibility of replay attacks.

This entire process relies on the password never being sent, and the messages being hashed every time they are sent. If either of those change, you can not do things as I've described. Hashing function is up to you and, obviously, you're going to be more secure with SHA256 or the likes than MD5 (I would go with SHA1). This might sound like a lot of CPU work but it is still less than that of SSL and without the hassle of certificate renewals and the likes.



Edited 2 time(s). Last edit at 01/12/2009 04:07PM by NickWilliams.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: January 13, 2009 03:47AM

@NickWilliams

I see what you are saying.
You are saying that the OOB-communicated password, message and the time-stamp are concatenated and hashed each time when the client sends the request. ok.

And if the adversary captures the communication and then replays it later, it won't work because of the time-stamp mismatch.good.

However, one thing that's really bugging me in this technique is that how would you keep track of the time-stamps at the server side i.e. considering the time when time-stamp is concatenated in the formula at the client side and the time it leaves the workstation plus the time it takes to travel across etc. How would you synchronize the timing thing between server and client (if we also consider milliseconds even nanoseconds)?



Edited 1 time(s). Last edit at 01/13/2009 05:04AM by gunwant_s.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: NickWilliams
Date: January 13, 2009 06:53AM

Synchronization of timestamps is tough. Generally the server and client do some handshaking and the client estimates its latency to adjust the timestamp it sends in an attempt to match the server's. The server also applies a tolerance but, in our situation, this requires additional processing at high cost depending on the resolution of the timestamp (e.g. calculate timestamp for 1 second ago, 2 seconds ago, 150 milliseconds ago, etc) and, as you're alluding to, it's probably not the best choice for our situation.

So long as you're generating something in addition to the password to use as a salt, and so long as the server invalidates that salt as quick as absolutely possible, and so long as an eavesdropper will never be able to obtain this salt, you'll be fine. Remember that we're not guarding against eavesdropping so you don't want to be sending this additional salt to the client. Instead use something agreed upon at design-time. Something such as a sequentially increasing integer of sufficient size never to wrap back to 0 during the course of communication - this is probably your best choice.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: gunwant_s
Date: January 14, 2009 02:14AM

I think the solution you mentioned is appropriate if we are considering the stated research question. It has given me another interesting research area on how to implement this technique where we have to put the mentioned methodology into practice besides addressing the time-synchronization issues. Since I've got the idea now, I know how to proceed.

Do you know of any application (web/non-web) already using this technique? For a web application, it is definitely memory intensive, but as you said it can be acknowledged if you are on non-SSL considering other requirements. Not to forget an intensified security and functional review is apparently needed.

Anyway Thanks a Lot for your help. I still seek other ideas if you or anyone wants to share.

Thank you all.

Options: ReplyQuote
Re: salted MD5 / SSL / ??
Posted by: NickWilliams
Date: January 14, 2009 07:48AM

I think the best example is Amazon's Web Services; they utilize HMAC-SHA1 extensively. Their documentation also describes the process thoroughly: http://docs.amazonwebservices.com/AmazonS3/2006-03-01/index.html?RESTAuthentication.html

Further, it looks like they transmit the timestamp visibly as well as use it in creating the hash. This will ensure that the timestamp sent by the client is actually authentic (if it was altered, the hash would change). The server can first ensure the hash is authentic, and then examine the plaint-text timestamp and ensure that isn't too far off. I think that's a winning idea for sure to prevent replay attacks.

Options: ReplyQuote


Sorry, only registered users may post in this forum.