You are not logged in.
Pages: 1
In my product one of possible authorization schema is very close to mORMot default so problem exist in mORMot also.
The problem is:
If someone receive all rows from User database table (User.LogonName and User.PasswordHashHexa) he can perform authorization without actual password knowledge, just because he know PasswordHashHexa value.
And this is a puzzle for me how to resolve this situation...
May be someone have ideas?
P.S. in real application I use Kerberos or private/public key based schema, so password do not stored in DB, but sometimes it is overhead..
Last edited by mpv (2014-11-02 10:33:53)
Offline
And the second idea:
I have feature similar to NoTimeStampCoherencyCheck, but in case it true, I continue to check timestamp coherency but with 300 second delay (almost all HTTP implementation drop connection after 5 min of inactive).
Offline
Hi,
Mormot not work that way.
Read the blog: Authentication-and-Authorization
briefly:
Here are the typical steps to be followed in order to create a new user session via mORMot authentication scheme:
- Client sends a GET ModelRoot/auth?UserName=... request to the remote server;
- Server answers with an hexadecimal nonce contents (valid for about 5 minutes), encoded as JSON result object;
- Client sends a GET ModelRoot/auth?UserName=...&PassWord=...&ClientNonce=... request to the remote server, in which ClientNonce is a random value used as Client nonce, and PassWord is computed from the log-on and password entered by the User, using both Server and Client nonce as salt;
- Server checks that the transmitted password is valid, i.e. that its matches the hashed password stored in its database and a time-valid Server nonce - if the value is not correct, authentication fails;
Offline
I think your app has to compare an unencrypted password from the client with an unencrypted password of the database, which is stored encrypted in db.
In this case, the knowledge of the Hash is useless because it will never compared.
My whole communication goes over https. Therefore the client could insert an unencrypted password without security problems.
Offline
@mpv & others
If you want the password on the server to be protected when stolen, we need to implement a private/public key mechanism, instead of the shared hash key model currently used.
http://en.wikipedia.org/wiki/Public-key_cryptography
We need to find a simple way of implementing it.
Offline
I have already did this. If you get User.PasswordHashHexa you can inject it into JS Ajax-client to perform authorization without actual pass knowledge. (but you need to know the username) It's difficult, but it's possible to perform the same task in win Client.
"User.PasswordHashHexa" shouldn't be exposed. I think if you encrypt SHA256("User.username") and store it into DB, it would be much more difficult to inject into JS f.i.
Would be possible someone fish "User.PasswordHashHexa" stored in DB?
Any idea how someone could fish "User.PasswordHashHexa"?
Last edited by warleyalex (2014-11-02 20:15:01)
Offline
I already implement a private/public key mechanism (our goverment have sertified CA and provide libs for Elliptic curve cryptography
Authorisation implementation is:
In User table I store user public key.
Client send auth?userName=...
Server generate random 64 bytes secret, encrypt it using client public key and send encryptedSecret and server public key back
Client decrypt encryptedSecret using his private key, encrypt result using server public key and call auth?userName=..&secret=...
Server decrypt secret using server private key and compare with originally generated.
Authentication is the same as in mORMot, but sha256(secret) is using for session signarure instead of sha256(salt+password).
In this schema I dont need to store password in DB at all, but must provide secure store for server private key and give HASP tokens to clients, so, as i note above, it is oversecure in some app.
mORMot way is good, but only weakness is password in database stored in the same format client use it to authorize (in other word, this is the same as storing it as is)
Offline
@warleyalex. Someone could fish "User.PasswordHashHexa" in many ways, the simplest is to pay some money to sysdba :-), or by attacking database server, or using SQL injection or in many other ways.
Offline
Pages: 1