1

To be clear when I say "private unique identifier" I mean an identifier, which is not stored on the database for the website, it would be hashed in combination with the password and a good salt in the hash table for login information to each account. And when a new user signs up or has forgotten their unique identifier a new one would be emailed to them, and said email along with all trace of the identifier would be deleted from the server after hashing it with the password and storing them. To clarify further you couldn't use a display name because then it would be connected to the account on the hash table, and you couldn't use an email address because the server needs to keep that unencrypted in case you lose your account credentials and you need to be sent a reset link. This would be something like the initials of your name with a unique identifying alpha-numeric or numeric code tacked on to the end which is too long to be brute-forced.

Now the reason why I think this should be an obvious idea for account security. If you were a malicious actor who managed to steal the entire hash table with salts and related account information from a website then there are certain attacks on the said hash table you could use to gather login information. This includes hashing the most common passwords list in combination with the salt values to find the easiest logins. This attack obviously wouldn't work so well on accounts with safe passwords, but I'm going to look even further for maximum security even for accounts with bad passwords. If you have a private unique identifier hashed with the passwords, then dictionary attacks using common password lists wouldn't work because they don't have the unique identifier, and it's not user-chosen so there would be no way to find it.

I've gone over this method a few times in my head and I feel like it's pretty solid, and it has probably already been named somewhere, but I'm not sure what it would be called and I couldn't find it. One thing I know for sure is none of my accounts use a method like this. Please let me know what the name of this practice would be, what attacks would work on a security method like this, and why more websites don't use a method like this. The only reason I can think of is that asking users to keep track of a unique identifier in addition to their passwords all for a security method that only adds so much to passwords is more security than most websites care to use.

Thanks for any and all answers.

Ethan
  • 115
  • 6
  • Why don't all houses uses steel doors with steel frames? It would be much harder for thrives to kick down a door – Conor Mancone Feb 04 '21 at 03:56
  • 1
    Maybe I do not get it since your question does not describe the login process. But from my understanding you basically require the user to remember both the password and the server generated identifier. How is that different from just creating a random password for the user instead of letting the user itself pick one? – Steffen Ullrich Feb 04 '21 at 12:31
  • 1
    And in general to answer this kind of *"Why don't all websites ... [my pet idea]..."* question you should ask yourself: a) does it really provide significantly more security? b) is this improvement in security needed in the first place? c) does the new idea significantly impact usability? d) are there alternatives which also provide (sufficiently) more security while having less impact on usability. – Steffen Ullrich Feb 04 '21 at 12:33
  • @SteffenUllrich on further inspection, yes, in terms of hash security, using a website generated password would be identical to the method I've outlined here. However, on even further inspection from answers here https://security.stackexchange.com/questions/173484/why-dont-all-sites-generate-passwords-for-users and in the connected question that while the security may be the same, the desire of users to decide their own passwords and their potentially poor handling of website generated passwords/ids means this could work as a covering-all-your-bases approach. – Ethan Feb 04 '21 at 13:53
  • @SteffenUllrich As for your second response, I was already realizing near the end of my question as you can see from this "The only reason I can think of is that asking users to keep track of a unique identifier in addition to their passwords all for a security method that only adds so much to passwords is more security than most websites care to use." that this approach was not adding enough security to dismiss the impact to usability which it creates. I'd like to rephrase the question from "all sites" to sites with concerns about security. I still think sites like that can make use of this. – Ethan Feb 04 '21 at 13:58
  • This idea is really awkward if you want to support a forgotten password flow which is what every user understands. Now, you need to store the e-mail adress somehow. Since the whole idea is not to store any public identifier, then you would need to encrypt the adress. You would need some kind of key to encrypt the adress, but storing the key on the server would defeat the purpose. You could derive the key from the private id but then the user would have to remember their private id but somehow not their password which is unlikely. – Artjom B. Feb 04 '21 at 14:39
  • @ArtjomB. The forgotten password flow isn’t really a problem as I see it, first of all you wouldn’t need to encrypt the email address because you aren’t using it in the login, only when signing up. The idea isn’t “having no public identifier”, it is that the identifier you use to login isn’t public. So if you forget your password or your unique id you enter your email address and you are sent a link which if you click then gives you a new unique id and a place to enter your new password because it has to rehash both anyways. – Ethan Feb 04 '21 at 14:48
  • Well, it is a problem because the forgotten password flow is a way to log in for many people. They routinely forget their passwords and just use their public id to get a new password. If you want to support this flow using a public identifier then you might as well use the public identifier for normal login operation. There is no difference. An attacker uses the weak point and if you think having a public identifier is a weak point then it can be used via the forgotten password flow. I'm still not sure what the benefit of that scheme would be if you still require a public identifier in the DB. – Artjom B. Feb 04 '21 at 22:35
  • All you're really doing is creating a second password or pass phrase of arbitrary complexity. 2FA adds a *Something You Have* instead of a second *What You Know*. – user10216038 Feb 04 '21 at 22:57

1 Answers1

1

I am unaware as to a name for this model, but would say that the main reason for lack of uptake is its unwieldly nature if the user is not already employing a password manager.

In this setup the Private Unique Identifier (PUI) appears to be acting as a second password, one that is specified to be secure in the event of database breach. Assuming the PUI is of recommended length for a strong password (using Protonmail's of 15 characters as an example) this will be nigh impossible for end users to remember for multiple sites. As such they would have to use a Password Manager to effectively use this system, but in the event they do this they can already use passwords of sufficient length and randomness.

In addition the PUI is not a 'full' implementation of MFA as the PUI is not a different type of proof (such as something you are like biometrics or have like Authy app). Consequently I do not think the added security is as great as encouraging users to use 2FA.

The other, more mundane reason is that this change would involve changing many tables or files (if using NoSQL) in your DB! As to implement this you may have to change the Primary Keys of tables it could be a very hard security addition to add to an existing site.

As for attacks, as (assuming I understand the concept like you) the PUI acts as a second password, it would be suspectible to the same attacks. If it is also created with your initials or another deterministic prefix this might make it easier to break.

anotherusername
  • 340
  • 1
  • 6
  • It does seem to be acting as a new password, I've also found that it's equivalent to taking their salt, making it private, and giving it to them because salts are also unique and non-brute-force-able. I don't think tacking on the initials would make it easier to break though, considering the rest of it would already be tested to be non-brute-force-able. But I do see why this would be harder and less effective than 2FA. – Ethan Feb 06 '21 at 22:02
  • cheers, and with prepending the initials (or anything similar) I included it as this would mean the attacker would be able to know some of the characters that make up the PUI from say the display name. Like you said I doubt this would aid in compromising given the complexity, but someone might be able to find some crazy relation so thought its worth mentioning – anotherusername Feb 07 '21 at 01:40