search

LinusU / secure-remote-password

A modern SRP implementation for Node.js and Web Browsers
101 stars 22 forks source link

It's just very time consuming? #11

Closed navigator117 closed 6 years ago

navigator117 commented 6 years ago

It's just very time consuming?

LinusU commented 6 years ago

Would you mind clarifying what are asking?

navigator117 commented 6 years ago

It's cost > 200ms on my machine to run the test. I was wondering whether SRP are suitable to be used on heavy load site? nodejs seems not doing well or CPU cosuming tasks too.

LinusU commented 6 years ago

Most of the work happens on the client side, I would recommend benchmarking only the server part to see the real impact.

I would guess that this is actually faster than doing bcrypt/pbkdf2 on the server side, and you could still use bcrypt/pbkdf2 on the client side and thus gain the extra security without impacting server performance.

I'm currently deploying all my stuff to Lambda, so I cannot really measure the performance impact in regards to event loop saturation with this package. Although it would be very nice to add some benchmarks to the project!

alexgoldstone commented 6 years ago

The SRP algorithms are only applied when the user's password is created, changed and at time of login.

For us, we then issue a JWT on successful SRP authentication. So, any impact of SRP is minimal compared to the overall session.

Unless all users are logging in at exactly the same second, it really shouldn't be a problem for high load sites.

Of course it would be better to quantify this and I could try to contribute to the benchmarking but what would we be comparing against?

LinusU commented 6 years ago

[...] but what would we be comparing against?

Very true 😄

navigator117 commented 6 years ago

Yes, your are right :) I have check the test, the client part cost most time.

navigator117 commented 6 years ago

It's too hard for me to read RFC of SRP. Can you tell me, if I save the server & client ephemeral & session key with salt and verifier in db, is it possible to guess user password out from these data?

navigator117 commented 6 years ago

And I have tried to use this library to generate session key, with another HOTP library to got one time password. I want to keep session for a long time, months eg. is it possible to guess session key out from many OTP token?

LinusU commented 6 years ago

Can you tell me, if I save the server & client ephemeral & session key with salt and verifier in db, is it possible to guess user password out from these data?

When signing up, you should only store username, salt and verifier in the database, nothing else.

When authenticating, you should only store the serverEphemeral.secret in the database.

That being said, SRP is zero trust, so as long as you only send the what's documented in the readme here, the server should never even see anything that could help to figure out the password.

And I have tried to use this library to generate session key, with another HOTP library to got one time password. I want to keep session for a long time, months eg. is it possible to guess session key out from many OTP token?

Not sure exactly sure what you are doing here. Without knowing which HOTP library you are using, and how that is working, I cannot answer on that part...

navigator117 commented 6 years ago

Thanks for your advice! I have tried to use this library https://github.com/yeojz/otplib/ to do OTP verify after session key generated. AFAIK, session keys can use to create security channel from client to server. But I just want server to verify that client know the same session key without transfer it. So I choose to let client generate new token from session key and send it to server at every request, server then verify recved token with session key. Could you tell me, if I miss understand the usage of SRP, or It's just fine to use like this?

navigator117 commented 6 years ago

You said "When authenticating, you should only store the serverEphemeral.secret in the database.". So I know I can only keep session key in memory, never save it to DB.

LinusU commented 6 years ago

So I know I can only keep session key in memory, never save it to DB.

If the session key is leaked, and you are authenticating subsequent requests based on that one, someone could impersonate that user. It's hard for me to make recommendations without knowing your specific use case, but this probably isn't too much of a problem. In case of a breach, only active session would be affected and, assuming that you find out about the breach, you should be able to easily invalidate all sessions.

As far as I understand HOTP seeing many of them shouldn't leak any information. Therefore I think that initializing your HOTP state with the derived session key should work very well.

Are you using time- or counter-based OTPs? Are you sending the derived OTP result as the Authentication header?

navigator117 commented 6 years ago

I'm using counter-based OTPs. In challenge-response mode, at each time, client ask server the new counter value, then client derive the OTP token from his session key and the replied counter value, and send it to server. server then calc his token value and compare with the recved one. after successful compare, server knows client has the same session key, and increase the counter for next request as needed.