Security is about systems, not individual components. Take a random Internet service protected by passwords and add a second factor to the login step where after login and password you must enter a code that gets SMS'd to your preconfigured phone number. The number of fraudulent logins will drop to near zero as password guessing is no longer sufficient to break in to an account. The number of attackers that will be able to attack your login page and intercept SMS's for a specific user within the phone network is limited to three letter agencies.
The best security is security that people will actually use. Virtually everyone has a mobile phone and thus why the SMS channel is attractive.
Sure, this isn't the be all and end all in security and an app like Google Authenticator is more secure but SMS as a second factor is ideal for most consumer applications.
> Take a random Internet service protected by passwords and add a second factor to the login step where after login and password you must enter a code that gets SMS'd to your preconfigured phone number. The number of fraudulent logins will drop to near zero as password guessing is no longer sufficient to break in to an account.
I think you're mitigating one set of risks while adding others.
EDIT: just want to add, I do think UX should be a primary concern of security; I just disagree with your analysis of his post.
Fair enough. I think the interesting thing to debate is his conclusion: that two factor auth using SMS is so flawed as to be avoided completely. That's complete nonsense.
Twitter introduced SMS authentication as a second factor. Do you really think that their number of fraudulent logins for users protected by that second factor hasn't gone down to near zero?
That should be the top comment. Having done force protection for an aircraft carrier before, during, and after 9/11, it's all about systems. We involved nation-states in this. All our systems and all their systems. It took months if not years of planning, advance trips, meetings in SCIFs and prestaging assets to bring one of those into a foreign port. Lasers, standoff air defense, dolphins, guys in in cafes "reading the paper". Training 2000 sailors on .50 cal, shotgun, 9 mm. Boat teams. Here's us getting underway from Virginia a week after 9/11:
http://m.usni.org/magazines/proceedings/2001-12
People with no dog in the fight, famously the older warrant and limited duty officers, guys who came up through the ranks for 30 years, would continuously poo-poo my plans. "What if this...." "What if that..."
Toward the end of my tour, the fleet force protection officer, a senior SEAL commander, drug my counterpart from another ship in, an old warrant officer who had been doing physical security since before I was born. The SEAL drilled our team on scenarios in front of this other guy for an hour. Then he turned to the warrant and said "These guys might take the first hit, but I know what they're going to do. I can count on them. I can plan around what they'll do. I have no idea what your ship is going to do. Fix it."
Screw the what-iffers, but make sure you can annihilate their what if scenario twice before it ever comes to that. Take ownership of you defense. Take you job personally. Use the what-iffers for the cheap war gaming they offer, and then don't worry about them.
Get everyone in your organization on board with your plan. Make sure you know who has the authority to pull which triggers, and make sure they're available on the necessary timeline, or devolve that authority to people who are. But don't let the intern have so much authority he can inadvertently start a war.
Know what your internal and external reporting requirements are, and why. For example, I'm willing to bet the security of gmail is considered a national security priority at this point. Even if no one in DC can do a damn thing about it. It's been wargamed, and the Pentagon battle watch commander can get a googler with need-to-know on the phone in under a minute. If that googler doesn't know that, he probably ought to have figured out why.
If you have the option to use RSA SecurID or Gemalto
devices (used by Amazon), use them first.
Any system where the manufacturer has a copy of the secret key on the token is theoretically vulnerable to this attack.
There is no encrypted version of the secret seed. There is no hashed version. You and the opposite party (the server you authenticate to) both have to be in possession of the secret seed.
That means if any server containing those keys is compromised, your OTP token is suddenly just paperweight (yeah, people like these crappy analogies, i heard.)
Using something like an opengpg smartcard and true challenge/response type authentication is much better than the "2FA" provided by password + OTP.
Something you have (the keys on the smartcard), something you know (the passphrase to decrypt those keys), the key never leaves the smartcard, nobody else has your key.
There's little excuse to poor secret management if you run your own hardware.
What does that mean? Where do you need to trust Google's?
a) it locks me out forever. I'm screwed.
b) it has a way to reset my auth. Meaning an attacker doesn't actually need my phone.
So getting the phone involved is either a huge risk or a pointless feel-good factor that can be bypassed. Either way, I'm not on board.
Many second factor auth systems use this. There is a list of 10 codes that can be used once each (and they're only valid used in order, so only one is valid at a time). You print this list out and keep it in your wallet or wherever else in case you lose your phone. If you lose both your phone and this list, then you are in fact screwed.
Or is it the scenario where they've stolen your password and your phone? If it's a smartphone, they'd have to be able to unlock it and once they've done that, SMS doesn't seem any worse than Google Authenticator.
http://www.itnews.com.au/News/282221,phone-porting-used-to-u...
http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...
I see no problem with password + SMS or password + phone. The big problem is that some companies think that their second factor overrides the first factor, and choose a weak second factor. 2FA must be an && operation, not an || operation, for all modes of authentication. Otherwise, you are exactly right, and attackers will compromise the weakest link in the chain.
Here's a quick summary of pros/cons:
TOTP pros:
* Assuming the initial secret is delivered securely (eg. HTTPS) no MITM vulnerability
* Free as in beer
* Simple to implement
* Instantaneous
* No additional personal information asked of user[1]
* Requires user's to install an app or have a physical TOTP device
* Clocks must be kept in sync[2]
* Nothing to install assuming your user has a phone
* Not free as in beer
* Could be MITM by telco or anyone with access to telco data (wireless scanner)
* Requires asking for the user's phone number
* SMS is *not* instant, could be minutes or more to receive a message
[2]: Clock sync is really important. If you're going to do a TOTP implemenation make sure you run ntpd/ntpdate to keep your clock in sync.
If you lose your SMS authenticated Phone, you can get a new one and transfer your number to it.
2FA is not a replacement no. What it does is increasing security in environments where you might risk that your main password is compromised.
This doesn't mean you are free to reuse passwords but it still significantly raises the bar for a successful attack.
In the case of typical 2 factor authentication via phone - if I can reset your password via a code being sent to your phone, then you've lowered the security of your password from maybe an 8 digit password to a 4 digit numeric pin...
Of course, I would need to know your phone number, which may be difficult to guess?
My credentials: I am the founder of Authy, we do two-factor authentication using SMS, Phone Calls, TOTP App and Hardware Tokens - we protect over 80,000 accounts including CloudFlare, Coinbase etc, so I am very familiar.
On 2FA using SMS:
1. Yes it's not as secure as a dedicated TOTP App but:
2. SMS phishing doesn't matter here. SMS phishing would allow the attacker to send message as you but not receive messages. In order to compromise Two-Factor SMS auth he would need to be able to receive them.
On VoiceMail Security:
1. True, voicemail is insecure. But if your Two-Factor Auth provider knows anything about security, he can help you. For instance we just helped Coinbase with Voice verification. In order to protect the verification codes going to VoiceMail, we require the person to input a number before reading the token.
Eg. Hello, this is Coinbase, if you are expecting this call, please press 1. [ Only on 1] your code is, “1,2,3,4,5,6,7”. Again “1,2,3,4,6,7”, last time “1234567”.!
So if you can only use SMS or Phone Call Two-Factor Authy, by all means use it. If you have a Smartphone it's better if you move onto a dedicated TOTP App.
The biggest weaknesses this days on Two-Factor Auth is not SMS or the carriers, it's the implementation. Unfortunately although implementing TOTP is easy, a secure Two-Factor system is not. Most are using recovery codes, e-mail and defective recovery mechanisms, which is how this systems are being by-passed.
http://www.slashgear.com/dropbox-hack-allows-bypass-of-two-f...
Find yourself a good Two-Factor Authentication provider. I would recommend Authy, but I am biased so I'll recommend Duo-Security.
That's not what phish means. Phishing in this case would mean the victim gives you her PIN, assuming you are trustworthy.
> Phishing is the act of attempting to acquire information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication.
http://williamedwardscoder.tumblr.com/post/24949768311/i-kno...
Scary when it really happens.
(My blog post)
The two are intertwined closely. For something that isn't that important, a user isn't going to jump through complex hoops every time they have to login. What they will end up doing is finding workarounds (Hello Mr. Post-It).
For most folks, they don't really need complex solutions to reset their email password. What needs to be asked is "What am I protecting, and what is it worth to me?"
Oh, and I'd suggest certificate-based auth is way better than complex passwords.
Daniel's been around for a while (I've loved OSSEC for years) so I suspect this post just wasn't meant to be a complete essay on the topic...