14

A person has a form that asks for a name and password. The password is sent to the server where a hash is created from hashing the name and password. This hash is converted into a number using the ascii value. The number is limited to 10 digits, and is used to seed a random number generator. Three random numbers are generated from 1-77616. These numbers are used to select words from a list of 77616 English words. The three words formed are used as the persons username.

77616^3 is roughly 2^48, so the probability of a collision after a million username generations should be ~0.001774778278169853.

Does this seem like a secure way to manage users, that way a login/register system doesn't have to be implemented? Is there any benefit of using this kind of system over a traditional login/register system?

Improve this question
10
  • 9
    This doesn't seem secure. The rng is a pseudo-rgn, right? So the place where collisions will happen are already at the limited 10 digits. And can you describe the practical procedure a bit more? A user registers with username and password, the server does something, but what happens then? How does the user authenticate themselves? Just with the generated username, but without password? And why do you think that this isn't a registration system, if the user has to enter name and password?
    – tim
    May 13, 2017 at 15:33
  • 3
    It's still not clear to me. Can you describe what a user has to do when 1) doing something for the first time (eg enter new name, etc) and 2) doing something later again (you somehow need to authenticate the user, right? So the user does what? Login with the three generated words?)
    – tim
    May 13, 2017 at 15:39
  • 9
    @klenex: Essentially you are inventing your own key derivation function based on user name and password instead of using an established KDF. See Why shouldn't we roll our own? why this is usually a bad idea.
    – Steffen Ullrich
    May 13, 2017 at 15:51
  • 1
    OP, you are using various confusing words to name your fields. Maybe if you named the fields as usual, the confusion will be less for you, less for us, less for users. User while registering provides username and some seed and in return receives a static passphrase. User while entering the system provides a passphrase and not username. Voila.
    – kubanczyk
    May 14, 2017 at 9:38
  • 2
    It also seems like the approach won't let someone change their password without invalidating their identity.
    – tangrs
    May 15, 2017 at 1:13

4 Answers 4

Reset to default
35

No, this doesn't seem secure.

Collisions

Mersenne Twister is a deterministic RNG, so it's not suitable for most cryptographic tasks (although it's usage makes sense, because if it weren't deterministic, your approach would of course not work).

In this case, collisions would not happen at the stage you assume and base your calculations on. Instead, they would happen when you limit the ascii value to 10 digits, so the probability of collisions is way higher than you assume.

Comments on Approach

What you have is basically a home-made hashing function. You take some input, you apply some function(s) to it, and receive a fixed-length (3 words) output. The input space is larger than the output space, and it is impossible to reverse the procedure (get the password from the three stored words).

Don't roll your own and Don't be a Dave apply. To properly hash passwords, see How to securely hash passwords?.

You are still implementing a login and registration system (a user needs to enter username and password, you store it in some form, and can then later compare the stored value to newly entered values to authenticate the user).

If you would stop at this step: "The password is sent to the server where a hash is created", you would have an ordinary process. But instead, you add additional steps, which do not increase, but decrease, security.

Improve this answer
11
  • 1
    The username and password are never stored. Also, the limit can be increased to 20 digits. I'm not trying to argue in favor of using my system, just trying to get a clearer idea of why it's not secure.
    – klenex
    May 13, 2017 at 16:04
  • 1
    @klenex They are stored in some form, just not in plaintext; instead, they are stored as a form of hash (they have to be stored in some form, otherwise you wouldn't have something to compare values submitted by a user to authenticate them). And sure, you could increase the digits to 20, but it's still low. I'll let someone else do the math, but 10 digits should be approx. equivalent to a 32 bit hash, 20 digits approx. 64 bits. For comparison, md5 is 128 bits, sha1 160 bits. You could increase the size further, but there is really nothing to gain from it; just store the hash from the beginning.
    – tim
    May 13, 2017 at 16:53
  • 6
    @klenex Then maybe I'm still not quite understanding how exactly you want to use this in practice. I don't see how a hash is less user-friendly than words. Neither is actually seen by the end-user, who in both cases would enter their password, not the hash or words (if they would do that, you would have a pass-the-hash issue; it also just wouldn't make much sense. If the user sees the words, there really isn't a good reason to derive them from the password in the first place; they could just be randomly generated).
    – tim
    May 13, 2017 at 18:21
  • 6
    @klenex so the result is actually shown to the user? And instead of a result that looks random, you want words instead, so it's easier to recognize? I think I understand now, but that is really important information that is missing from the question. In that case, I also wouldn't worry about collisions so much, but about bruteforce speed. If you basically display the hash of each user, it will likely be very easy to crack a considerable amount of hashes, and thus impersonate other users. Depending on your security needs this may be ok (in which case increasing to 20 digits should be fine)
    – tim
    May 13, 2017 at 19:13
  • 3
    @klenex (I suggest a new question instead of editing this one, as the changes would change the question considerably; it's basically a completely new question).
    – tim
    May 13, 2017 at 19:31
6

You start with a username + password hash, with the latter hopefully being a cryptographic hash with at least 256 bits. Then you turn it into a 10-digit number, throwing away all but 33 bits. You then use this as a seed for a pseudorandom number generator to compute a 48-bit key of words, but the information is already lost -- you can't stretch 33 bits into 48 bits, there will only be (at most) 10^10 possible choices for the three words. So your method, even if well-implemented, gives up a lot of entropy for no benefit. You might as well require that users have 7-letter passwords without uppercase or symbols.

Improve this answer
3

Aside from mathematics, your system is insecure due to user assumptions. Ordinary users do not generally treat their username as a secret. Most systems do not hide it from other users (e.g. on this very site we can all see each others user names). Your users will have no inclination to not sharing it, and will not understand that you are logging them in through this username (they will naively assume there's a cookie or certificate or something that's doing an automatic log in).

Improve this answer
3

No, you have not eliminated the password. You have eliminated the username, then renamed the password as the "username". Since you are calling it "username", your users will assume "this is my username, I can share it online with my friends", and boom their account gets hacked.

Do not make security rely on the secrecy of a "username".

Improve this answer
4
  • how would their account be hacked? This makes little sense.
    – klenex
    May 14, 2017 at 14:55
  • 2
    @klenex Because you've said that the system is passwordless, so presumably the user should only remember the 3 words, which is now their username (so they don't remember any other username either). And presumably your users will only enter those three words when they want to authenticate. Basically you have randomly generated usernames and no passwords, and if a user shares their username with anyone else, that other person also has access. Alternatively you have randomly generated weak passwords and no usernames, which means coincidental collisions gives you access to a random account.
    – Thorbear
    May 14, 2017 at 21:02
  • No, they don't have to remember their three words. It is generated with the username and password they enter. security.stackexchange.com/questions/159379/…
    – klenex
    May 14, 2017 at 21:13
  • 3
    I'm confused. In your original question you said that the 3 words are the person's username. Now you are saying that the 3 words are separate from the username. I'm also confused about whether or not the password is entered at login time, that was not specified in the question.
    – Buge
    May 15, 2017 at 6:44

You must log in to answer this question.

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