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?

klenex
  • 159
  • 1
  • 5
  • 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 '17 at 15:33
  • Sure, this isn't implemented yet, so let's say it is longer than 10 digits long. I use the mersenne twister random number generator. Let's say user makes a post, only the three words would have to be stored. Every time a user does something the hash is recalculated to get the username. That way no login credentials have to be stored. – klenex May 13 '17 at 15:37
  • 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 '17 at 15:39
  • so when a user is doing something for the first time the user can enter in any username and password. This username and password is used to generate a hash. The hash is used to generate three random words. When the user wants to 'log back in' the person just uses the same username and password that way the same three words are generated. Using this system no username or password has to be stored, just the three words attached to a post. – klenex May 13 '17 at 15:46
  • 9
    @klenex: Essentially you are inventing your own key derivation function based on user name and password instead of using an [established KDF](https://en.wikipedia.org/wiki/Key_derivation_function). See [Why shouldn't we roll our own?](https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own) why this is usually a bad idea. – Steffen Ullrich May 13 '17 at 15:51
  • @SteffenUllrich I'm not sure how this is considered a KDF. Do you have a suggestion of a library that does exactly what I'm asking for, so I don't have to build it myself? – klenex May 13 '17 at 15:57
  • 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 '17 at 09:38
  • 2
    It also seems like the approach won't let someone change their password without invalidating their identity. – tangrs May 15 '17 at 01:13
  • This seems like a terrible idea, there is a reason the standard models have become standard, it is usually because they are the best (feasible at the time) approach. When it comes to security you do not want to be trying new radical things because they usually don't work and alot is at stake with security – Milney May 15 '17 at 08:33
  • So what happens if two users supply *john* as username and *123456* as password upon registration? They are both mapped to the same passphrase? – Hagen von Eitzen May 15 '17 at 09:32

4 Answers4

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.

tim
  • 29,018
  • 7
  • 95
  • 119
  • 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 '17 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 '17 at 16:53
  • The problem with storing the hash from the beginning is that it's not user friendly. There must be a way to derive words from the hash in a secure way. – klenex May 13 '17 at 18:03
  • @klenex: So you’re trying to create a memorizable string from a username and password (two memorizable strings)? Or is the real case converting a random id/key to words? – Ry- May 13 '17 at 18:13
  • 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 '17 at 18:21
  • @tim https://en.wikipedia.org/wiki/Imageboard#Tripcodes it's similar to this. Maybe wikipedia has a better explanation than me. – klenex May 13 '17 at 18:54
  • 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 '17 at 19:13
  • @tim this is only true if the order of the word list is known. Since it is unknown and there is a global seed, people would have to use the site to try and guess display names. Since there is a captcha and spam filtering this is very hard. So overall does it sound okay? – klenex May 13 '17 at 19:24
  • @klenex I would say it depends for what this is used. You may want to ask a new question with a detailed description of the process (including how it is actually used; at least tripcodes should be mentioned, but a bit more description would be good) and a vague description of the sort of website this is used for, and the security goals you have (eg this is for a video commenting system and you would prefer if users don't imitate each other vs this is for high-profile government officials who should never be impersonated). then ask if the process is secure enough for that use-case. – tim May 13 '17 at 19:30
  • 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 '17 at 19:31
  • @tim https://security.stackexchange.com/questions/159433/is-this-tripcode-system-secure – klenex May 14 '17 at 15:33
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.

Charles
  • 161
  • 3
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).

Tom
  • 10,124
  • 18
  • 51
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".

Buge
  • 169
  • 5
  • how would their account be hacked? This makes little sense. – klenex May 14 '17 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 '17 at 21:02
  • No, they don't have to remember their three words. It is generated with the username and password they enter. https://security.stackexchange.com/questions/159379/is-this-passwordless-system-secure/ – klenex May 14 '17 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 '17 at 06:44