Login problem - Salted Password Hashes in Database

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

p3dro.sola
Posts: 25
Joined: 22 Dec 2009, 17:00

Login problem - Salted Password Hashes in Database

Postby p3dro.sola » 14 Jan 2011, 00:03

Hi, I'm developing a custom login extension. But the catch is that the passwords stored in the database are encrypted with a salt.

so i have a hash like md5(password + salt)

In SFS 1.6 i could get the plaintext password from the client, and thus compare them, but in 2x the passwords are already encrypted. Is it possible to decrypt the client's password? Or are they hashed?

What's the solution here? Cause if SFS forces you to store your passwords as plaintext, or straight MD5 hashes, it's not a great idea.
rav
Posts: 82
Joined: 06 Dec 2010, 13:14

Postby rav » 14 Jan 2011, 05:51

get crypted password from client login request
cryptedPass = (String) event.getParameter(SFSEventParam.LOGIN_PASSWORD);

get plain password from database
plainPass = SomeDBManager.getPlainPassword();

after compare them via api:
getApi().checkSecurePassword(session, plainPass, cryptedPass)
p3dro.sola
Posts: 25
Joined: 22 Dec 2009, 17:00

Postby p3dro.sola » 14 Jan 2011, 07:42

rav wrote:get crypted password from client login request
cryptedPass = (String) event.getParameter(SFSEventParam.LOGIN_PASSWORD);

get plain password from database
plainPass = SomeDBManager.getPlainPassword();

after compare them via api:
getApi().checkSecurePassword(session, plainPass, cryptedPass)



Yeah, i know i can do that. The while point is that it's ridiculous to store the passwords in plaintext in the DB.
rav
Posts: 82
Joined: 06 Dec 2010, 13:14

Postby rav » 14 Jan 2011, 10:26

p3dro.sola wrote: The while point is that it's ridiculous to store the passwords in plaintext in the DB.


Nothing prevents encrypt (f.e. with AES) the password before you put it into a database. And decrypt it before using in getApi().checkSecurePassword
p3dro.sola
Posts: 25
Joined: 22 Dec 2009, 17:00

Postby p3dro.sola » 14 Jan 2011, 10:29

rav wrote:
p3dro.sola wrote: The while point is that it's ridiculous to store the passwords in plaintext in the DB.


Nothing prevents encrypt (f.e. with AES) the password before you put it into a database. And decrypt it before using in getApi().checkSecurePassword


The vast majority of web apps use hashes. IE: not reversible.
The reason for this is that if your encryption key is leaked, you're fucked.
tchen
Posts: 191
Joined: 11 Dec 2010, 14:14

Postby tchen » 14 Jan 2011, 10:36

The weakest link is the open network here, so sending clear-text passwords (or reversible ones for that matter) over the wire is worse than having to store it on the database.

If you already have another authentication system running, there's always the possibility of piggybacking on it and issuing a nonce token that's exchanged with the SFS2X instead of the password.
p3dro.sola
Posts: 25
Joined: 22 Dec 2009, 17:00

Postby p3dro.sola » 14 Jan 2011, 10:39

tchen wrote:The weakest link is the open network here, so sending clear-text passwords (or reversible ones for that matter) over the wire is worse than having to store it on the database.

If you already have another authentication system running, there's always the possibility of piggybacking on it and issuing a nonce token that's exchanged with the SFS2X instead of the password.


I agree. But it'd really make integration easier if they were encrypted instead of hashed.
tchen
Posts: 191
Joined: 11 Dec 2010, 14:14

Postby tchen » 14 Jan 2011, 10:44

I found this old thread on the 1.x forums from BigFish which might be a good idea to try

viewtopic.php?t=3695&start=0&postdays=0&postorder=asc&highlight=

Quick summary: hash the password on the client to duplicate your db hash, then send and compare.
rav
Posts: 82
Joined: 06 Dec 2010, 13:14

Postby rav » 14 Jan 2011, 10:46

p3dro.sola wrote:The vast majority of web apps use hashes. IE: not reversible.
The reason for this is that if your encryption key is leaked, you're fucked.


OK, use MD5 before inserting something into database and use MD5 for cryptedPass before getApi().checkSecurePassword. So there are no plain passwords in your database
p3dro.sola
Posts: 25
Joined: 22 Dec 2009, 17:00

Postby p3dro.sola » 14 Jan 2011, 10:48

tchen wrote:I found this old thread on the 1.x forums from BigFish which might be a good idea to try

viewtopic.php?t=3695&start=0&postdays=0&postorder=asc&highlight=

Quick summary: hash the password on the client to duplicate your db hash, then send and compare.


Yeah, but 1.x worked differently.
The password you submitted was what was received.

in 2x you send x and the server recieves md5(x)

so if you send md5(x) the server recieves md5(md5(x))
tchen
Posts: 191
Joined: 11 Dec 2010, 14:14

Postby tchen » 14 Jan 2011, 11:07

Lets say the original db password uses dbpass=sha1(plaintext)

On the client,

login.user = 'bubba';
login.password = sha1(txt.input);

So on the server, we actually get
encrypted = md5(session.salt + md5(login.password))

which if you use getApi().checkSecurePassword on dbpass, should return you true as it's comparing against md5(session.salt + md5(dbpass))

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 5 guests