A conversation at Google about secrecy questions and answers

Here are some examples of q&A:

• Q: What’s your favorite food? A: Pizza. The answer is often pizza. Just by guessing the answer to this question, you can crack about 20 percent of your English-speaking users. Add ten more guesses and you can crack a third of the users who set the question. For Korean users, 43% of them can be cracked with less than 10 options.
• Q: What day of the week did you get married? A: Thursday is a user-defined question, but it has a fatal flaw — the average attacker only needs five attempts to crack the correct answer. And that’s not enough to test for brute force.
• Q: What city was I born in? A: In some countries, most people live in a small number of large cities. The list of possible cities can be narrowed considerably by looking at the language in which the ID validation user interface is used. With this question, you can crack 40% of your users.
• Q: What was the name of my first teacher? A: Mr. Smith, Smith, John, John S. Smith, John Smith, Jon Smth. These are all correct answers, but they don’t pass correctly. I provide fuzzy matching patterns for these questions, because the user’s answers are always so close. Matching logic usually requires some background to the problem (the “edit distance” algorithm by itself is not sufficient for things like street addresses). Good luck making your product multilingual.

Professional account systems do not use encryption questions alone to allow users to recover passwords. It’s just a reference. I give you less than a 2% chance of getting it through a sufficiently sophisticated mechanism. That’s why Google is phasing out the encryption problem and using text messages to recover passwords. Of course, SMS recovery has its own problems, but it is much better than the encryption problem.

5. Do not use verification codes

Captcha is a common feature on many login forms. I also did some of that work during my time at Google. Nowadays, however, captchas are of little value and enforcement rates are extremely low.

These captcha codes don’t help.

The first step is to properly understand captchas, which impose very simple restrictions on automated attacks. They do not protect your account system from the risk of bulk enrollment. In addition to account security, I’ve spent years researching registration abuse at Google. We’ve seen with our own eyes how easily spammers have solved tens of millions of captcha codes that we thought were too difficult. There are companies that specialize in captchas, such as DeathByCaptcha, that use optical character recognition and human recognition. A common captcha prevents blind users from registering, which is a real problem. Speech-based authentication and recognition is easy for machines but difficult for people.

Using captcha to prevent brute force cracking is helpful. Brute force cracking an account’s password can take hundreds of attempts, and an easy way to stop this is to start adding captcha after they’ve had a few failed attempts. In mechanical loops, even a simple captcha to slow down the process is sufficient.

Captcha is less effective at preventing bulk account registrations. Building a system to detect and prevent such phenomena is another task, and I’ve spent years working on it. To get a sense of how difficult this can be, go to Buyaccs.com and compare the huge margins charged by black-market account sellers. Accounts from sites with better defenses tend to charge higher prices. Unless you’re one of the Big 5, you can’t do more than us in terms of registration security, which is another reason I recommend outsourcing your login system to the major companies.

If you still want to use captcha, use reCAPTCHA and make sure your captcha is in the right place to avoid replay attacks. Don’t try to use a kit you made yourself or found on GitHub, such captcha is easily solved by modern optical character recognition (OCR) and does nothing but reduce customer registration success.

6. Outsourcing two-factor validation

Two-factor validation is a common feature these days. However, getting it right is difficult and expensive, and you don’t want to do it yourself.

• Text messages are unstable, especially in countries where recovery codes often fail to display. You might end up with a voice synthesis phone because it’s more stable, and now you need to consider a multilingual voice synthesis engine.
• A lot of text messages or phone calls can be a big expense, even if you can get deals in bulk.
• People may change their phone numbers frequently. If your password recovery process is based on an email address, this process will be easy. But once you introduce stable two-factor authentication, password recovery becomes a bug in your system. If you don’t fix it, attackers will have a much easier time cracking it. And it doesn’t work if you try to stop it.
• Two-factor authentication can be abused by attackers who add it to phishing or hacked accounts. This is to prevent a real user from retrieving the account during malicious activity.
• Phone numbers are vulnerable to porting attacks, so the trend is to require users to set up mobile apps or security keys. In order to implement this measure means more work, of course, neither of these may work, so you will eventually need some customer support process to help them recover.
• As you can see, two-factor authentication adds a lot of customer manual work because you no longer use encryption questions or email to recover the user’s password. And that’s expensive.

Some of these problems are fundamental, but most have already been fixed by someone who will pay for your phone and customer support for free

However, if you still don’t want to use their services, there are startups that can solve a small part of the two-factor verification puzzle for you.

