# Tag Info

3

Actually you are quite near on implementing PBKDF2. It is kind of iterated HMAC execution. So have a look here and just implement the missing parts: PBKDF2

1

all those concerns have been studied a lot and still are. I'll try to give some keywords for them. a web app that stores all data on the server in a way that the server can't decrypt the data even if it wanted to. Solution for this is User-side encryption. That's why, forget about the server chosing the encryption key himself. It's quite well spread ...

0

First observe that the password is all that protects the user's data from the server. There is no security added by the public and private keys. Here's a simple solution that should work reasonably well. It may even be secure... Assumptions We rely on a secure symmetric cryptosystem $(E,D)$ that supports authenticated data, that is, $c = E(k, ad, m)$ and ...

1

Since your HMAC key is held in the same database as the passwords you shouldn't count on it to do anything... If the attackers get the passwords, they get the HMAC key. So HMAC doesn't prevent brute forcing, and a password hashing function would provide both points 1 and 2 above. Depending on your timeline you may want to consider using whatever function ...

Top 50 recent answers are included