1

When one enters a password to access one's online account, one has to type out the complete password, and submit it to be authenticated. If the password is very long, and if the account is accessed regularly, it will be very tiring to type out the full password over and over again.

Are there any schemes where the user types in a long password, and at every keystroke, the server checks whether or not the password provided so far is satisfactory? If it is satisfactory, the system logs the user in before the user finishes typing the password.

Do such schemes exist?

Flux
  • 683
  • 1
  • 6
  • 12
  • So in your suggested scheme, if the first keystroke is unsatisfactory (i.e. incorrect) the server would refuse? – techraf Dec 06 '16 at 00:11
  • @techraf: If the first keystroke is unsatisfactory, the user would have to enter more characters until it is satisfactory, at which point, he/she would be logged in. – Flux Dec 06 '16 at 00:33
  • 5
    So the number of characters you consider satisfactory is the length of the password on the system side. Your scheme is called "a shorter password". – techraf Dec 06 '16 at 00:35
  • 1
    Any decent authentication scheme shouldn't rely on the individual characters of the passwords. The user enters the password and it is hashed and then compared with the stored hash value on the server side. If it matches, authentication is successful. The scheme you describe is probably from a movie or something. If a real world system is using it, its authentication security is horrible. – void_in Dec 06 '16 at 04:52
  • If the password is becoming an issue, it may be time to look at passwordless authentication schemes. – jhash Jan 05 '17 at 15:20

4 Answers4

2

Not sure I understand exactly what it is you are proposing. But unless I misunderstand you completely it would be a security disaster:

  • If the server gives any kind of indication (if only just in the time it takes for it to respond) if an individual character was correct or not it makes the password much easier to brute force, since you can just do it letter by letter. You end up having to make l*n attemps instead of l^n, where l is the length and n is the size of the alphabet.
  • If the server lets you in after just half a password you have negated the whole benefit of having a long password. As techraf comments: Your scheme is called "a shorter password".
  • You can not hash the passwords if you want to be able to check them character by character. That makes safe password storage an impossibility. (Well, you could hash them a ltter at a time but then we are back at the brute forcing problem.)
Anders
  • 65,052
  • 24
  • 180
  • 218
1

No reason it can't be implemented. On the server side, just truncate the password to N characters before hashing it. On the client side, try to log in when the Nth character has been typed.

What is the point though? Such a scheme only signals to users that you don't respect their choice of security level when their password is long.

Also, what if a user has a passphrase that begins with a long word and you truncate to, say, 8 characters? Then it can be dictionary attacked.

DepressedDaniel
  • 1,240
  • 7
  • 8
  • 1
    I don't think this could work without storing hashes for all the combinations from 1 to length(password). If the hash of only N characters are taken, it won't match the hash that is stored on the server side. – void_in Dec 06 '16 at 05:11
  • 1
    @void_in, that's correct and not only would that be horribly insecure (you'd only have to break the1 char hashes!), it would also be horribly resource intensive. – Julian Knight Dec 06 '16 at 08:38
  • 1
    @void_in Well OP obviously doesn't want a user to be able to log in from the first character. While OP's question is poorly phrased, I interpreted it as wanting to be able to log in automatically when N or more correct characters are entered. – DepressedDaniel Dec 06 '16 at 20:42
0

Yes, such systems exist, but in a slightly different way than a typical user password. Microsoft uses a 25 character product key system, with characters grouped in sets of 5 characters. Each group of 5 has a checksum as its last character. This checksum allows the app to notify the user if they've made a typing error in that group, without revealing to the user whether or not the group itself is a part of the actual product key required to activate that particular product.

However, you cannot have a secure password checking system that validates on a character by character basis. Otherwise it takes an attacker very few iterations to discover the secret.

John Deters
  • 33,897
  • 3
  • 58
  • 112
-1

it will be very tiring to type out the full password over and over again.

How about using public key cryptography for this? You secure the auth form with a fancy 2048 bit RSA key, set it up once, and password protect it with an easier-to-remember password. An attacker would need access to your system to get your private key and authenticate himself. You add another layer of security, which compensates for the strength of your passphrase.

I personally think this solution is safer than having your password saved somewhere.

(Side note: of course you'd need to take they keys with you wherever you want to login from)

Rápli András
  • 2,144
  • 1
  • 11
  • 24
  • I don't think this really answers the question. It is more of a suggestion for an alternative scheme. – Anders Jan 05 '17 at 16:57