The results of the study of authentication methods and some mechanisms of protection against WEB-attacks on the example of Google, VK and others

What is the topic?

In this article I will talk about the implementations of different functionalities (mainly on web services) to ensure the safety of users on the example of the “giants” of the modern IT industry. This material will be useful to developers, architects, team leads and managers in setting tasks of similar functionality. The implementations in the article were developed by teams of professionals, tested by time and hundreds of millions of users (as well as by a large number of hackers), although there are no guarantees that this particular implementation is absolutely correct and 100% safe, of course not. Information is based on personal analysis of these resources.

Authorization

The most successful and interesting option is implemented in VK. Described in brief here . The password is entered on the main page of the site, but the action of the form leads to the subdomain (login.vk.com), a cookie is set there for the current domain (login.vk.com) and for vk.com (remixsid). If something is wrong with the cookie on the “main” domain (changed, the last IP did not match, etc.), a redirect to login.vk.com automatically occurs. And if the password was actually entered in this browser, then it will have a persistent cookie (which was set when entering the password), which will be used for automatic login. If it is not there (for example, cookies were taken away via XSS), then it will not allow your account. There is also a record of the latest active sessions - 6 pieces, which are considered “alive” and which can be completed in your personal account, which is very convenient. Google also has a separate domain for authorization. And since it has a lot of different services, then the authorization also sends a list of services, where to start with these cookies.

Two-factor authentication

They talk about it to the left and to the right and in the general case it is customary to implement OTP by sending via SMS. Take Google again as an example. And the first problem: the connection is not available, what should the user do? To do this, we implemented two solutions:
')

• Offline generation of OTP through the application on a mobile device. The first step is the synchronization of the website and the mobile application by entering a special code. After the passwords on the server and on the mobile phone are matched in time (it is better that the phone is synchronized via NTP). Those. On the mobile device, offline, the password is displayed, which is suitable as an OTP (every minute - a new password). As a result, anywhere, with a working mobile device, we can log in without receiving an SMS / receiving a call from Google.
• One-time, already generated, passwords. On the accounts.google.com/b/0/SmsAuthSettings page, you can retrieve and print passwords that will always (once) come up when you request an OTP code. Can be printed and put in wallet

Authorization of Google employees on their internal portal login.corp.google.com also happens with the use of two-factor authorization, but you can also use usb-token (analogy with banks) for authorization.

What to do if your service provides an API for mobile devices? And some applications running outside the browser are incompatible with two-step authentication and cannot request verification codes? Here, following the example of Google, we solved the problem as follows. You can generate an "application password" . The name of the application is entered and the one-time issue (nowhere and never is displayed) is the password for the application, which must be entered instead of the password.

Password recovery

The logical continuation will be this item. Using the standard scheme with the expulsion of a link to the mail, what is better to do, generate a new password yourself or give the opportunity to enter it to the user? In general, the second method (Google) is preferable. But if you decide to use the first one, generate a password with at least 7-8 characters (letters / numbers / at least one special character). Literally the other day, I analyzed a table with users and passwords, where the password was set automatically (md5, 6 characters, [a-zA-Z0-9]). And for a penny got them in pure form. Anyway, it is recommended: sha * and two "salts". (Ie kind of sha * ($ stat_salt. $ password. $ email)), i.e. when, with a full database dump, no password will still be able to be decrypted, since the static “salt” (which, for example, is protected in the code) will be unknown. But this is a topic for another conversation.

It is also important to understand that it is also necessary to implement it correctly. Example: Facebook, last year. Password recovery via SMS. They send us the code on the phone, we enter it and change the end user id in the form. As a result, we change the password to any user. How could you not check the user ID, which we change the password? How was it possible not to match the sent code in SMS and user id? Epic fail.

CSRF Protection

Protection against CSRF correctly implemented using the "hidden" tokens (<input type = "hidden">). But how to generate them correctly? Google, at each authorization, issues a token to the session and stores it in a cookie. Those. looks cookie, looks what came in the form, if everything is ok - we work further. That is, one token for all actions in a single session. It is wrong to ask the user if there is a mismatch of tokens, whether he really wanted to perform this action (“hello” to the service developers who just recognized themselves in this article), as this is very doubtful (the user can click the machine) + there are workarounds for such “clarification requests” ". Vkontakte acted differently - they generate one token for each action, which is based on the current user id, action id and some “target” id (user, community / public number, etc.). But, unfortunately, it is not checked everywhere.

Separate content domain

All user content needs to be uploaded to a separate domain. This can save from a variety of threats. Google has googleusercontent.com, VK has vk.me. Using the example of an XSS article iOS device using the example of software from Facebook, Google, VKontakte , when the “feature” of an entire platform for exploiting a vulnerability cannot do any harm - another indicator than a separate (isolated, no cookie) domain for user content is important .

Content Security Policy

Now many resources are actively developing with CSP. For example, Yandex recently implemented a version of mail with full CSP support. CSP is a header that tells the browser where it comes from (from what addresses) and what content (pictures, scripts) can be downloaded. As a result, when an attacker even finds a way to conduct an XSS attack, he cannot send any data directly to another server, or even execute inline scripts. Of course, there are also workarounds, for example, you can generate a picture and embed js into it and, if possible, upload it to one of the allowed domains. And refer to it <script src "... image.gif>, an example .

HSTS

Speaking again about the HTTP headers ( article ), it is impossible not to mention the HSTS . It's one thing just to send it.
Another thing is that there is a pre-shared sheet in Chrome and Firefox, among which are listed the domains that must be visited via HTTPS - src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json .
You can send a request to add your resource in the mail

Accounts on 3rd-party resources

Quite often (and sometimes necessary) to use the services of other services (domain registration, monitoring, etc.). And it seems like there is a cycle (for example, once every 3 months) when the password is changed on all such resources. Good practice.

Perhaps somewhere else the “giants” (I have no information) use VPN access to work resources (frequent practice and in small companies) and some other protection mechanisms. If you know those - share in the comments :)

upd: It is possible that Apple uses VPN.