7. Do not force users to change their passwords

Troy explained this very well, so I’m not going to repeat it here, but again, it’s important. Don’t ask users to change their passwords just because they’ve been in use for a while.

• Some users may not make it through the process, and you may lose some users.
• Users are smarter than you and will change their passwords (once, twice, three times) and then immediately change them to their old passwords, which means you need to store a history of your most recent passwords to prevent this. But I bet you won’t.
• This does not increase security.

8. Do not set a validity period for the session

Yes, this is another bad “best practice”. Expiration dates for session cookies are often thought to increase security for the same reason that expiration dates for passwords are thought to increase security.

• Attackers tend to start malicious activity immediately, so setting an expiration date is not very useful.
• The session expiration setting makes users accustomed to unexpected password prompts, which makes them vulnerable to spoofing.
• The randomness of the storage expiration period can create a lot of bugs, which can lead to your developers spending a lot of time fixing bugs. Most of the code on your site should not be able to handle that, in the middle of an operation, the session you’re using expires, so you have to go back and fix it, if you can find it. The randomness of user reports makes it harder to track down errors.

9. Log out

In immature account systems, logout errors are very common. It sounds simple enough, but the accepted way of doing this is flawed.

• It’s convenient for users to simply delete session cookies, but that means you can’t recover from a cross-site scripting attack. Once a “cross-site scripting attack” is detected, you might want to invalidate session cookies that might be stolen, but this is not possible if the logout simply “asks the browser to remove the cookie.”
• Add the timestamp to the session cookie, then set the last Logout time, and each operation requires checking the account database to see if the user’s session is too old. This can lead to slower operation responses, meaning developers will need to optimize for this (which doesn’t seem to matter, after all). But if they remove the check for a port of interest to the attacker, the problem you encountered in step 1 will recur. In addition, this means that by exiting a browser or device, all users will be logged out, which is not the desired behavior.

The correct approach is to use an in-memory cache to hold a list of expired session cookies. However, for most companies, there is a cheaper and good enough alternative: make the user’s exit link only a way to clear session cookies, which can then be expired and automatically renewed every five minutes. The behavior of replacing expired session cookies can be queried by querying the database to see if the administrator has forcibly logged out the account. If the user displays an expired cookie, he needs to log in again. This means that cookies are less likely to be stolen after they are cleaned.

10. Separate account email from marketing email

Typically, we use the company’s main email server to send users a password recovery link, login verification, and so on. However, some people in your company will “connect” with users by sending them commercial emails that they don’t want to receive.

Even if users agree to receive such messages during account registration, most of them do not want to receive such messages again, and some even report them as spam. The savvy users know, this is a very convenient solution, simply click on the “report spam”, can make those nasty E-mail disappeared, without having to spend effort in looking for the use of tiny font write “unsubscribe” link, or exert to write an email filter.

Unfortunately, this kind of behavior will reduce the credibility of your email domain. Messages sent from your account system will most likely end up in the user’s spam folder. That’s why we see reminders like these asking us to check the spam folder during the registration or password recovery process.

One way to get around this is to buy a separate top-level domain to send emails and make sure that email verification standards are met. However, some users may notice a domain name mismatch and report your email as phishing. The best solution is to send your marketing email using a domain name with a different email verification standard, but your product people may not approve. So, again, the moment you choose to do it yourself, you also suffer.

11. Protect your password database

Once you have a password, your database becomes a target for attackers (and they often succeed). They’re not interested in your company, they just want passwords so they can try higher value targets. So, data breaches are a serious problem, and while the direct impact on customers may not be that big, they can lead to serious consequences. Databases that use the OAuth protocol are of little value to attackers and therefore less likely to be attacked.

conclusion

I could write a lot more about account systems. Protecting your site from malicious accounts could be a book in its own right. I can’t write the book, but if you’re interested, check out this video, which is an interview I did in 2012.

To be honest, this may seem like a huge undertaking, but it’s not. So I always advise you to stick with it and outsource your account management to big companies. Because your main business is not worrying about messing with captcha codes, or writing design documents for logging out, or diagnosing why you lose users who forget their passwords, or why sending messages to Peru is unstable. Every penny you spend on these things, for those competitors who offer “use third-party login,” they are spending it on their core business.

So don’t look back and give up your password database.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, React, front-end, back-end, product, design and other fields. If you want to see more high-quality translation, please continue to pay attention to the Project, official Weibo, Zhihu column.