'The name or password you entered is not correct' Why not narrow it down?

What are these websites that don’t give out your username to absolutely everyone? Even places that change one’s display name tend to leave you some way to figure out the original name.

Still, obscurity is only a poor security method when it is used instead of something else. It’s perfectly fine when added on top of an already secure system. There may not be much point, but it doesn’t hurt, so why not?

Now, constantly changing it–yeah, that’s stupid. But only in the same way as passwords, as people will write them down.

Yes. It’s typical of people who parrot that phrase and don’t understand it and it’s surprising how many security professionals don’t understand what they’re saying.

Keeping things obscure is a bad practice if it’s your only method of security. As part of a security system, it’s essential. The less publicly available information, the more secure you are.

Consider: suppose you have an online bank account. If that’s the only public information people have: “I have an online bank account,” you’re more secure than if you say, “I have an online bank account at Wells Fargo bank.” The latter information now allows people to look at one bank instead of hundreds. If you give them your userid, you’re even less secure. Maybe I need to guess the password, but what account to attack and where it is.

So the less information you give out, the more secure you are. It is wrong to expect that will protect you by itself, but it is just as wrong to say it is not an effective method of securing your account.

Facebook is a good example. You log in using an e-mail adress (which can be perfectly secret if need be, but often isn’t), which has nothing to do with the username or your real name. In essence it adds a layer of security, because being the owner of your e-mail account (which can be made extremely secure) further authenticates you (as the creator of the account, not your identity).

As you said, it doesn’t hurt, and it discourages denial-of-service attacks against individual users, as well as data mining, which can be used for other types of attacks. When making a security assessment of a system (imagine that this is your bank), obscurity can’t be counted on. In a cryptographic parallel, an attacker is always presumed to have both the plaintext and cryptotext, and be fully aware of the cryptographic algorithm, yet still not be able to use that information to intercept future communications. Mant cryptographic systems are open source (customers demand full insight), so can’t rely on obscurity even if they wanted to.

You’re basically contradicting yourself. If you consider obscurity essential, then you are factoring it into the security of your system. But true obscurity is an illusion and once it ceases to exist can never be reestablished. You’re far better off making the information public to begin with (also raising chances that your holes in your core security will be uncovered in good time) and always presuming that an attacker has access to that information.

I believe that your example doesn’t hold for the following reason: You are unlikely to be specifically targeted. An attacker, unless motivated by a personal grudge against you, is far more likely to target all customers at your bank rather than you personally, so when figuring out how secure your money is, the obscurity of your bank is not a factor you can rely on.
Anyway, once you’re logged in to your bank you are relying on a securely established SSH tunnel running medium to heavy encryption (+2048 bit). The time required to figure out what bank you’re using is trivial in comparison to trying to factor a couple of multiple thousand bit primes. Returning to the mattress example, it’s like adding the security of a door knob to the two ton adamantium safe standing behind it.

In any case, I was originally criticizing to KneadToKnow’s example of hiding money under the mattress and not telling anybody as entirely void of security. In what way do you disagree with that statement?

Exactly.

I’d prefer to *keep the information private *and assume that an attacker has access to it.

Another aspect to this whole debate: I already know a username that will grant me access to all of your accounts. I don’t need to know your own personal username; I can just log in as root.

Now, one of two things will be the case: Either the password on root isn’t good enough, and I can log in that way and get all the information I want, or the password on root is good enough to keep me out, in which case you have to ask why all the other accounts don’t have passwords that are just as good.

Normally they are (besides the fact that most *nix distributions have done away with the root-account and instead grant sudo-access to individual users). Knowing a username in itself is not a security breach, but gaining access to the list of users does open up for other types of attacks.

Let me guess. You’ve never actually studied computer science.

I LOL’d.

Perhaps an anecdote would help here.

I used to work in the security department at a very large internet company that takes security very_seriously.

One day another department changed the login page to give the user the exact feedback that is described in this thread (meaning letting the user know if it was the password or the userid that was incorrectly entered). They did this since password/userid recovery was the #1 cause of customer service contacts (as it is for most companies as far as I’ve experienced).

