Tag Info

Hot answers tagged

55

For smaller sites, you don't want to allow hackers to enumerate your user lists, but for Google, the site is so large, one can assume almost everyone has an account or several accounts. So, the risk is minimized after a threshold of ubiquity. It is still a good idea for most sites to not disclose whether a username exists, but the risk needs to be weighed ...


41

Jeff Atwood, when making the login for Discourse, had this to say on the subject: This was the source of a long discussion at Discourse about whether it made sense to reveal to the user, when they enter an email address in the "forgot password" form, whether we have that email address on file. On many websites, here's the sort of message you'll see after ...


26

For Gmail, you can determine whether an account exists simply by sending an email to an @gmail.com address. If it bounces, that account does not exist. This is true of many email providers. Here, usernames are not considered secret. If a user has the email address foo@example.com everybody knows that foo has an account at example.com with username ...


24

Your argument is contingent upon using a web based service. If you use your password manager for SFTP, encrypted drives, desktop apps, etc. then you don't have a self service reset option. If we then want to continue the argument only for web apps, here are some issues: This requires you to use one email address, which may not be practical (work versus ...


17

General-purpose hashes have been obsolete for passwords for over a decade. The issue is that they're fast, and passwords have low entropy, meaning brute-force is very easy with any general-purpose hash. You need to use a function which is deliberately slow, like PBKDF2, bcrypt, or scrypt. Crackstation actually explains this if you read the whole page. On the ...


15

No a salt should not be derrived from other known parameters, a salt should be globally unique. So the best you can do is to generate a really random salt for each password. Todays operating systems have a "random source", on a deterministic computer it is the best you can do to read form this random source (DEV_URANDOM). Beside this, the SHA-* hash family ...


15

They trim passwords to deal with the (sometimes insecure) process of people copying and pasting them.


14

