Tag Info

Hot answers tagged

182

The Short Answer The short answer is: "So you don't get hit with a $5 million class-action lawsuit." That should be reason enough for most CEOs. Hashing passwords is a lot cheaper. But more importantly: simply hashing the passwords as you suggested in your question isn't sufficient. You'll still get the lawsuit. You need to do more. Why you need to do ...


120

The Holy War I think you will find that the correct way to generate passwords could start a holy war where each group thinks the other is making a very simple mathematical mistakes or missing the point. If you get 10 computer security professionals in a room and ask them how to come up with good passwords you will get 11 different answers. The ...


68

Schneier writes this: This is why the oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick. but the key to understanding what he is really after is a little further in his essay: There's still one scheme that works. ...


44

The XKCD password scheme is as good as it ever was. The security doesn't derive from it being unknown, but from it being a good way to generate memorable passwords from a large search space. If you select the words to use rather than generate them randomly, though, this advantage is lost -- humans aren't good at being random. The bit about memory is ...


41

No, you are correct that at some point during efforts to prevent attackers from determining valid user identities you will either have to lie to them or provide exceptionally vague error messages. Your app could tell a user that "the requested username is unavailable" and not be specific as to whether it was already in use or just didn't meet your other ...


41

[Disclosure: I work for AgileBits, the makers of 1Password] One of the reasons why I advocated an XKCD-like scheme (before it got called that) in Toward Better Master Passwords back in 2011 is precisely because its strength does not rely on the attacker knowing what scheme you used. If I may quote myself The great thing about Diceware is that we know ...


36

This thread is a bit short on analogies, so here goes: An unhashed password is like a transparent lock, anyone who gets a proper look at it can design the matching key.


30

To start off, I'll provide one to start with: Imagine you manage a bank. You don't want to allow your customers direct access to the money. So you have a teller who has just a computer and a small amount of money to deal with everyday withdrawals and deposits. He cannot access everything, nor can he pass secrets to the customer, because he doesn't have ...


27

You're making the assumption that the system actually knows which field was entered incorrectly. There are several reasons this is not necessarily true. One possibility is that it's a side effect of implementation. A simplistic method of looking up logins in a database might look something like (using :n for parameters supplied by the user): SELECT 1 ...


25

Personally, I don't see a reason why the password should be hashed, because when setting the password, it's absolutely clear that other people will need to know it. Then why bother storing the password at all, just let anyone in! ;) If you are storing a secret, it's because this secret identifies a subset of your total users. Not all your potential ...


19

Modern cryptosystems are generally not susceptible to known-plaintext attacks. In terms of encryption algorithms, there are basically 3 algorithms commonly in use in TLS: AES RC4 DES (in 3DES) All 3 of these are believed to be resistant to known-plaintext attacks, and have been well studied for such attacks. The one thing I would wonder about are ...


14

I like analogy as a way to explain technology, however in this case it's probably not workable as the analogy would be too complex. Most managers are more motivated to avoid personal risk to their position than doing the right thing, so rather than an analogy I'd use examples where storing passwords in plain text has reflected badly on a company. I'd just ...


12

actually, hashing it MANY times is bad. here is a quote from http://yorickpeterse.com to proof that. "To cut a long story short, hashing a hash N times doesn't make your passwords more secure and can actually make it less secure as a hacker can quite easily reverse the process by generating hash collisions." read the full explanation at ...


12

Using analogies can be powerful, but in this case, I think it would be much easier to just explain in simple language what is going on. Something like this should be effective, but probably should include powerpoint slides with illustrations and large corporate fonts. As you know, we require people to use passwords so that we know who they are when they are ...


9

In general, it is harder to brute force a registration page than it is to brute force a log in page, so we benefit from this additional cost. But, in concept, you are correct. There are other ways to enumerate usernames than log in page messages. It is simply 'Good Practice'(TM) to keep log in failure messages generic in order to make it harder for ...


9

As others have said, the attack Bruce Schneier describes is effective when the user chooses multiple words him/her-self, not using a tool. Schneier usually writes to a general public audience, which is unlikely to grasp the difference between self-chosen "random" words and program-chosen random words. I'll add that even if you use a script or other tool to ...


