Why is the password not decrypting correctly?

[shaulbehr]

I'm writing a server side extension with custom login code. Here's the code:

Code: Select all

String encPwd = (String) event				.getParameter(SFSEventParam.LOGIN_PASSWORD);
ISession session = (ISession) event.getParameter(SFSEventParam.SESSION);
encPwd = encPwd.toLowerCase();
String clearPwd = CryptoUtils.getClientPassword(session, encPwd);

But the value of clearPwd is not what I sent in - instead, it's a string that looks like some kind of hex number, and it changes with each new session, e.g. "f94f56419f6fd58a5d96b63246db2723"

What is more, I suspect something is very awry, because if you look at the interface definition in Javadocs you'll see:

Code: Select all

public static String getClientPassword(ISession session, String clearPass)

Why is the parameter called "clearPass"? Surely it should be called "encryptedPass"? The return value should be clearPass!

Am I wrong - or is this a bug?

[appels]

you can't decrypt the password, it's one way. You should use 'checkSecurePassword' to validate the received password

[shaulbehr]

No, that doesn't work.
What if the password is hashed on my SQL database?
I want to be able to hash a password and compare it to the hash on my DB in order to validate.
What you're saying is that the incoming password is *also* hashed, meaning I cannot decrypt it, and if I need to validate it against another database, well, then that's just too bad.
Seriously? SFS was designed with this kind of "customizable" login in mind, such that you can't actually do a custom login?

[appels]

1. it does work since i'm using it.
2. checkSecurePassword was created to do just that what you are saying.
Compare the encrypted password received from the client against a password.

[shaulbehr]

1. it does work since i'm using it.
2. checkSecurePassword was created to do just that what you are saying.
Compare the encrypted password received from the client against a password.

Sorry, my wording was ambiguous - I meant "No, that doesn't work [as a solution for me]."

Let me be clearer about my scenario: I have a hashed password in my MS-SQL database. Hashed, i.e. cannot be decrypted. In order to validate the password, I need to take the candidate password and hash it using the same hashing algorithm, then compare the hashes.

What you are saying is that this mode of login validation is not supported by SFS2X. Am I correct?

[appels]

I also have hashed passwords in my database, send the hash to SFS, use the command to compare the hash against the hash in the database.

[shaulbehr]

I also have hashed passwords in my database, send the hash to SFS, use the command to compare the hash against the hash in the database.

How is that possible? How could SFS possibly know what algorithm I'm using to hash my passwords?

[appels]

which encryption scheme are you using ?

[shaulbehr]

which encryption scheme are you using ?

I use my own formula for encrypting passwords. Completely unique. That's why I would be pretty much stunned if SFS knew how to copy it!

[appels]

I don't know the specifics on how the command works or what it supports but using MD5 works fine that way i explained.

[shaulbehr]

In other words, SFS does not support custom hashing; you have to have access to the user's clear text password from your own database (i.e. no custom-hashed passwords), or you can't use SFS.

As it happens, I can work around that - but IMHO that's a very severe design limitation in SFS, and the programmers should seriously look at creating an interface that allows you to decrypt the incoming password into clear text.

[rjgtav]

Hi. What about this:

1. In the client, instead of sending the clear password, you send the password hashed with your own scheme.
2. In the server-side, you get the password from the db and then you can already use the checkSecurePassword()

[appels]

i'm a big noob when it comes to encryption but making it possible to decrypt a password seems like an open door to hacking to me. Which would be an even bigger flaw in the design. But i'm sure Lapo can chime in with more a more technical explanaition.
And indeed the way i explained before might also work for custom encryption but again...i'm not the expert.

[Neznajka]

you may send all parametres you need to encrypt in ISFSObject and then do encrypting password on server. if password is crypted corectly then all will be ok.

[rjgtav]

Well, the only problem is that you're sending the "clear" password over the internet... That's why the API automatically hashes the password before sending it with the LoginRequest