1. Needs a very long-lived session to be convenient. Elsewhere they note their's is a whole year. That's a long time to go without reauthenticating a client!
2. Authentication is or should be a much more common event than recovering a lost password, and now that's totally dependent on your email provider. One concern is latency.. a minute can feel like an hour while waiting to log in to your account to do something urgent. But also worrisome is provider downtime, spam filters, etc. all can block you from accessing your accounts.
Of course the way they "deal" with #2 is by just trying to avoid authenticating you very often (#1), which is not a generally-applicably awesome security practice. Might be ok in some cases but I wouldn't classify that as an overall "better" way to sign in.
I think a better way to solve this is at the browser/OS level with built-in password generation and management. And that's actually a third drawback to this approach.. it's incompatible with password managers.
I agree. It is also the only method that can guarantee backward compatibility with the millions of existing websites that are not going to move to a different auth method anytime soon.
KeePass, LastPass, et al. have done a tremendous amount of work to make the experience as seamless as possible, but there are still a lot of rough edges because every website has different policies. If most websites agreed to accept strong passwords of a standard format (e.g. 32-byte string of ASCII printable characters), we could finish the automation and just treat passwords like any other key that websites exchange with us all the time.
About a year ago, I proposed that we should come up with a standard login API for websites to adopt, in order to improve the password manager UX . There was quite a bit of discussion, but unfortunately the world seems to be much more interested in getting rid of passwords altogether, no matter how unrealistic it might be. Well, can't blame them, it's always more fun to create something new than to fix something that already exists.
The solution they have isn't an authentication system. It is a system that relies on an existing authentication system (your email provider's system) to work.
This is essentially the same as OpenID Connect: you really log in with your email host, be it Google, Yahoo, whatever. It is better, because your websites don't have to support the use of a dozen different vendor-specific login buttons.
But the real authentication happens when you enter your password to access your email.
Therefore, when I read:
> I think a better way to solve this is at the browser/OS level with built-in password generation and management.
All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there?
We can have a world where identity is federated through your email account. We can also have a world where it is federated through your browser account. They are fundamentally similar, and I have no way to know which of Gmail or Firefox Sync are more secure, but I do know that they're both inconvenient as is.
Gmail keeps nagging me about 2FA, a very bothersome way to log in (since I don't often have my phone), and wants me to have a backup email address for recovery purposes (which I cannot accept from my main identity holder because, well, it is the main one).
Firefox Sync doesn't enforce the use of a master password for all users, which can easily give the appearance of security. Besides, it won't always detect password fields and won't auto-login when it sees them. In addition, it doesn't have the (UI for the) ability to switch users on the browser — you need to use a private window for that, but then your passwords are still shared with other users. Finally, it doesn't generate strong passwords for you (which makes sense, most websites offering a password have stupid rules).
From the website's side, implementing a login solution relying on an existing email provider is way easier and more secure than relying on your browser's Sync system.
So, is it really a better way to solve this? Not currently.
1. The majority of my accounts are tied to my email account. Now, I can't easily change email providers; I'm locked in, for the most part.
2. Email is slowly dying and will be mostly extinct before long. Most people under 20 don't use email except for authenticating with web sites. Email was traditionally used for asynchronous one-to-one (or one-to-many, in some cases) communication. But, new services have risen that do this better.
3. The near-ubiquitous rise of mobile and smart phones: although you may not have a phone nearby, my phone is pretty much the only thing that I always have with me or nearby. So, I want sites to authenticate me with my mobile device, not email. I see mobile device (an identity proxy) becoming more ubiquitous, not less.
4. But, sometimes I want to authenticate anonymously.
5. I don't want to have to trust my email provider (or any 3rd-party provider) to safely and privately store my account information.
6. And, if I lose or break my phone, I don't want to lose my identity - I want an easy way to encrypt and store my identity at multiple backup locations.
Although, sites that uses 2FA usually don't ask for the phone code very often. They use it more to authenticate the device you're using. If it's your home computer, you only use the code once every month or so.
2FA feels like a chore before you actually uses it. I know because I resisted it for a few years. Now I complain when a service doesn't have it. :P
It's not just about trust. There are also a significant technical drawbacks to piggybacking email for authentication, namely the two I mentioned (security/convenience and reliability).
You should take a look at iCloud Keychain. It does a better job at tackling some of the drawbacks you note with Firefox Sync, especially when combined with Touch ID as a more convenient master password.
For a lot of sites I use with low frequency my login procedure is basically just reset password, and login with new password.
1. It generates at least 3 new database transactions each time it happens, not to mention the associated crypto requirements and email.
2. This password recovery system is a common attack vector and vulnerable to social engineering attacks and MITM attacks.
3. It is mostly obviated by the existence of password managers. For those with the knowhow to do this sort of thing, all of this sort of stuff should be happening on the client side.
I don't think that this scheme is for any site ... banking sites just want to be more secure... but it is very much better, than setting pw="123" on all websites, you don't care to much.
BTW: I also described a similar idea some time ago in a blog post:
After I wrote it, that such ideas where discussed at HN even some time ago.
I made a small program to access Google Keep automatically. Because I was too lazy to implement proper authentication, I just hardcoded my session keys. The app is started from a different IP, using a different user agent and is STILL able to access the site after weeks!
(Nowadays I have proper authentication in there, but it’s still worrying that stealing sessions from Google is so easy. Especially because some Google services submit their sessions keys via HTTP, without SSL)
If you really wanted, you could shorten the session lifetime and automatically renew it upon each use, perhaps up to some limit.
One could bridge that gap by adding two headers to the authentication emails - one containing the URL where the sign in request originated, and one with the sign in URL that must be visited.
A browser extension could then check your emails, and if an incoming mail matches the sign-in page of the current tab, log you in directly.
The idea of using email for password exchanges is fraught with difficulty, and not only because there's a lot of terrible email providers that don't even support starttls on their mail servers. Net-savvy people have fought a war to have HTTPS implemented across the web, can you imagine how hard it's going to be to get people to fight for implementation of security they can't even see? Ask your nearest non-technically minded friend if he knows if his email is encrypted in transit, and then ask him if his bank website is.
Someone elsewhere in the thread mentioned they'd only just started using key-based SSH login, and how it seemed to them the best thing since sliced bread. Extend that a little further with keyphrase protected keys and ssh-agent/pageant/whatever macs use, and you have a much, much better platform than "emailing a temporary password."
The problem I see with implementing something like that is getting it off the ground.
I consider my inbox as a notification pool where anyone and anything can send me a message. Now what I would love is different sets of tools/UIs that let me interact with each notification in the right manner.
Example both a newsletter and a my bank statement can come, however the view and actions would be entirely different.
I will admit that not being responsible for storing passwords was one of the reasons I used it. I'm by no means a security expert; one less thing I can screw up seems like a major plus.
Enter email to signup -> link gets emailed.
Enter email to login -> link gets emailed.
I use JWT for this and it really makes it easy to get started on the part of the project that matters... and sometimes (not always) I think it's probably going to be fine to leave it this way.
To your second point. Yes, this is true. But this is improving . I'd add that forgot password functionality carries the same risk, and I'd add that the more likely chance of your password being 'discovered' is by brute force or a website hack storing passwords in plain text - rather than intercepting email.
 https://sendgrid.com/blog/sendgrid-and-the-future-of-email-s... (I work at SendGrid)
How about Apple's Keychain? iOS and Mac users get suggested auto-generated passwords that are then automatically saved and synced across devices with no extra installs or options.
Some say email is already like that but it isn't with services using two factor authentication.
I don't think there is an easy and intuitive way to get rid of passwords without involving some sort of physical component that stays on yourself.
Due to "Forgot my password" workflows email is already a central authority. If you have two factor auth set up for your email account then you're already pretty well protected and having each and every service use a different two-factor method provides diminishing returns in security.
The funny thing about this proposal is that it is exactly the way my non-technical family members use every service. They don't bother with passwords they just use reset links every time. They don't have to remember anything and it's a common workflow.
This assumes one (or n) devices that belong to you. I typically have to log into multiple services using a large amount of computers for work. In my use case this would be tremendously annoying whereas two factor I can simply log in like normal and type in the code from my phone's app.
> If you have two factor auth set up for your email account then you're already pretty well protected and having each and every service use a different two-factor method provides diminishing returns in security.
I disagree; it prevents someone from getting into my email due to a vulnerability and then being able to get into every other service I'm connected to. Each service I use would, ideally, have two factor (though I obviously do not think two factor is perfect but it's better right now than most alternatives in my opinion).
I guess whatever the scenario 2-factor + email round trip is more of a hassle than 2-factor + password.
Thanks for your response!
+1 to that. My non-technical family and friends do the same.
I spent a month experimenting with this approach myself vs using LastPass. It was actually pretty comfortable - easier than 2 part auth - excepting that sometimes the forgot password links were difficult to find.
To put it another way: This article describes logging in to a service via an email sent to your account. Every major service already has this in-place via the use of the "forgot password" link; if I have access to your email account, I can already log into any service which sends a reset link to your inbox.
2-factor auth is great as an additional layer of security on top of either this method or the traditional password method, so why not just remove the additional vulnerability of permitting logins via passwords stored everywhere else on the internet, too?
Except with two factor authentication you can't simply reset your password via email and login. It's not perfect but services using two factor authentication prevents email from being a completely centralized way of authentication. I at least like that aspect of it.
Why not one of these on a thin enough tag to stick on your phone? Sounds like a very good solution for me.
That is not the case. It will remember you every time you come back. You just never set a password when registering.
So your phone can't aid you here. If you're using any type of setup that doesn't use instant-push emails on your desktop, logging in will be very cumbersome.
I've wanted to move Persona in this direction for a while. I'm really excited to see if Webmaker is successful with this auth model.
Include a link in the email in case they are currently on the device they want to authenticate.
This solution is good for long term authentications (registering a device to a service e.g. my Xbox to Netflix), but cumbersome for a service I log into frequently from many unique devices.
When authenticating, the browser could just send the user's public key, and if a user with that key is in the system, it replies with a session key encrypted with the user's public key. If browser companies would get their act together, we wouldn't have as many authentication issues as we do today.
The biggest problem is that the user experience is pretty terrible for generating and managing the certificates used for authentication. There's also the fact that the certificates are stored by the browser with no obvious mechanism to log in from another machine.
So instead of clicking the login button and getting an email every time you need to authenticate (or using really long sessions), you use the "email to login" method once per new device. The resulting page takes the user through creating and uploading a client auth certificate, and stores it (along with a user provided device name to allow revocation).
In-browser cert+key generation is not perfect by any means but it certainly is possible - it's how providers of S/MIME certificates  are able to give you a signed certificate without you manually creating a private key+csr and uploading it.
 e.g. https://www.comodo.com/home/email-security/free-email-certif...
