Hacker News Reader

Where do you store the public key?

If you store it on the server alongside the encrypted password and salt, you're effectively using a bigger salt with a weird hashing algorithm that hasn't been vetted by any expert for the specific purpose of password storage.

If you store it on the client side, the user needs to supply the public key whenever he tries to authenticate. This has the effect of making the salt much bigger, but you don't need to use public keys to achieve the same effect. If you can trust the user to store a public key, you can trust him to store any large chunk of random bits.

So apart from the virtually useless fact that you might be able to decrypt the password with the private key (why would you even want to do that, instead of just resetting it?) your method seems to offer no real benefit compared to simply using larger salts with argon2/scrypt/bcrypt/whatever.

Not sure i understand your reply at the moment, but i will definitely try.

We are using RSA. The public key is on the server. We simply using RSA as a "hashing algo". Randomly generated salt is added to the password sent by the user to make the password (much) longer as well as strengthen it before the encryption takes place.

I have explained the reasons for storing the passwords (for the time being, hopefully temporarily) in other replies in this comment branch:

quote:

There's no argument from me regarding undesirability of keeping the passwords. But we also have a different concern - we don't want to be in the business of authentication at all - our goal is to have a third party service or appliance performing authentication and forwarding us already authenticated sessions with the user name as a header, for instance. Our desired end-state - is when we do not have any knowledge of or access to credentials used by the end-user.

To enable us to make this transition possible - for the time being we store the passwords, since as i explained in another reply, we must make this transition transparent to the users and we have legitimate users that login once a year (think credit report, just an example, not our business), so we can't intercept the credentials within a reasonable time period.

/quote

The more standard way to migrate passwords/authentication schemes is to do it on login. So if you want to switch to scrypt from some other format, wait for them to login, check their password via the old method, then rehash the password with the new method. Store in the database which method was used.

If you're switching to a non-password based system like OAuth, make users link their accounts after logging in with their password. If you are going to completely drop the password, then send each user an identifiable link where they can link their account.

Thank you for your reply. Interesting you mention intercepting users passwords.

Our system already went through a similar transition years ago - when we had to migrate away from NDS (Novell), since we abandoned that technology.

In NDS we did not have access to hashes. We ended up having to "MTM" the passwords in opur web app to intercept them before they are sent to NDS and after a successful login store them in the database. To transition our entire user base took a very long time (more than a year), since we had no way to compel the users to login and had to wait until they login on their own volition.

Ever since we've been reluctant to lose the ability to recover the passwords. Transition to Active Directory has been on our agenda for quite some time - and having the ability to decrypt the password for this purpose - we can make that happen in short order (AD hashes the passwords, so it will be a one-way operation of course).

But the question still stands - is asymmetric encryption strong and secure enough to take place of hashing, assuming the private key is secured? I have not been able to find any relevant sources to answer these questions.

> But the question still stands - is asymmetric encryption strong and secure enough to take place of hashing, assuming the private key is secured?

It should be (though it's a big "assuming"). Being able to quickly move away from an older less secure hashing scheme rather than waiting for users to log in could be a security advantage too.

There's a couple of us here watching the replies to this - as this has been our concern for a while and this is a great opportunity for us to get some feedback. Thank you for your reply.

Interesting point about it being an advantage. I am actually going to make a note of this.

One way of handling the private key that i proposed - was to use a privileged access vault like Thycotic. Or just have it on a USB key in a lockbox.

Because it would leak information about the length of the password (and would require length limitations on passwords if the encrypted password is stored in a database). More importantly, I don't see what benefit you get from encrypting your password (read: slow and causes the above issues) rather than using hashing algorithms. If you use the crypt standard for storing your hashes, you can also update the hashes on login when migrating to a new algorithm. Unix systems have solved the "storing passwords" problem. We just need to keep iterating on "what hashing algorithm is trending on HN this week".

Hi, i explained our reasons in replies to other posts, i think they are if not good, at least worth considering.

quote:

There's no argument from me regarding undesirability of keeping the passwords. But we also have a different concern - we don't want to be in the business of authentication at all - our goal is to have a third party service or appliance performing authentication and forwarding us already authenticated sessions with the user name as a header, for instance. Our desired end-state - is when we do not have any knowledge of or access to credentials used by the end-user.

To enable us to make this transition possible - for the time being we store the passwords, since as i explained in another reply, we must make this transition transparent to the users and we have legitimate users that login once a year (think credit report, just an example, not our business), so we can't intercept the credentials within a reasonable time period.

/quote

The approach i used applies salt. It can also pad the password to some standard length, if desired. Though it currently doesn't do that.

Slowness of the algo is perhaps a benefit in a way? In my testing it is still fast enough for our use (we are not facebook).

This only works for deterministic encryption like "textbook RSA", not for any semantically secure encryption, which would produce different ciphertext each time you run it.

I would worry about trying to dual-purpose the encryption like this. If you feel like you must have a way to get the plaintext password back, which BTW you really really do NOT want that liability, but anyway, the safer choice would be to use a semantically secure encryption of the password, and then ALSO hash the password using the current best practices. Use the hash for now to authenticate users, keep the ciphertext if you must, but you'll probably regret it.

Thanks for you reply. It is indeed RSA that I used (from .NET framework).

There's no argument from me regarding undesirability of keeping the passwords. But we also have a different concern - we don't want to be in the business of authentication at all - our goal is to have a third party service or appliance performing authentication and forwarding us already authenticated sessions with the user name as a header, for instance. Our desired end-state - is when we do not have any knowledge of or access to credentials used by the end-user.

To enable us to make this transition possible - for the time being we store the passwords, since as i explained in another reply, we must make this transition transparent to the users and we have legitimate users that login once a year (think credit report, just an example, not our business), so we can't intercept the credentials within a reasonable time period.

What i try to get out of the replies - is whether there's nothing immediately broken about using asymmetric encryption that endangers us aside from the understandable but not immediate concern about liability.

P.S: Earlier i mentioned "intercepting credentials" in our code - and wanted to highlight that the ease of doing that is precisely the reason why we really want to separate ourselves from handling credentials in any form.

I'd been considering something similar, never really made a PoC though.

How about this: User provides their public key when they signup. To authenticate, server produces a nonce and sends to the client, client signs the nonce with private key and sends the result, server verifies signature with public key.

Interesting thought, i need to think about it - i will and write a reply when i have a little more time than i do at present.

What are your reasons to hold on to the password?

Upon further consideration, this pretty much describes a an authentication method based on a client certificate. Unless i am missing something - i am not sure how to apply this to our problem space. We have traditional type of users who are used to username/password authentication. Solutions that we consider have to build on that as a fundamental model.