Spring Security - encrypt password before authenticating

[Luke Taylor]

I already explained that this doesn't make sense.

Hashes like MD5 are irreversible - it is impossible to obtain the original value from the hash. Once you hash something the original information is lost. Therefore you cannot use a hash to authenticate to something which is expecting you to send the password (as in binding to an LDAP server). Spring Security (or anything else on the client side) has no way of obtaining the password from the hash.

If you want to hide configuration data in files, then you need to use *reversible* encryption (with a key). See this blog article for a description of Jasypt's support.

http://blog.jayway.com/2008/12/09/en...s-with-jasypt/

[Garoad]

I already explained that this doesn't make sense.

Hashes like MD5 are irreversible - it is impossible to obtain the original value from the hash. Once you hash something the original information is lost. Therefore you cannot use a hash to authenticate to something which is expecting you to send the password (as in binding to an LDAP server). Spring Security (or anything else on the client side) has no way of obtaining the password from the hash.

If you want to hide configuration data in files, then you need to use *reversible* encryption (with a key). See this blog article for a description of Jasypt's support.

http://blog.jayway.com/2008/12/09/en...s-with-jasypt/

I'm surprised by this.

Say you're storing user attributes in a database. You don't want to store a plain text password (or even reversible encryption)--anyone who gets access to that database table could then obtain every user's password. A more secure way to store passwords is to use a salted hash.

So to increase security in this scenario you can hash the password before authentication as discussed in this thread. This works by storing the hash *result* of the password in the database, rather than the plain text password-- thus no passwords are stored anywhere. For authentication the password given by the user goes through the hashing algorithm, and then is compared to the previously hashed value stored in the database. Since the algorithm always returns the same result given the same input, the patterns will match if the password is correct.

As a side note:
Whenever you visit a website and it is able to send you your password (as if a plain text password over non-encrypted email isn't bad enough...), it's cause for concern. The reason most secure websites require you to reset your password (cannot send you the actual pass) is probably because they are not storing your password at all, but a hash (not possible to verify for certain). But if you get a plain text password back in email--it's obvious they're storing the real password in some form and it's possible to retrieve it. (Reversible encryption could help here but still isn't as good.)


So anyway, is there a way of enabling this within Spring Security? We'd just need some way to pre-process the password before it's compared to the stored hash. Sorry to bring back an old thread but this is what I found when I looked...

[pmularien]

Since this thread has gone all over the place with regards to topic, can you please clarify what you mean by "enabling this" - what do you mean by "this"?

[Garoad]

"This" meaning the case I described above of storing password hashes. It may already be possible but I'm assuming not since nobody has said otherwise yet.

Instead of storing a recoverable password, we store (say) an MD5 hash of the password. To authenticate, re-hash the password provided by the user at the time of authentication (this is the part those in the thread seem to be having trouble with), comparing the original stored hash with the newly generated one.

[Garoad]

I do notice a thread around now called "preAuthenticationProcessingFilter" - perhaps that's how to do this? (I'd imagine this is already possible, but just want to confirm and hear how.)

[pmularien]

"This" meaning the case I described above of storing password hashes. It may already be possible but I'm assuming not since nobody has said otherwise yet.

Instead of storing a recoverable password, we store (say) an MD5 hash of the password. To authenticate, re-hash the password provided by the user at the time of authentication (this is the part those in the thread seem to be having trouble with), comparing the original stored hash with the newly generated one.

What you're describing is exactly how Spring Sec can be configured to work, that's why I was confused

Simply configure a password encoder on your user service and Spring Sec will take care of the rest during authentication. When saving the password in the first place, obviously you need to encode it in the same way, but you can just re-use the password encoder for that too. Problem solved!

Pre-authenticated auth is something completely different.

[Garoad]

Perhaps I misinterpreted the original post. I did find this which I believe relates to what I was asking for (and what you've brought up just now):

<authentication-provider user-service-ref="userService">
<password-encoder hash="md5">
<salt-source user-property="username" />
</password-encoder>
</authentication-provider>

[pmularien]

You are correct sir! The only thing that sometimes gives people a difficult time is understanding how the password gets MD5 hashed upon insert/update, but I bet you will be able to figure that out too

I think somewhere earlier in the thread there was confusion about hashing the password prior to authenticating against LDAP, which definitely won't work, ever.

[prigole]

Has there been proposed any solution that enables (salted) hashed passwords to be sent to the server rather than cleartext passwords? We are in a similar situation where we can't use https (client's company policy) and we would really like to scramble the passwords before sending them over the wire.

Best regards,
Peter Rigole

[pmularien]

I'm not aware of anything that would let you do this. Regardless, no matter what you do the password on the client side, if it's unsecure over the wire, it's of course completely vulnerable to replay attacks. Your best bet is to at least write some kind of custom time-sensitive non-repudiation algorithm (such as a hidden, maybe server-encrypted timestamp form field) so that replay attacks are much less likely to work.

Why on earth would a client not want to use SSL to secure username and password data though?