No, it's an OTP. And that's so much more than a password...
1. Go to login
2. Forget password - click reset password
3. Go to email, find reset password email
I wouldn't really mind if this became more common. I don't trust password managers (and access the internet from so many different devices that the only common thing they share between them is that I can access my webmail client or email on my phone.)
* I don't trust any software that uploads data to a centralized service (encrypted or not)
* Especially when that software is not open source / free software.
(Hashed) Password storage is moved to a third-party database (the email provider). Presumably the client "remember me" links are meaningless by themselves.
A very large percentage of users reuse the same password on multiple sites. If you do that, a security breach in any site will leave your password exposed on all sites. And if you're anything like me, you have an account on all sorts of tiny sites.
You really can't trust the security of any startup thats less than 2 years old, or less than 5 people. Most software engineers don't know infosec well enough to implement a proper password database and protect it. Most startups are only 'secure' because they're such small threat targets that they don't have much value in attacking. However, if those small targets store username and passwords that get reused on lots of websites, everybody loses.
If the 'reset password' link sends an email, users have to trust their email security anyway. If I have access to your email, I can reset your facebook, twitter, etc passwords then delete the password reset link & notification from your email account. Google is going to do a better job at password security than a 3 month old startup with 1 engineer.
Absolving mozilla (or anyone else) from keeping passwords improves security.
If you gain access to your victim's e-mail account, even if you find any passwords in there, you cannot use any of them because they are not working anymore.
So it's not only a stronger, non-recycled password. It's:
1. an OTP
2. that expires very soon
3. that cannot be recycled
4. in a place that's likely to be well-protected
EDIT: 5. that place (#4) is in widespread use
This is beyond a "password manager" which barely covers #3 (it incentivizes not to recycle) – and maybe #4, if you're careful.
The solution in this article isn't really "relocating" the attack... more like removing additional attack vectors and limiting it to the email vector (which already exists right now, anyway).
I'm not sure what you're saying here:
> (Hashed) Password storage is moved to a third-party database (the email provider)
There is no hashed password? It's just a challenge response using an alternative path.
In contrast, a password is designed to be used from any login point.
In this regime, unless the optional password is used, there is no hashed password stored on Mozilla's servers. Only a copy of the hash of the "login key" is stored, so the attack surface is considerably shrunk if you are attacking Webmaker users.
I'm not totally clear about what the different between a "login key" (short-lived, pronounceable) and whatever is contained in these semi-permanent login email links (~1 year, presumably non-pronounceable).
I don't see a difference in this and 'Reset your password' links in emails that are common place. They are basically the same premise, without the password.
In mobile the sign up flow can even be more streamlined using deep linking:
1. User enters email address.
2. Opens email client and click the link.
3. Link contain app specific schema myapp://login?token=cold_fish etc.
4. App opens and verifies the token with the server.
5. User is logged in.
User has to enter only email address as opposed to email + password (and sometime password confirmation)
Then only needs to click a link in email client to sign up.
Thunderbird shows a large modal "WARNING! Server mail.myhost.com does not use encryption" dialog.
To be fair those inbound reports are potentially bloated by a lot of spam that no one reads or cares about. It would be interesting if Google disclosed what percentage of messages that end up being read are sent over TLS (or non-spam messages generally). But we can also see that several top 10 sending domains do not support TLS at all (adsender.us, constantcontact.com, grouponmail.*, sailthru.com - mostly advertisers). Luckily the top receiving domains support TLS (which look like other big-name ISPs).
Compared to website TLS, email TLS as commonly implemented has two significant challenges beyond these percentages. First, since TLS is established by the STARTTLS extension protocol within an existing plaintext SMTP connection, it's easy for an attacker who can modify communication to force it to remain in plaintext (simply don't advertise the TLS capability). Second, that previous attack is hardly even necessary: most email senders are willing to establish connections to receivers who present self-signed certificates. The same scenario when browsing a website will show a security warning and recommendation not to continue. The reasoning goes: it's better to use TLS even with a self-signed cert than fall back to plaintext. There's no human involved who can make a judgment call to abort, like there is when browsing a website. So, while email TLS with self-signed certs may be helpful against passive dragnet surveillance, it's little defense an attacker who can intercept and modify the communication: the attacker can simply present his own self-signed cert instead, and the email will flow.
Solution ideas: Devise a standard by which messages can be stamped "TLS only or don't send", and another standard by which domains can declare their intention to support TLS. Senders will remember that the domain is TLS-enabled and refuse to fall back to plaintext; and will require a certificate from a reputable CA under either protocol.
I'm one of those who have been trying to do so. I created an open source approach called Handshake.js that is re-usable for developers. 
I presented this topic to a good crowd at JS.LA .
At the current time, I'm finding developers still hesitant to jump into the approach. Passwords are familiar and there are many developer tools/libraries to quickly setup the defacto username/password approach to authentication.
It uses the same idea as in the post, ie the "lost password flow for login", but with XMPP. The latter gives you much higher flexibility in that it actually is thought out as a programmable protocol. You try to login, the server sends a token to any of your connected clients via a bot message, you just repeat it to the bot and you're then granted access.
I feel there is high potential here, and there even is an official XEP (http://www.xmpp.org/extensions/xep-0070.html) for this.
It works very well for our purposes. We don't need crazy security because we store no important personal information -- just product preferences. It's insanely easy on the users.
I guess I should get back to blogging about my entrepreneurial lessons learned, as this has been one of many of them....
This seems like a solution that completely replaces the need for every website to manage their own user signups, which is something you still need to do even if you integrate with Google/Facebook/etc. because not everyone has an account with those and signing up for one is less trivial than having a sign-in link sent to your email.
Besides, I don't think they are claiming to be innovative. I think they just point out there is a redundant step which we can remove from the process.
They're doing so for the nth time, and on the (or a) device they usually use, and thus their browser (or other password manager) has already got their password remembered and thus it is pre-filled in.
Having to click back and forth between email every time you log in seems way clunky relative to that, which for me is something above 90% of the instances I log in to some web application.
Couple that smoothness with picking a non-reused, strong password for a web application (which password managers make actually practical) and the friction in the user login experience seems to have little if any upside.
I go to a site and my intention is to stay on that site throughout whatever I'm doing there. If you force me off your site for something like logging in (where it's the point of 'I trust your site, give me access') then I've lost focus and you've put your experience in someone else's hands.
If I was doing this, I'd have to open a new tab, go to GMail, wait for it to load, find the tab within GMail that has the email and then click the link. Every so often, I'd probably have to put my Google password in too. That's a lot of effort, considering that your site probably isn't that significant to me.
If by push notifications, you mean mobile devices, then surely that would only log them in on that device rather than on their computer?
The only difference I can see is that they ask you the email to figure if you are coming from yahoo or Google while the most common pattern is to show two buttons.
I don't think asking your email is a good idea, email is a something they should ask to the identity provider instead.
Actually, the "lost password" flow already assumes email as a single point of failure, so I suppose my 2FA comment is moot (in other words, we should be pushing for 2FA for accounts regardless of their password approach on other accounts).
This is already the case right now. An attacker who has access to your primary email account can gain access to any of your accounts using Forgot Password.
> the "lost password" flow already assumes email as a single point of failure,
Exactly. I think that was the inspiration for the idea. If we have a single point of failure anyway, why not just use it directly to login?
If the goal is to separate the need to remember complex passwords from the application, then a password manager makes much more sense (ideally with 2FA).
In the long game of improving token-based security, this is a step sideways at best.
That is to say, yes, a compromised primary e-mail _is_ catastrophic, but seems like an already accepted risk. Why is this worse?
I didn't mean to imply that this was worse, only that it doesn't really change the threat.
This is not the case when using two factor authentication.
It really feels like they want to solve my password storage problem for me, in a very opinionated manner without any alternative for me, and while it might be a good solution, it does not feel like one (for me).
The linked more technical description suggests that the latter is done (sessions on trusted devices are valid for 1 year), so you apparently cannot stop someone with a stolen device from accessing your account (while the session is active / the cookie persists).
I was initially concerned that email is insecure, but then I remember sites already use email for password reset. :) My bank does something similar by also remembering my personal computers by browser fingerprinting and/or IP address.
What i do is i keep all worthy sites'password on the password manager and the rest of the site follow a pattern based password or a common simple password. For e.g. i typically use some this "keepass"or domain of visited web + keepass
In the past I had thought it would be great if instead of email it could push to your phone so a message would pop up saying "confirm login? Yes/no". It would be a really simple option from a ux perspective but screw going anywhere near making the crypto tech to support it.
Passwords must die. We need to get to the point where there is a modular mechanism for authentication so that individual devs never are tempted to create a users table and add a note field for password storage.
1. Navigate to Settings, Finger Scanner, Pay with Paypal
2. Select Install FIDO Ready Support, then Install NNL fingerprint scanner
3. Select Link to Paypal, then Link Fingerprint
4. Login to paypal with username and password
5. Agree to terms
6. Swipe finger to link fingerprint
7. Install paypal app.
1 is obviously mandatory. 2 could be preinstalled. 3 could be combined, but is mandatory. 5 is stupid. 7 should be already installed if you use paypal.
End result: find the right settings area, select link fingerprint to paypal, login to paypal, swipe fingerprint to link, done.
Don't criticize FIDO based on some half-baked implementation. Any problems you have with the setup flow are either Paypal's fault or Samsung's.
Don't blame the technology or the FIDO alliance when that video is about the S5 and Paypal, and the video is hosted on Paypal's youtube account.
The new yubikey neo (as of October) supports FIDO, but I don't know about client (browser/mobile) support middleware, and it requires nfc or full sized usb.
Email delivery problems is a factor that needs to be considered though.
Stolen "remember me" cookies is another factor... The password stealing malware will start harvesting those cookies instead of passwords (it's already happening in some cases).
If I steal someone's phone, I get access to any system using this.
If I buy a sim card off someone, or buy used sim cards, I could also gain access to some potentially high value targets if they use this.
If I 'borrow' my phone of someone, I can steal things from them if the sites using this have value.
"fewer/less: fewer means smaller in number, eg fewer coins; less means smaller in quantity, eg less money"
Simply put fewer is for things which can be counted, less is for things which can not. So you have fewer cylinders of air, but less air. If you can say "one X" and have it make sense you should use fewer, otherwise use less.
That's the rule as it's meant to work, the more interesting question is "does the rule matter any more?", to which I'd answer probably not.
You don't see supermarkets with "5 items of fewer" lanes and most people don't really see any difference between the two terms. The reality is that language continues to evolve, as it has always done, and the distinction is really now just one for pedants (guilty as charged). If you need proof of this then the just look at the figures in quoted blog post (assuming they're even vaguely right), which suggest that most Guardian journalists are ignoring their own style guide and their sub-editors (a job title which pretty much comes with pedantry in the job spec) are letting them.
That's why I shop in Waitrose
That is the reason, you should try not to change your eMail to often and when, keep the old adress until it gets cold.
Of course, what you normally should do: Change your eMail-address in the application before you switch.
AND: Never use your ISPs eMail-address (unless he will let you use it after you canceled your contract).
The system will probably have to give a way for the user to change email address while the user still has access to the old email address.
This is something that wasn't mentioned in the article but should definitely be solved.
Any reasonable web-application today has (or should have) a possibility to change eMail address.
Except the UX is sexier.
Key loggers anyone?
Here's another take on how to get rid of passwords: The Password Manifesto
Of course your proposal is superior, but the infrastructure is not available yet. For web-apps with low security demand, I think the discussed scheme would be sufficient (since we already have security implications because of password reset schemes -- and real secure schemes are seldom. In Germany there even where attacks to two-factor authentifications via mobile of banks ... the attackers just ordered a second sim-card in the name of the legal user and intercepted the snail-mail).
I agree the security of this solution may be right for certain applications.
Yes, my proposal is an infrastructure play - but I believe it is a more realistically achievable one than most password alternatives.
There are of course some questions, that also would need to be solved. For example: What if an other person has access to my computer -- than I still would need some kind of master-password that had to be remember-able. Also there must be methods, to transfer my keys to an other computer or to "copy" for example onto mobile devices.
The example of the SIM-card for banking just shows, that the "big security" is really a hard problem. Two-factor is one idea, but it is always a game where the attackers are hunting the defenders (or vice versa).
I see the transferability as an export/import format issue. W3C, browser vendors and password managers need to agree on a format for keychain export/import.
Note that this technique could still be used in conjunction with multi-factor auth. Since it is just an evolution of passwords, those type of mechanisms are still relevant and compatible (though, eliminating knowledge factors should reduce need for a second factor).
So far, both the W3C and the browser vendors have been AWOL for the most part on real solutions to this problem.
If you are interested, I'm looking for folks to help flesh it out and promote it. Any and all help is welcome!
Problem with this system: it requires input on a single device (the computer), removes an out-of-band authentication option (password), and pushes the requirement for authentication down the stack to a system without a secure connection (e-mail, SMS).
In this new system, the password becomes an optional secondary authenticator. Your primary authenticator is now moved to some pre-authenticated service, such as your e-mail (which you have already logged into, presumably with a password) or SMS messaging (which you have already logged into, presumably with a swipe or pin on your phone). On top of that, neither of these uses a secured connection, so MITM/interception are trivial, to say nothing of phishing+CSRF.
One of the major flaws with existing out-of-band authentication access is that we assume the user only has one form of input: the computer. If the computer gets hacked [via malware] the user cannot protect themselves. But the future is here, and we carry [networked] computers in our pockets! Turns out the most secure way we can authenticate is via two separate networks and two separate computers using two secured connections. Example:
Step 1. User requests to login to HTTPS Site A.
Step 2a. Site A prompts User for a password.
Step 2b. Site A sends an SMS to User with an HTTPS link to click.
Step 3a. User enters password on site.
Step 3b. User clicks link on SMS in mobile device.
Step 4a. Site authenticates password.
Step 4b. Mobile site reads cookie on User's mobile browser.
Step 5. User is authenticated; both mobile device and computer have access to site.
It would be trivial to add this dual-auth method to their existing system, so hopefully they implement that instead of throwing the baby out with the bath water.
For what it's worth, of course, here's an attack that could compromise that system. Attacker shows user a phishing password prompt page that uses a browser hack to steal a cookie. Attacker sends an SMS to the user (assuming they found the user's phone number) with a link to another site which also exploits the mobile browser to steal that cookie. Now the attacker has the two cookies and can log in, assuming the site does not use an Authentication Manager that detects attackers who steal credentials (only large-dollar sites use these).