8

All explanations so far are a bit long, here is a short one: Some people who can't remember their bank pin, keep a note in their wallet. If a thief or aquaintence would get to look inside the wallet they'd have a problem, UNLESS the pin is written in a way that they can't read it. Hashing is basically writing text in a way that nobody else can read it.


7

Imagine you're the bouncer at a club. To know whether to let people in, you have a codebook of people's names/aliases (some people prefer to be discreet, and are only known by an alias) and their own private passwords; you can't recognize that people are or aren't who they say they are by their voice or appearance (there are too many people, and due to the ...


6

It depends. One thing you need to understand is that this is not security-by-obscurity: the entropy values used in the comic assume that the attacker already knows you're using this method. If the attacker doesn't know how you're generating the passphrase, then the entropy goes up massively. The trick to the XKCD method is that you need to actually use a ...


6

Don't roll your own crypto. It lulls you into a false sense of security, and may be detrimental if you publish it and other people start using it. A hashing algorithm's strength does not stem from the opacity of its design; on the contrary, it benefits from the thousand expert minds looking at it. Your basic idea isn't without merit, though. But if you are ...


6

https must be enabled anyway and you must not use http in your login form. What your developer is saying that by limiting the application to be served as https only (should be configured in the web server) even if the password is sent in clear text in the form, the whole traffic is encrypted and hence the password is safe. That is correct. Even if you hash ...


6

You cannot know what tools exist. Actually, if the attack pattern can be enunciated ("just use three random words from a list of common words") then it can be translated to code in a matter of minutes. That the already-compiled, ready-to-run tool is not accessible from a single Google search and a couple of clicks does not mean that it does not exist, only ...


5

From the attacker's standpoint, whether you send a plain text password or a MD5 hash or it doesn't make much difference, as long as sending the same value over again unlocks the door. Remember, getting in is the primary objective, not obtaining the exact value of the password. So if the attacker intercepts the hashed password, sending it again from his box ...


5

if your hashing algo is irreversible and secret This is always a bad design practice. As soon as this algorithm becomes known to the attacker (and it will), you are doomed. Thus all designs should assume that algorithms are known to the attacker. Keys should be kept secret, not the algorithm -- keys can be easily replaced, but algorithm cannot. Please, ...


5

one I like That is the bane of precise entropy calculations: human psychology. It is hard to quantify precisely how much the attacker can model your aesthetic choice. There are two extremes: The attacker may totally fail to guess what kind of password you like or don't like. In that case, your selection cannot be exploited by the attacker, and the ...


5

When you use an "authentication token", the simple presentation of that token by the client grants access (as long as the token is deemed valid by the server). If you store the tokens "as is" in your server's database, then an attacker who could get a glimpse at your database will immediately learn all the tokens, allowing him to send requests in the name of ...


5

Explain it in terms of lines of defense. Obviously, you're going to be doing everything you can to make sure that your code is secure. But the fact is, your server will not only run code that you wrote, and you have no control over the code written by other people. Even if all of the other code on the machine is open-source, you would need to hire another ...


5

Assuming your server doesn't use any credentials besides system-level accounts and the MySQL password, there's one thing you need to protect: the swap file. Programs are supposed to take steps to prevent credentials from winding up in swap, but they don't always do so. There are some sensitive things in /dev and /proc (such as /dev/mem and /proc/kcore). ...


5

If nothing else, it's an API for checking passwords without any time delay. It has to be: if they had a time delay after every incorrect guess, it would defeat the point of live-checking the password. If you password is "password", then the server has to check seven incorrect passwords before reaching the correct one, and you can't afford to have a delay ...


5

Maybe a silly question but are you certain you're not getting a ✓ meaning that the password you have entered has met the minimum requirements for the sites password policy? Such that the client side code is saying "yes, this is a valid password and I will accept it, although I have not yet validated the correctness." When you enter the password as ...



Only top voted, non community-wiki answers of a minimum length are eligible