As @cpast says, the main problem of a single SHA-256 is that it is way too fast. An attacker with an off-the-shelf gaming GPU can try passwords at a rate that is counted in billions per second (American billions, but that's still a lot). Another problem is that there is potential for combining things improperly. SHA-256 is a hash function: it takes one ...


13

Context is everything. storing passwords via encryption is like storing passwords in plain text. This advice is about client programs implementing a faux password manager that stores password to access online service in encrypted format so you don't have to type the password to access that service at all. This kind of encryption is moot because to ...


12

The vast reduction in risk you enjoy simply by using a password manager (no password reuse, stronger passwords, phishing resistance, etc.) dramatically outweighs any minuscule additional risk of keeping your email password in the same vault. That is, assuming you protect the password vault with a strong password. Additionally, those accounts are the ones I ...


12

Drilling a bit deeper on the copy and paste issue: Microsoft products, particularly the Office suite, are notorious for attempting to help by adding trailing white space to items copied from, say, Outlook and pasted elsewhere. The purpose of doing this is so that you don't have to be as careful where you place the cursor when copying and pasting to avoid ...


10

Yes, your steps appear to be correct. The attacker hashes lots of words or sequences of characters until she finds one which matches the target hash. Pseudocode: hashlist = [ "a235b8320c...", "688b4302c57f3...", ... ] wordlist = file.readlines("/path/to/wordlist") for each word in wordlist: h = hash(word) # is the hash of this word in the list of ...


9

Because they trim whitespace. The why of that is not known, but is not unusual, and often is related to the inability for humans to discriminate - you and I know that foo bar has a space in the middle, but it's hard for us to say how many spaces are in foobar if any of them are trailing. Judging from productforums posts, this policy is not new.


9

start typing characters., Once the password is valid, the red text goes away, indicating a valid password. This kind of behavior doesn't necessarily violate PCI DSS requirements. If the site works the way you describe, it's not very good from a security point of view because it makes brute force attacks more difficult to detect -- but that doesn't make ...


8

I'm sure that rule developed in the days of 'big iron', when all accounts were on big corporate or government systems. Since the system doled out the account names, the use of a sign-up page to look for account names wasn't an issue. Thus, keeping the list of account names was feasible & useful. Now that we're dealing with self-sign-up sites, it is ...


8

My answer would be no, they are not obsolete. Your scope is too narrow. You are thinking all passwords stored in a password manager can be reset. You do not account for: passwords for operating systems passwords to protect certificates passwords to protect network equipment These passwords cannot be "reset" with a simple reset link and require more ...


7

Your companion is right that the least restrictive policy has a higher potential entropy, as it can encode a larger amount of information. This being said, the entropy of a set of data depends on the probability distribution of each datum appearing in the dataset. Therefore, the quality of a password policy should not be measured in terms of how much ...


6

Bcrypt is run many times to intentionally slow it down. Perhaps you need to adjust the number of rounds of bcrypt you are running? This answer has some information on it. While what you propose may work, I can't say that implementing a variant of standard password handling is a good idea. While I have specific concerns, such as the SHA hash staying in the ...


6

Knowing which username exists or not is not important, because an attacker can also check it from the sign up page. Google does not allow that an attacker runs an attack like brute force attack for obtaining a username list.


6

There are two things wrong with what you are doing with what you are doing: your algorithm in it's simple form is fast and thus not suited for password hashing. (the properties you want in a password hashing algorithm is it being fast enough to run once, but slow if you need to run it several times as well as being unfriendly when being run on FPGA/ASICs ...


6

It depends what you mean by "enhance security". On the one hand, yes, it's more pieces of information for a thief to steal, but on the other hand, if they can steal one password, chances are they can steal all your passwords. For a great discussion on multi-factor authentication see this answer. by @tylerl. The Cole's Notes is: we like to have multiple ...


6

sha256 is not designed to hash passwords. To hash passwords, you should prefer to use hash functions created for this usage. You will find all required information below in another question addressing a similar request: Most secure password hash algorithm(s)?. In the above mentioned question, you will learn why general purpose hash functions like sha256 do ...


5

There's a more important reason for prompting for username first and then prompting for password: it allows Google to offer a different UI for accounts that are using passwordless authentication or other experimental login mechanisms without revealing beforehand which accounts are using it. It's similar to how Google's 2Factor auth UI isn't displayed until ...


5

This seems good except that it is vulnerable to a phishing attempt / rouge site that can get me to enter the OTP & then use it on the fly to get access. This is what x.509/TLS certificate is supposed to prevent. If: you trust the underlying mathematics of x.509 certificate and TLS, both the server and the client has implemented TLS correctly, the ...


4

Email addresses are not the same as usernames. A username is semi-private information (potentially), but an email address is publicly disclosable and publicly routeable. Think about postal mail, the mailing address if often well known, but the current list of valid recipients is not necessarily design to be public, although there are often ways to look that ...


4

I'm going to disagree with your premise that it makes sense to keep some passwords out of a (secure and non-proprietary) password manager. While it might seem like some passwords might make sense outside of it I think those might be limited to two types: A full-disk encryption key on a device which contains your password manager itself. This is mostly ...


4

Start collecting data There is no "was_compromised" database setting that gets changed when a breach happens. You'll have to monitor your evidence now, and look for suspicious activity. You should look into the concepts around Intrusion Detection more broadly, but I'll give some database specific ideas to get you started. Essentially, start logging ...


4

I believe you are asking the wrong question. The correct question would be, in this day of 100 different accounts by each person (email, forums, websites, etc.) can you remember a different password for each one? No, you realistically can't. And, with the prevalence of hacks that steal the password database (encrypted or not) from one website or ...


4

A drawback of SHA1 is that it is fast, so it is easier to create rainbow tables and brute-force it. Adding a salt helps, but if the password is weak, then "number + weak password" may well be in the rainbow tables along with the password. PHP provides built-in password mechanisms. When you use these, the crypt function automatically generates a salt for you ...


4

It's probably a usability issue. It's very easy to unintentionally accidentally add a space to the beginning or end of a username or password, especially on certain types of devices: mobile with autocomplete, people typing via voice, people using assistive technologies that auto-insert spaces, copying and pasting passwords, etc. The other day I was ...



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