3

I am designing a system which requires access control via a strong password and for that purpose will use a password generation algorithm A that produces a strong password of length L >= 32. The system would check for the password and, if the password is incorrect in several consecutive attempts, block the user from further logins for some period of time.

In addition, the system should:

  • generate a long strong password
  • password must be unique in the world,
  • allow for an easy password change,
  • require no authentication (i.e. users supply only password, but no user name),
  • be simple in implementation and in use.

Because I have no hands-on experience in security issues, I would greatly appreciate if the security gurus could critique the following simple, and, perhaps naive, design:

  1. Invoke the same known algorithm A (say, a good one-way hash function, a UUID generation algorithm, etc.) T times, where T is a very big number, at least a billion.
  2. Record all T generated different passwords in a file, a password per line.
  3. The user shall pick a number N (perhaps randomly generated) between 1 and T and remember that number in his or her head.
  4. When asked for a password, the user would look in the file at position N, copy the password at that position and paste it to the program that asks for a password.

Comments:

A. It appears that a person can remember a number between one and a billion without much trouble, as it has less digits than a US long distance phone number.

B. As long as the file is not lost (it can be replicated), the user will always have the right password.

C. The password can be changed easily any time by regenerating the whole file and picking a new password at the same position N. The user will not need to remember the new password -- using the same number N would result in a new password.

D. If an attacker gets a hold on the file with a billion passwords and tries repeatedly to login in order to find the correct password, then most likely it would take a very long time (years or may be centuries) because the system would keep blocking the user after just a few failed attempts.

E. Because of D, the password file can be kept in plain-text, no encryption is needed.

Question:

What is wrong with this kind of system?

Improve this question
10
  • 2
    It is not user friendly. User still needs to remember something (row number) and in addition, needs to open password file, scroll to the correct row, copy and paste password for each login.
    – Question Overflow
    Nov 3, 2014 at 8:39
  • Would this be a problem? User A starts using the service and gets the file. User B changes his password and User C starts using the service and gets the file. Now User A and C together compare their files and the difference gives them the password of User B? Or perhaps the similarities give them the passwords of many other users?
    – Dennis Jaheruddin
    Nov 3, 2014 at 13:57
  • I agree it is not user friendly, not sure how to improve that short of running something like this (in UNIX): "head -N password_file".
    – Simple
    Nov 3, 2014 at 16:55
  • About scenario for users A, B, and C -- the idea is to always generate each password unique in the world, in separate files per user, sorry if this has not been explained clearly. I am not sure how then different users could make any conclusion from comparing their individual files -- every line from one file will be different with every line from another file all the time.
    – Simple
    Nov 3, 2014 at 17:00
  • 1
    It looks like you have much bigger issues in your design other than password management. The password should not be a key to anything!
    – schroeder ♦
    Nov 3, 2014 at 17:47

3 Answers 3

Reset to default
7

If you assume the attacker has the file, then you're actually relying on the number N as your password. You have stated that this is a user selected number, and it's likely that users would just chose (for example) 111....111, 123..., 000...000, or something similar.

This could be countered by telling the user what value of N to use at "generation time", however, it's likely that the user would write it down or similar. Humans don't remember long-distance phone numbers any more, heck, I don't remember any phone numbers anymore!

You've also stated that the number N maybe upto a billion or so, or roughly 10^9. This gives your password scheme quite a low entropy overall.

Improve this answer
5
  • 3
    A billion is 10^9.
    – isarandi
    Nov 3, 2014 at 11:15
  • Thanks @isarandi, I've fixed the error. Only a couple of orders of magnitude ;-)
    – Tinned_Tuna
    Nov 3, 2014 at 16:57
  • 1
    Realizing the 2014 people, including myself can't remember phone numbers as the old somehow makes me uncomfortable :)
    – AKS
    Nov 3, 2014 at 18:19
  • just a fun fact: billion has different values in different languages (just want to explain how the mistake maybe happend) en.wikipedia.org/wiki/Long_and_short_scales in most european languages a billion is 10^12
    – Patrick
    Nov 3, 2014 at 18:59
  • @isarandi Actually the word billion means a million squared. It originates from the words bi meaning second and million, in other words "billion" means a million to the second power. But somewhere along the way somebody misunderstood it and somehow convinced entire countries to use their misinterpretation of the word billion. There are countries still using the proper interpretation of the word billion.
    – kasperd
    Nov 3, 2014 at 20:01
2

Also consider that using a password in isolation means that if an attacker has access to the password file they would not need to find a password for a specific user, they only need to find a password that has been selected by any authorised user, obviously as the user population increases the greater the probability of an attacker choosing a 'live' password.

From a practical perspective how would you block users? With no identifier you will need to use something else, I'll assume IP address, which is OK if you know that all your users will have unique IP addresses, but if there is the possibility of shared IP addresses (for example via an Internet gateway) there is a very real possibility of unintentional denial of service, or even successful logins resetting the failed login count and allowing an increased attack rate.

Improve this answer
4
  • Using an IP address would tresult in horrible usability... we all know there are people who'd love an IP whitelist for their credentials, but authorizing users via their IP would result in trouble if their IP changes every week/month (based on ISP), or logs in from another location
    – Lighty
    Nov 3, 2014 at 10:13
  • 1
    Agreed. And in case there is any doubt I was not recommending using IP addresses as identifiers!
    – R15
    Nov 3, 2014 at 14:13
  • This warning about IP-based blocking is very valuable, thanks!
    – Simple
    Nov 3, 2014 at 17:02
  • What I have not mentioned (because I thought it was not important) is that users would also supply the name of a resource they want to access (different users may share the same resource). So, perhaps the system could block not just IP, but a combination of IP/resource_name? Is this different from having users supplying their name and the system blocking based on IP/user_name?
    – Simple
    Nov 3, 2014 at 17:09
0

You've designed a Password Manager with less protection and usability than all the other mature products out there.

  1. The file needs to travel with the user.
  2. The password to access the pseudo-password manager is a 9 char password comprising only of digits.
  3. The pseudo-password manager file only works for a single login location.
  4. The file is not protected in any way.
  5. If the password scheme is known to an attacker, the ability to brute force the password hashes on the system becomes much easier.

Why not use an actual password manager? LastPass, Keepass, 1Password, etc? They improve on your system from the start.

Or MFA? A user could have a low-entropy password and still have protection.

Improve this answer
2
  • Thank you for your critique. Perhaps I can think of the ways to mitigate your points 1,3 and 4 in the suggested scheme. But not sure how to improve on 2 and 5... Also appreciate your suggestions about specific password managers -- I am still learning the password management.
    – Simple
    Nov 3, 2014 at 17:37
  • Perhaps another 'fatal' flaw is that the design assumes that the system delays next login attempts after a login failure. Yet if an attacker steals the password hashes from the system, then it would take a very short time to check the billion plain-text passwords against the stolen hashes.
    – Simple
    Nov 3, 2014 at 22:36

You must log in to answer this question.

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