5 ms·

It is really hard to prevent advanced attacks. I actually think that two-factor auth is a very simple and powerful way to prevent all sorts of attacks, includin

It is really hard to prevent advanced attacks. I actually think that two-factor auth is a very simple and powerful way to prevent all sorts of attacks, including social engineering. It's a shame that he dismisses it as too advanced right out of the gate.

Spearchucker 14y ago
The thing that bothers me about semantics (do two-factor, or, use OAuth) is that so many people I've discussed security with can't tell me whether they should, and why they should. Does the value of the asset merit the cost of the second factor (considering the 2factor is a per-user cost)?
- Joeri 14y ago
  That's why you make it optional for your users.
- icebraining 14y ago
  While it's not as secure as an hardware token, you can get second-auth for free for any user with a more capable cellphone (e.g. a Nokia S60, iPhone, Android, BB, etc). Google Authenticator is free for the user, and the algorithm used (TOTP/OATH - not to be confused with OAuth) is open and easy to implement: it's essentially just feeding the current unix time and a per-user secret to an HMAC-SHA1.
  - Spearchucker 14y ago
    So the point was that two factors may not be required (security for security's sake is a waste of resource). But let's go with the cellphone thing for a minute. I'm assuming you'd use it to send some sort of OTP to the user. Imagine the route that token takes - from your server across the internet to an SMS service (a channel you might secure using TLS/SSL). From there to any one of an arbitrary number of network operators, again over the public internet. You've no control over this leg. From there the token travels through the network operator's network, to a switch, and then over the GSM network to the handset. There are at least two places there where you can launch a man in the middle attack. Which brings me back to the threat model - understanding the value of the asset you're protecting will tell you whether the cost [1] of such an authentication scheme is worth it. Oh, and the cellphone-based OTP is of course an additional asset this authentication scheme introduces. [1] Cost is not just the cost/per SMS. It's also the cost of developing/aquiring the technology, and then maintaining it and the infrastructure that supports it.
    - icebraining 14y ago
      Nope, the solution I posted doesn't use SMS - in fact, it's completely offline. You could have the phone in airplane mode. It essentially generates a code based on a pre-shared secret and the current time. As for the costs, as I said there's plenty of free client applications (Google Authenticator is just the most well known), and not only there are plenty of libraries that you can use on your server, as the RFC that details TOTP provides an implementation in less than 50 short lines of code (+ Java boilerplate); see http://tools.ietf.org/html/rfc6238 http://tools.ietf.org/html/rfc6238 And you just need that, plus an extra field in your data store for each user (to store the secret) and a textbox in the login page.
      - Spearchucker 14y ago
        I've not come across that one before, and... it looks really interesting. I'd argue that it's not completely offline because it requires time-sync, depending on the precision of the client. That assumes the validator is online and can re-sync at any time. Using a phone is a great solution. Except when the app that requires TOTP authN is also on the phone. That's a shame. Either way, thanks for positing the link, and clarifying. I learnt something today.
        icebraining 14y ago
        I'd argue that it's not completely offline because it requires time-sync, depending on the precision of the client. That assumes the validator is online and can re-sync at any time. Well, it uses a 30 second window, so it can cope with small drifts; as long as the phone's RTC isn't broken, you should rarely need to re-sync. I use it with a J2ME application on a Nokia S60 without an internet plan and it works fine.
tptacek 14y ago
I like 2-factor auth, but I'm not sure I see what it has to do with XSS and SQLI.
- stanleydrew 14y ago
  It doesn't have anything to do with XSS or SQLI, quite right. But in his intro he dismisses two-factor auth as some sort of advanced security technique when in reality I think two-factor auth is a quite simple way to dramatically improve security.
  - jamessocol 14y ago
    Like I said elsewhere, that's a major cost/benefit calculation in terms of both real cost and user experience/conversion rate cost. If it makes sense for your app, do it, but it's not part of the basics, at least not yet.
peterwwillis 14y ago
2-factor doesn't prevent your code from being swiss cheese, though. It helps prevent attacks on authentication. If you have a valid user, they can hammer on your swiss cheese code all day and eventually expose your database or worse.
jamessocol 14y ago
I don't completely dismiss it, but it's a huge burden for users, especially those who aren't very tech savvy. I'd love non-optional 2-factor auth for my bank account, maybe that would really introduce it to non-geeks and start making it less of a burden. Anything that makes engaging harder (2-factor auth, captchas, which I'll get to sometime next week) will cost conversions and engagement. You have to weigh those things realistically. Security doesn't exist in a vacuum where User Experience doesn't matter.
Joeri 14y ago
Two-factor auth is like installing an electronic lock on your front door that uses voice recognition and a chipped key. It's only a good idea if the door itself isn't made out of cardboard.

Spearchucker 14y ago

The thing that bothers me about semantics (do two-factor, or, use OAuth) is that so many people I've discussed security with can't tell me whether they should, and why they should. Does the value of the asset merit the cost of the second factor (considering the 2factor is a per-user cost)?

Joeri 14y ago
That's why you make it optional for your users.
icebraining 14y ago
While it's not as secure as an hardware token, you can get second-auth for free for any user with a more capable cellphone (e.g. a Nokia S60, iPhone, Android, BB, etc). Google Authenticator is free for the user, and the algorithm used (TOTP/OATH - not to be confused with OAuth) is open and easy to implement: it's essentially just feeding the current unix time and a per-user secret to an HMAC-SHA1.
- Spearchucker 14y ago
  So the point was that two factors may not be required (security for security's sake is a waste of resource). But let's go with the cellphone thing for a minute. I'm assuming you'd use it to send some sort of OTP to the user. Imagine the route that token takes - from your server across the internet to an SMS service (a channel you might secure using TLS/SSL). From there to any one of an arbitrary number of network operators, again over the public internet. You've no control over this leg. From there the token travels through the network operator's network, to a switch, and then over the GSM network to the handset. There are at least two places there where you can launch a man in the middle attack. Which brings me back to the threat model - understanding the value of the asset you're protecting will tell you whether the cost [1] of such an authentication scheme is worth it. Oh, and the cellphone-based OTP is of course an additional asset this authentication scheme introduces. [1] Cost is not just the cost/per SMS. It's also the cost of developing/aquiring the technology, and then maintaining it and the infrastructure that supports it.
  - icebraining 14y ago
    Nope, the solution I posted doesn't use SMS - in fact, it's completely offline. You could have the phone in airplane mode. It essentially generates a code based on a pre-shared secret and the current time. As for the costs, as I said there's plenty of free client applications (Google Authenticator is just the most well known), and not only there are plenty of libraries that you can use on your server, as the RFC that details TOTP provides an implementation in less than 50 short lines of code (+ Java boilerplate); see http://tools.ietf.org/html/rfc6238 http://tools.ietf.org/html/rfc6238 And you just need that, plus an extra field in your data store for each user (to store the secret) and a textbox in the login page.
    - Spearchucker 14y ago
      I've not come across that one before, and... it looks really interesting. I'd argue that it's not completely offline because it requires time-sync, depending on the precision of the client. That assumes the validator is online and can re-sync at any time. Using a phone is a great solution. Except when the app that requires TOTP authN is also on the phone. That's a shame. Either way, thanks for positing the link, and clarifying. I learnt something today.
      - icebraining 14y ago
        I'd argue that it's not completely offline because it requires time-sync, depending on the precision of the client. That assumes the validator is online and can re-sync at any time. Well, it uses a 30 second window, so it can cope with small drifts; as long as the phone's RTC isn't broken, you should rarely need to re-sync. I use it with a J2ME application on a Nokia S60 without an internet plan and it works fine.

tptacek 14y ago

I like 2-factor auth, but I'm not sure I see what it has to do with XSS and SQLI.

stanleydrew 14y ago
It doesn't have anything to do with XSS or SQLI, quite right. But in his intro he dismisses two-factor auth as some sort of advanced security technique when in reality I think two-factor auth is a quite simple way to dramatically improve security.
- jamessocol 14y ago
  Like I said elsewhere, that's a major cost/benefit calculation in terms of both real cost and user experience/conversion rate cost. If it makes sense for your app, do it, but it's not part of the basics, at least not yet.

peterwwillis 14y ago

2-factor doesn't prevent your code from being swiss cheese, though. It helps prevent attacks on authentication. If you have a valid user, they can hammer on your swiss cheese code all day and eventually expose your database or worse.

jamessocol 14y ago

I don't completely dismiss it, but it's a huge burden for users, especially those who aren't very tech savvy. I'd love non-optional 2-factor auth for my bank account, maybe that would really introduce it to non-geeks and start making it less of a burden. Anything that makes engaging harder (2-factor auth, captchas, which I'll get to sometime next week) will cost conversions and engagement. You have to weigh those things realistically. Security doesn't exist in a vacuum where User Experience doesn't matter.

Joeri 14y ago

Two-factor auth is like installing an electronic lock on your front door that uses voice recognition and a chipped key. It's only a good idea if the door itself isn't made out of cardboard.