2 ms·

With the exception of the database or backup being 'stolen' wouldn't the addition of a 3rd variable, like a captcha code, solve brute force attacks? I have b

• jsjenkins168 19y ago
  Services like CAPTCHA are intended to solve different problems, like protecting your web service against DoS or bot/spam attacks. To brute force crack a password, you would really need direct access to the digest. We are talking around the order of 2^80 attempts before finding a collision with a algorithm like SHA-1. Checks need to happen very fast. Doing this through a web interface is already too slow to be feasible from a time perspective. So really, cracking passwords is only a consideration when someone gets a hold of all your digests (eg. your database) and can crunch away on them locally for a long time.
  • thomasptacek 19y ago
    I'm really not sure you're talking about the same thing as, well, anybody else doing password security. Brute force incremental crackers (read: almost every password cracker ever written) don't attack the algorithmic strength of SHA1. They attack the complexity of the underlying passwords, using dictionaries, mutation functions, and statistics. SHA1 is strong (at least in this application). Passwords are very, very weak.
• thomasptacek 19y ago
  Password cracking is an offline attack. If you think the only way you're going to lose your password table is if someone steals a hard drive or a backup, or uses a zero-day to root your whole server, you are making an extemely bad assumption.
  • gscott 19y ago
    Assuming the webserver is not compromised, the sql server is on it's own local network, and the webserver is on both the local network and the Internet accessable network (2 network cards), how exactly does someone get direct access to the sql server to run an offline attack. I have always assumed the database server is safe there alone on it's own network as long as someone doesn't break into a machine that is connected to that network.
    • thomasptacek 19y ago
      Consult the Wikipedia on "SQL Injection" attacks.
      • gscott 19y ago
        I already parse everything from the querystring, form fields, (even) cookies (anything the user can manipulate) for malicious input (sql injection). That is standard fare, anyone who doesn't do that will find themselves in a world of hurt fast.
        • thomasptacek 19y ago
          Tell me all the things you parse for, and I'll name something you missed. The catch: if I do, you have to change the front page of your application to this: http://www.kare11.com/assetpool/images/0791415019_well101HDB.jpg http://www.kare11.com/assetpool/images/0791415019_well101HDB... for at least 2 weeks.
          • Xichekolas 19y ago
            After reading every comment on this thread, I have determined that all posts from Thomas are written using the same pattern. "Several sentences of very informative information and background on the topic of security for those non-experts (vast majority of us). One sentence calling the parent poster an embarrassing retard." Seriously though, I appreciate the insight into the topic and enjoyed your reply post to the one at Coding Horror. Thanks to you I finally understand the reason a decent salt matters, and I'll be sure to ditch SHA1 for bcrypt when I get home. You can rest assured I'm not trying to design my own password system (for anything public)... I was just wondering, are there other systems that do authentication without actually sending the password over the wire besides the supposedly-hard-to-implement Stanford one that may or may not be patented? Bonus points if it's open source...