smartfoxserver.com

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.

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)

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.

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

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.

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.

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.

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.

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

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))

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))