In the month subsequent to this change the security department noticed a significant increase in failed login attempts. We’re talking in the millions of extra attempts.

Obviously, this did not represent a security “breach” persay since these attempts failed but the attacker was doing this behavior in order to direct other attacks at the company’s users in a more direct and effective way.

Needless to say this small change in the login UI was quickly reversed so that they wouldn’t be revealing such pertinent information to any random person that has access to the login page.

Exactly. I’ve got your user name and the system it’s for. Now, a quick poke at Facebook will probably give me the names of your pets and/or kids, favorite color, favorite food, your spouse’s name, etc.

Now I can bang away at one system and one ID with a half a dozen or so likely passwords. Still feeling secure?

Or, if the bad guys get ahold of the system’s password file, and they know an ID on the system, it’s fairly trivial to run “crack” on the file with that known ID and soon have everyone’s ID and password. Of course, if they can get the password file, they probably already have elevated access to the server and the game’s over.

I just feel the need to point out this excellent username/post combo.

Not quite. The password file will either be rather heavily hashed or encrypted using an appropriate crypto function such as Blowfish. You won’t have enough time to extract any cleartext from such a file before the sun runs out of fuel. The hashed passwords themselves give no access at all, presuming that the system doesn’t have any other serious security flaws.

Also, agree on the excellent username/thread combo. =)

For a single hash this is true. However a password file is not a single hash, but contains many entries. The more entries, the better your chance of finding a rainbow table match.

Add to this users’ very common habit of using as passwords their spouse’s name, their kid’s name, their pet’s name, important dates, or dictionary words, and it’s much, much easier to break passwords than non-professionals may realize.

Ehhh… Go tell that to my Unix server admins. They crack password files when they’re bored. There used to be a commercially-available application with a name that sounded similar to “softsnack” that was excellent for auditing and recovering passwords. Useful tool to have in case a disgruntled admin started changing root passwords before leaving.

Give it a good set of rainbow tables and it’ll probably get you the passwords in a handful of hours. One bit that really makes it easy is the default of an 8-character password length limit in most *nix systems.

Windows 2008 Server makes it a lot harder - the max length there is 128 characters, and I believe you can use Unicode, which takes you from about 40 possible characters to something closer to 100,000 unique characters. The sun may still be shining when you crack that, but assuming the system requires password changes every 60 days, the password you crack will be a few thousand changes ago. Odds are, it will be 123456.

Wow! That’s the same password as my luggage!

Note that, even at the #1 spot, that’s still less than 1% of users. It’d still be easy to come up with a practically-usable list that would give you a significant fraction of all passwords, but you’ll need a little more than one try.

And what is RockYou, anyway? Is it the sort of thing that people would actually need good passwords for? Because even though I do know about password security, and will use strong passwords when it’s called for, I still use a weak password when there’s not much at stake.

Ah yes, too true. That is, if you haven’t bothered salting your hashes. In that case you’re pretty much back to square one.

gotpasswords, *nix systems haven’t been limited to 8 characters for the last decade or so, ever since they dropped DES and wen’t over to MD5 (which is fine for short hashes), or most flavors of SHA if you’re feeling paranoid. Many systems have since time immemorial used Blowfish, which is particularly due to its know strength against rainbow attacks.

But seriously, you’re saying that SHA2 has been so seriously compromised? Dear lord, that’s news to me. And the NSA. *Call the scientists! * I’ll happily provide a bunch of nicely salted hashes in SHA512 if your sysadmins would like to take a shot. And if your sysadmins are still using DES to hash their passwords, then I say get new sysadmins.

That, on the other hand, is an entirely different issue.

You can force users to remember passwords up to 10-12 characters or so (being rather optimistic), but past that you’re back to phrases and post-its.

Oooh…explain to me how you’re going to make that work in practice?

This is of course a question of religion, but I believe that time limited passwords are more of a risk than an advantage. It leads users to either use simpler passwords (because they have to memorize them all anew), or start writing them down on post-its or in notebooks.

Hey, any of you security guys want to weigh in on my thread?