7 ms·

People forget how quick it can be to get the tools to do simple things like SQL Injection and XSS without even trying. They are free and EXTREMELY easy to get.

by kirinan 14y ago

People forget how quick it can be to get the tools to do simple things like SQL Injection and XSS without even trying. They are free and EXTREMELY easy to get. Not covering those basic security flaws will allow any "script kiddies" to get into all of your data. Even still though, some of the more sophisticated attacks, like Social engineering, are not being made into tools that anyone that can use a computer can use. Its not so easy to make secure things because the hackers only need to be right once, you need to be right every time. Also remember, you're only secure as your weakest link.

stanleydrew 14y ago
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.
- 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.
tucson 14y ago
what tool(s) can a web entrepreneur use to check if his site won't be hacked by script-kiddies?
- woobles 14y ago
  I'm going to assume you mean "What tools can a web entrepreneur use to check if his site can be hacked by script-kiddies". There are a multitude of static analysis and penetration testing tools out there, free and licensed. Fortify (Static analysis), HP Web Inspect and IBM AppScan (penetration testing) are just a couple easy(ish) to use tools. On the free side of things, BackTrack comes with a plethora of security tools one can use to assess your site.
- kirinan 14y ago
  Mastering the top 10 of the OWASP is important. Those are trivial but are important to keep in mind when working on the web. The next thing you can do is ensure that keep everything locked down and open up only what you need. This means that if you only need port 443 open on your server for people to access your API, thats the one you use. Multi Factor Auth is important for API's (I suggest OAuth). Other than that, keep your server monitored, and never EVER trust your users (in a security sense).

by kirinan 14y ago

stanleydrew 14y ago

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.
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.

tucson 14y ago

what tool(s) can a web entrepreneur use to check if his site won't be hacked by script-kiddies?

woobles 14y ago
I'm going to assume you mean "What tools can a web entrepreneur use to check if his site can be hacked by script-kiddies". There are a multitude of static analysis and penetration testing tools out there, free and licensed. Fortify (Static analysis), HP Web Inspect and IBM AppScan (penetration testing) are just a couple easy(ish) to use tools. On the free side of things, BackTrack comes with a plethora of security tools one can use to assess your site.
kirinan 14y ago
Mastering the top 10 of the OWASP is important. Those are trivial but are important to keep in mind when working on the web. The next thing you can do is ensure that keep everything locked down and open up only what you need. This means that if you only need port 443 open on your server for people to access your API, thats the one you use. Multi Factor Auth is important for API's (I suggest OAuth). Other than that, keep your server monitored, and never EVER trust your users (in a security sense).