To make the backup code work without sharing secrets, we use an algorithm inspired by S/KEY. We encourage you to store it somewhere safe. However, there’s still a way to sign in to Twitter even if you don’t have your phone or can’t connect to Twitter –– by using your backup code. The private key is only stored on the phone. And you can still sign in even if you lose your phone. Login verification is more secure and easier to use. When the request is verified, the polling will return a session token and the user will be signed in. In the meantime, the original browser will poll the server with the request ID nonce. If the signature is correct, the login request will be marked as verified. If you approve the request, the client will use its private key to respond by signing the challenge. At that point, you can choose to approve or deny the request. Within your Twitter app, you can then view the outstanding request, which includes several key pieces of information: time, geographical location, browser, and the login request’s challenge nonce. The request ID nonce is returned to the browser or client attempting to authenticate, and then a push notification is sent to your phone, letting you know you have a login verification request. Whenever you initiate a login request by sending your username and password, Twitter will generate a challenge and request ID –– each of which is a 190-bit (32 alphanumerics) random nonce –– and store them in memcached. When you enroll, your phone generates an asymmetric 2048-bit RSA keypair, which stores the private key locally on the device and sends the public key, which Twitter stores as part of your user object in our backend store, to the server. This means you don’t have to wait for a text message and then type in the code each time you sign in on. Simply tap a button on your phone, and you’re good to go. Now you can enroll in login verification and approve login requests right from the Twitter app on iOS and Android. Also, our updated login verification feature provides additional information about the request to help you determine if the login request you see is the one you’re making. This solution avoids that because the key necessary to approve requests never leaves your phone. Other previous attacks against two-factor authentication have taken advantage of compromised SMS delivery channels. We chose a design that is resilient to a compromise of the server-side data’s confidentiality: Twitter doesn’t persistently store secrets, and the private key material needed for approving login requests never leaves your phone. A weakness of these protocols is that the shared secret can be compromised if the server is compromised. For instance, OTP protocols use a shared secret modulated by a counter ( HOTP) or timer ( TOTP). Traditional two-factor authentication protocols require a shared secret between the user and the service. We think our new login verification feature is an improvement in both security and usability, and we’re excited to share it with you. Designing a secure authentication protocol is tough designing one that is also simple and intuitive is even harder. At Twitter, we want to make it easy as possible to secure your account.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |