8

I'll take Twitter as an example.

On one hand, when registering on Twitter, the password must contain at least 6 characters.

On the other hand, access token to the API have about 50 characters:

enter image description here

(source)

I'm wondering about the security reason behind this difference in length. If the tokens are really long because it improves security, why are short passwords allowed? Please note that I'm not asking why the minimal length is not a given number like 10, 15 or 20 characters, it would still make a great difference compared to tokens.

And while this token is hard to guess because it's random and longer, I can see my own tokens by connecting to the Twitter developers website with my relatively weak password. Why create a secure random token if it's accessible with my password? I know that it's possible to activate the two-factor authentication but the access to the developers website doesn't require it.

So, given the facts that:

  • a token allow more or less the same operations than a logged in user though its password,
  • accesses to API can be brute-forced as accesses from Internet,
  • Twitter can choose the minimal length of a password and the length of tokens,

why are tokens so long? If from Twitter's point of view 6 characters are enough for a password, why use 50 characters for a token?

A.L
  • 301
  • 3
  • 12

5 Answers5

19

Quite simply, the token is not designed to be memorized so it can be as long as they want. A password is limited in length to what a person can practically reliably recall after a short memorization period. This limits it to 7-10 characters for most people. The token is designed to be copy/pasted, just once even (since it is application specific) therefore there is absolutely no penalty to being long, and the great length allows it to be both secure and unique (i.e. the token can have enough embedded information to tie back to a specific account).

I suppose a more pointed question would be, why aren't passwords longer ;-)

Jeff Meden
  • 3,976
  • 13
  • 16
  • 3
    The short answer to your pointed question would be "because we've been conditioned to use passwords that are easy to guess and hard to remember". https://xkcd.com/936/ – Cronax May 13 '16 at 06:46
  • @Cronax you're right, but honestly even if you just get them to choose something besides 123456 or qwerty you are winning at security. There are worse passwords to choose than random (if short) ones, and that would be these http://www.passwordrandom.com/most-popular-passwords – Jeff Meden May 13 '16 at 12:27
13

There are several reasons for that.

One reason is that memorable passwords are too short for the expected security level. Several methods are used to mitigate this problem, but it would be problematic to apply them to access tokens:

  • Some services require a second authentication factor. Access tokens are meant to be used without user intervention, so most other forms of authentication are out (they would either be inapplicable, e.g. biometrics, or they would only result in a second access token).
  • Online services protect against brute-force attacks by imposing a delay between authentication attempts. This is problematic because it can lock the legitimate user out and because it's an extra implementation burden.
  • Password storage uses slow hashes. This costs a lot of CPU time. If a long enough access token needs to be kept secret and stored in hash form, no special precaution is necessary. Likewise if a key is derived from an access token.

Another reason is that the length of access tokens is typically decided by the author of a protocol or library, not by the author of the service(s) that uses them. The cost of making an access token longer is usually marginal. So the length is set at something that gives the highest security level that anybody requires. You're comparing the access token length with the minimum password length, but a more apt comparison would be with the maximum password length.

Some services use access tokens independently of accounts (i.e. as sessio cookies rather than as authentication parameter that is combined with an identification parameter). There can also be many access tokens for a single account with different privileges. So the access token needs to have more entropy to keep the probability of collisions infinitesimal.

Community
  • 1
Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
  • Hashing of tokens is actually very common, or more likely _should be_. Every system allowing for password reset links, should store only hashes of the tokens, otherwise a successful SQL-injection would allow an attacker to take over every account he wishes. Good answer as always. – martinstoeckli May 12 '16 at 19:08
2

If you need to store relatively short passwords, there is a bunch of precautions you have to take:

  1. Salting with a unique long enough salt to prevent rainbow-table attacks.
  2. Key-stretching so the calculation needs some time, to hinder brute-forcing.

On the other side, if the token is long enough you can store just a plain SHA-256 without any drawbacks on security. These are the advantages:

  1. There is no need for salting. In contrast to salted passwords, the token-hashes can be searched for in a database. So if you got a token you can hash it again and check with an SQL query if the token is valid.
  2. The calculation is fast and light on the servers cpu. While we needed a lot of cpu power to hash passwords because of key-stretching, hashing of the token is lightning fast.
martinstoeckli
  • 5,189
  • 2
  • 27
  • 32
0

In the case of an application I recently wrote, the access token is a symmetrically-encrypted string of the form

nonce=123456789;userid=123;username=bob;login_expires=12345679;...

The encrypted string is the cookie and is quite long. Decrypting it is fast, and assuming no one stole the secret key from the server, the data is authentic.

spraff
  • 315
  • 2
  • 9
  • Yes, when tokens are long, it can be that additional information (like a user ID or which permissions they have) is stored in them in a strongly encrypted form. It can be more efficient for a system to decrypt the token to access this information than to query a database for it, especially when the API is stateless and doesn't require a login, but validates the token on every API call. –  May 13 '16 at 06:59
  • I would recommend storing that information in the database together with the hash of a random token, unless you *really* need the performance advantage of stateless authentication. Encryption is subtle and easy to get wrong. For example in your case the `nonce=123456789` part is a red flag. If the encryption is used correctly, it's completely pointless, because the encryption already includes a nonce or IV. Also people often get the integrity checks wrong, enabling decryption and/or forgeries. Finally why encrypt it at all instead of using merely a MAC, you don't need confidentiality? – CodesInChaos May 13 '16 at 11:37
  • 1) Yes I want the performance advantage. 2) the nonce is indicative, I use PHP Sodium which includes a nonce. 3) Yes you've got to be careful, I researched modern best practices before implementing my solution. 4) I need confidentiality. But thanks for raising these issues all the same. – spraff May 13 '16 at 11:43
0

Tokens are used to access APIs programmatically; passwords are used by users typing them in.

Brute-forcing of passwords is prevented by strategies like splitting up the typing of username and password to two different pages, adding secondary input fields like captchas, and forcing a waiting period (or disabling the userid) after some number of unsuccessful tries.

Meanwhile, tokens are used without all these mechanisms and must withstand API access attempts running at full speed. Therefore, to prevent brute forcing they have to be much longer.

So, in other words, a short password plus defensive strategies gives you the same security as a long token.

Tom Hundt
  • 101
  • 1