Is storing a permanent access token as good as storing password?

Question

如果我想保留用户的登录信息，以便即使在例如闲置1年后也不必重新登录，则存储永久访问令牌与直接存储密码（可能是哈希值）一样，因为（永久）访问令牌本质上是“替代密码”？

Answer 1

Storing an access token is surely safer than storing the password directly, but let's see why:

1. An attacker can only get this token, but not the original password. This is better, because passwords are often reused on other sites, and/or can reveal password schemes. ➽ Make sure the token is random and not derrived from the password.
2. The token is not just another password. While passwords choosen by a user are often weak, a token is very strong. They are so strong, that brute-forcing is impractical. ➽ Generate random, long enough tokens, they should be at least 20 characters az,AZ,0-9.

Answer 2

Generally speaking, yes. But , with a lot of caveats.

A long, random token, generated by a CSPRNG (this is very important, there are different ways to generate "random" strings and not all of them are really random), is stronger than a password - yes. However, the way you intend to use this token means that it is effectively a password by itself, and that means the same criteria applies:

• It can't be permanent.

  A key property of passwords is that they are not constants and users can change their passwords when stolen, or otherwise over time. Any kind of token should be no different, except that it should be automatically changed (rotated) by your application, on regular intervals.

• It MUST be hashed!

  (with a strong algorithm: bcrypt, scrypt, Argon-2I, PBKDF2; anything else is plain wrong)

  Don't ever store user passwords in plain-text format, anywhere. Even if it is guaranteed that the user doesn't use this password on any other site, a plain-text password means that anybody who gets their hands on the database (even for a brief time), can hijack user accounts.
  You have a responsibility to protect your users not only from "hackers", but from yourself as well.

• Don't store it in a cookie, even if hashed or encrypted.

  The way you've worded the question implies that you would do something like this. Cookies are not a secure location to store passwords of any kind. Temporary, short-lived tokens - sure, but not passwords.

It looks like you're trying to design your own authentication protocol, which is not an easy thing to do. It may be easy to make it work, but that's about 5% of the job; there's just too many details to consider. And all of this, for the tiny benefit of saving the minor inconvenience of a user typing-in their password once in a while - people are used to this; it's not worth the security risks.

In case you are hell-bent on providing long-lived logins, I would recommend using an existing authentication protocol. Every such protocol uses on cryptographic signatures, avoiding reliance on user passwords altogether and thus eliminating all of the above problems almost entirely.

Personally, I would just allow the so-called "social logins" - via Facebook, Google, Twitter. You wouldn't have to handle passwords at all, and anybody can login with a single click of a button.

Answer 3

存储访问令牌比存储密码或哈希密码更好（总是可以尝试通过蛮力找到密码），并且我认为您应该终身赋予令牌。

Answer 4

Although the answer is yes, but it also depends on the place you are storing the token. And you might want to auth the user with XSRF/CSRF token as well along with the token.

But storing token is better than storing password.