5 ms·
Using Phones/SMS as 2FA – Why I am not a believer
- eitland 13y ago"And please remember 2FA is not a substitute for a good password policy." 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.
- taf2 13y agoI can't help but think maybe this is similar to having only the login screen https, but the rest of the site http with the auth cookie being passed around in clear text... Initially, we thought we were being more secure because we secured the transfer of the password to the website, but in reality the auth cookie is just as important. 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?
- uxp 13y agoBasic 2 factor authentication doesn't even cover the scope of password resets, so the idea that 2FA is flawed when used in conjunction with cellular networks is a terribly unthought out argument. If any service uses a token reset code sent to a phone as SMS or voice message, then that service is using a flawed password reset mechanism using the idea that cellular networks are highly insecure, regardless if it's also using 2FA. _Any_ single authentication mechanism over cellular networks is flawed using the same logic. 2FA, arguably, is more secure over cellular networks because it requires an authentication mechanism (the password) that is not transmitted over SMS/voice cellular in a plain format (assuming the authentication itself is sent over TLS/SSL).
- taf2 13y agogreat points, clearly i was misunderstanding, the reset mechanics i was describing are clearly a very bad idea and not 2 factor. thanks!
- brown9-2 13y agoThis is an argument against using SMS or phone calls as the second factor, apps like Google Authenticator are still a really great option (as the article states).
- sbierwagen 13y agoIf you have the option to use RSA SecurID or Gemalto devices (used by Amazon), use them first. RSA SecurID was famously compromised back in 2011: http://en.wikipedia.org/wiki/SecureID#March_2011_system_compromise http://en.wikipedia.org/wiki/SecureID#March_2011_system_comp... Any system where the manufacturer has a copy of the secret key on the token is theoretically vulnerable to this attack.
- lstamour 13y agoThat was bone-headed stupidity. RSA could easily have used more expensive HSM hardware, and the rest of us can spend a grand on two YubiHSMs or equivalent hardware. (Or trust Google's....) There's little excuse to poor secret management if you run your own hardware.
- StavrosK 13y ago> (Or trust Google's....) What does that mean? Where do you need to trust Google's?
- lstamour 13y agoI meant, "or trust Google's ability to keep their two factor authentication keys secret (with their Authenticator app)". Though perhaps I also meant using Google Authenticator app with your own keys ... except you'd still need to keep them somewhere, which means ideally an HSM and we're back to square one. :)
- StavrosK 13y agoWhat do you mean by "their" two factor authentication keys? There are no "their" keys. TOTP/HOTP is an open standard and Google Authenticator is an open source app. You can audit it, or write your own. It's not even that hard to implement.
- zobzu 13y agoReminder also that OTP is NOT a strong factor, anyways. Even if the manufacturer doesn't hold the secret seed (i.e. the device lets you regenerate it - vendors usually don't let you do that so that you're forced to buy again from them all the time).. so yes, even if they don't hold that secret seed, the target servers hold them. 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.
- extra88 13y agoHe gives an example of what can happen with voice-based authentication but not SMS. What can an attacker do, collect the text as it passes between the cell tower and your phone then use it before you get the chance to? 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.
- benmanns 13y agoIf you could social engineer an employee to change a voicemail number, you may be able to convince them to port a number to a new account.
- _djo_ 13y agoThere have been bank account hacks where the perpetrator has had an accomplice inside a cellular service provider who intercepted the SMS and prevented it from being sent to the account-holder's phone while retrieving the code.
- cheald 13y agoNumber porting attacks have been used to compromise SMS-based auth in the past. http://www.itnews.com.au/News/282221,phone-porting-used-to-unlock-net-banking-codes.aspx http://www.itnews.com.au/News/282221,phone-porting-used-to-u...
- benmanns 13y ago"No 2FA. If the only option available is SMS or call-based authentication, do not use 2FA." 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.
- michaelmior 13y agoAgreed. If BOTH are required than even if the second factor is relatively weak, it's still better than password-only.
- deleted 13y ago[deleted]
- poutine 13y agoIf both are not required it's not a second factor. Two factor is something you know (password) plus something you have (a phone number).
- willvarfar 13y agoHere's the story of a banking trojan attack that redirected the victim's phone to authenticate large transfers: http://williamedwardscoder.tumblr.com/post/24949768311/i-know-someone-whose-2-factor-phone-authentication-was-hacked http://williamedwardscoder.tumblr.com/post/24949768311/i-kno... Scary when it really happens. (My blog post)
- sehrope 13y agoThis was an easy choice for us when we setup two-factor auth for our app. We chose TOTP. The only real con (if you can call it that) is requiring the user to install a TOTP app (eg. Google Authenticator) but given our target userbase that was a non-issue. 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] TOTP Cons: * Requires user's to install an app or have a physical TOTP device * Clocks must be kept in sync[2] Phone SMS pros: * Nothing to install assuming your user has a phone Phone/SMS cons: * 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 [1]: I don't like giving out my phone number and I assume most other people are like that as well. Less is more when it comes to sharing personal info. [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.
- arn 13y agoWhat about losing your device? How is that handled with something like Google Authenticator? Don't you then have to fall back to some sort of manual verification? If you lose your SMS authenticated Phone, you can get a new one and transfer your number to it.
- sehrope 13y agoIf you lose your device then you restore it from a backup. For Google apps's 2FA setup they also have one time use codes. It s a special list of 10 codes that you're supposed to save somewhere safe offline (eg. wallet, deposit box, trusted neighbor, ...). If you lose your device you can use one of the codes to login and configure (or disable) 2FA.
- arn 13y agoI've had backup restore to a new device not work for google authenticator (I assumed that was by design), which is what has made me wary of it. But for your app, I assume you use manual re-authentication if someone loses their device?
- poutine 13y agoThis is utter stupidity. Somehow voicemail PIN weaknesses translate to being able to intercept SMS's? 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.
- pfraze 13y agoIn the case he cited with CloudFlare, the phishing the voicemail was a pretty effective attack vector. Also, where does he tie PIN weakness to SMS interception? They're uniquely vulnerable. > 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.
- poutine 13y agoOh really? You think that login+password is a trade of equal risk with login+password+sms? Sorry, but the second is clearly has much less risk. 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?
- pfraze 13y ago
- tantalor 13y agoEasy to phish. If you know some basic information about the person, you can get the PIN changed. That's not what phish means. Phishing in this case would mean the victim gives you her PIN, assuming you are trustworthy.
- pfraze 13y agoI'm not sure phishing is limited to situations where you attack the account owner, though I could be wrong. Going off of the Wikipedia entry (though this doesn't prove anything either): > 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. https://en.wikipedia.org/wiki/Phishing https://en.wikipedia.org/wiki/Phishing
- cranefly 13y agoIs there a problem with a system whereby a business already has clients phone numbers and uses them to send the client a temporary PIN when the client enters their phone number as a username on the business's website?
- _phred 13y agoYes: call/SMS forwarding. It depends on how good your first factor (e.g. password policies) are, and how your reset process works. Getting someone's phone number and setting up call forwarding doesn't require much social engineering savvy to pull off. http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/ http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...
- poutine 13y agoCall forwarding doesn't forward SMS. I don't think you can do SMS forwarding (at least for any carrier I'm aware of). You'd need to social engineer the carrier to port your target's number to a different phone -- in which case the target is going to be exposed to a ton of trouble...
- dobbsbob 13y agothat is how liqpay.com works. you enter number, receive one time PIN via sms to login
- seldo 13y agoMy biggest problem with 2FA that relies on a phone is that I can lose my phone. If I do, the system can then do one of two things: 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.
- rimantas 13y agoLosing your phone is not the same as losing your phone number.
- lstamour 13y ago+1. And in a world of VoIP that can be both good and bad ;-) That said, if you use Google Authenticator, it's just a backup away. And you can add additional numbers, which again provides that tradeoff between security and convenience. At the end of the day, high value targets should be defended in depth, with least exposure to attacks and easily dropped if compromised. Which means maintaining inbox zero on servers others monitor but are less shared (so you can phone someone) and implementing login systems without failsafes. Of course, IMAP wasn't built for much of this 2FA stuff ;-)
- Spearchucker 13y agoTwo factor is something you know (but can forget) and something you have (and can loose). The risk is there, regardless of the thing you have being a phone or key fob or smart card.
- LamaOfRuin 13y agoThis is where one time codes that you keep in your wallet come in. 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.
- jlkinsel 13y agoA problem for security geeks is they frequently forget about 2 things: 1) the balance between usability and security, and 2) The risk acceptance/appetite of the person for the security they want/need to use. 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...
- swampthing 13y agoI don't really understand the argument the author makes about SMS being easy to spoof. Most of the 2FA systems I've seen using SMS use it to communicate a secret that the user needs to type back in on whatever screen they were at. If an attacker spoofs the SMS message, the user is just going to get some secret that doesn't work when they type it in.
- danielpal 13y agoI'll chime in because theres a lot of mis-information here. 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-factor-authentication-05289228/ 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.
- lstamour 13y agoGood tip about the voicemail. Though in theory, with VOIP becoming more popular, it's still just a matter of time before more people run into the phone-call-redirect or even text-message-redirect if services like Google Voice pick up elsewhere. In addition, there's the social engineering hacks of last year, where the attackers added a credit card, then gained access by verifying that same card. At the end of the day, humans always play more of a role in security than people assume. Thanks for the tips, though! I'll revisit this thread later for 2FA.
- zobzu 13y agoI"ll just go ahead and remind that many people use google authenticator to authenticate accounts ON THE SAME PHONE. It's dumb, inconvenient, but yeh.