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.

Improve this question
9
  • 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 4, 2021 at 3: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 4, 2021 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 4, 2021 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 security.stackexchange.com/questions/173484/… 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 4, 2021 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 4, 2021 at 13:58

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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 6, 2021 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 7, 2021 at 1:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .