148

They do not need to be able to read your password to test it against known weak and guessable passwords. All they need to do is to try all the guessable passwords against your password. It can be properly hashed and salted, as they are supposed to do. They can do this quickly because they have legitimate access to the password hashes and can simply have ...


105

This is a bad idea. As user mentioned in a comment, anyone with physical access can just press the assigned macro key and the password will be revealed. You also have a high chance of accidentally pressing the macro key, thus typing in your password in places where you didn't mean to. The macro data also needs to be stored somewhere, and is likely stored ...


102

Password managers are not meant to hide your passwords from yourself It's as simple as that. To whit: most password managers let you view your own password anytime you want anyway. I say "most" only because I haven't used them all. I've worked with a few sites where auto fill doesn't work for reasons outside the password managers control. Therefore ...


97

You didn't actually set up 2FA. You set up your authenticator as an alternative method of single-factor authentication. This is clear from the first screenshot: "... to sign in without a password". If it didn't ask you for a password in the first place, it's probably not 2FA; the password is one of the two factors. The way I read this question it ...


96

Should I be concerned about this? Yes. This should be of concern to you because an attacker was able to obtain the valid password for your Gmail account. From the details of warning you have provided, it looks like it is from fraud detection rather than an OTP failure. If it was an OTP failure, you would have received an OTP when that login attempt was ...


90

First of all, let's keep in mind that vendors of biometric solutions have a vested interest in badmouthing passwords to promote their own products and services. There is money at stake. They have something to sell to you, but that doesn't mean you will be better off after purchasing their stuff. So one should not take those claims from vendors at face value. ...


89

Yes, decent password managers are more secure than using any password pattern. You have a password manager, and it has created you random passwords: 6AKQ3)mcV!xX3b8-ZgncCe%tdn!&.@3X a6/4TFaWKrzTHQyT2Df#;/*+QA$zH2tJ 9y__&%7jP4UcuG(9f7X6z44C#64bF:m& 9W649r788_8AU=9272zuGH"=C?2&C66j nT29HMc$y'H)ww2#D/2x(2sBU#WG23us Versus you have a pattern ...


89

As a password cracker, I encourage all of my targets to use this technique. 😉 This (understandably!) seems like a good idea, but it turns out that against real-world attacks, wrapping an unsalted hash with bcrypt is demonstrably weaker than simply using bcrypt. (EDIT: First, to be clear up front, bcrypt(md5($pass)) is much better than md5($pass) alone - so ...


78

Language-specific characters are typically avoided by password generators because they would not be universally available (US keyboards don't have accented characters, for instance). So don't take their omission from these tools as an indication that they might be weak or problematic. The larger the symbol set (a-z, A-Z, 0-9, etc.) the larger the pool of ...


75

The main reason passwords need to be long and random (i.e. high entropy) is to protect against offline brute force attacks. Passwords are usually not stored in plain text. Instead, they are hashed. If someone steals the database with the hashed passwords (this is surprisingly common), they can not directly read the passwords. Instead, they have to try loads ...


72

A limit is recommended simply to avoid exhausting resources on the server. Without a limit, an attacker could call the login endpoint with an extremely large password, say a gigabyte (let's ignore whether it's practical to send that much at once. You could instead send 10MB at a time, but more quickly). Any work the server needs to do on the password will ...


71

Thinking of it as "password protection" slightly misrepresents the actual situation. What happens when you password-protect a zip file is that the archive is encrypted using a symmetric algorithm (same key to encrypt and decrypt) using the password as the key. The unzipper program "checks" whether the key is correct the same way I check whether the key to ...


68

You should never try to secure a "real" web application with a scheme that you invented on your own. As such we shouldn't discuss practicalities on how you would actually implement or use such a method. Will it work? Your scheme does not send a password over the wire. What immediately jumps out is that you send the private key to the server, which never ...


68

YES! All passwords should only contain printable ASCII characters. Not "Extended ASCII", not Latin-1, not Unicode. The reason is that you never know what is actually received by a program when you press "à" or similar. In many version of "Extended ASCII", "à" is encoded as (hex)85. In ISO Latin-1, "à" is encoded as (hex)E0. In Unicode "à" is codepoint U+...


55

It's generally undesirable to have multiple people knowing the same password. Instead, systems that requires multiple user to be able to access the same resources usually requires each user to create their own accounts, each with their own password that's only known to themselves, and the system would simply allow all the users to access the same resources. ...


53

They could be, phishing sites are set up to do exactly this. On non-malicious sites, this would be generally be considered poor practice, but there is no reason why they couldn't, beyond user privacy regulations.


46

SHA-512 PROS: Due to the avalanche effect, every single modification to the suffix will change the SHA512 sum entirely. This means that from one N first letters of one hash you can't say anything about the N first letters of another hash, making your passwords quite independent. SHA512 is a one-way compression function, so you can't deduce the password ...


44

In General There's not really one answer to this question, and I wouldn't necessarily consider "large companies" to be a distinct thing with different approaches. Certainly, the particular companies you have named have their own way of doing things, but the people who would be best able to answer for them are employees of those companies. As for ...


42

From a usability standpoint, it's awful. You need to generate a hash each time you want to log in. Even using a password manager to look up truly random strings would be less work. From a security perspective, you have combined the problems of hashing client-side and using a password pattern: Yes, using a password hash on the client-side means that your ...


41

Password managers are the accepted and recommended solution to this problem: NCSC (UK): https://www.ncsc.gov.uk/blog-post/what-does-ncsc-think-password-managers CERT (US): https://us-cert.cisa.gov/ncas/tips/ST04-002 ENISA (EU): https://www.enisa.europa.eu/news/enisa-news/tips-for-secure-user-authentication NISC (Japan): https://www.nisc.go.jp/security-site/...


39

Facebook authentication, when I left, focused heavily on multifactor authentication. Both Facebook and Google invested in purchasing Yubikeys, and Google went on to develop U2F which became FIDO. Server access was based on signed SSH certificate issuance. There was a "break glass" ssh key that was physically stored in a safe as well as a few "...


37

It depends on the specific zip crypto algorithm. For example, the original ZIP specification used the password to initialize a set of three 32-bit decryption keys. Then the ZIP header (12 random bytes placed at the beginning) was decrypted and then: "After the header is decrypted, the last 1 or 2 bytes in Buffer SHOULD be the high-order word/byte of ...


37

The fundamental issue is that entropy can only be estimated from the password itself, and that estimate can be very very wrong. The entropy is determined by the password generation method. You can't measure the entropy of the method from a single password. Let's look at a practical example. I find it easiest to memorize very long passwords generated from ...


36

It's not as simple... About online bruteforce If account become completely locked after 3 attempts, it will be easy to make DOS (Deny Of Service) by locking all accounts! Server have to base locking decision not only on number of bad tries, but will use IP address, Browser ID and include duration for locking, so if someone just use wrong keyboard, they ...


36

While Royce's answer is correct in that wrapped hashes are weaker than unwrapped pure bcrypt hashes, it must be noted that they are nevertheless significantly stronger than your current implementation with a weak hash algorithm and no salt, since an attacker would have to go through the effort of individually attacking each hash, instead of simply using ...


34

In addition to what nobody said there's a more practical, but mostly internal, requirement here. Changing a local password in Windows without knowing the original password is called a reset. Resets cause DPAPI keys to be invalidated (because they're protected by a primary secret based on the user password). Once the reset happens those original keys are dead ...


32

The math may be right. One could refine and complicate it as much as desired, but it doesn't really add to the point. So I'll leave it be. Also, in practice it is easier—and might be faster—to check for any random character password with a fixed length than to check unique passwords from a list. A password list with 243 passwords with an average ...


32

The tests for any policy are: people know about it people understand it people know if they are complying with it people know how to comply with it Your approach is about 2 out of 4 on that scale for the average user. The better option is to demand randomly generated passwords. That's easy to understand, easy to implement, and easy to provide processes ...


31

I work for 1Password. We do have a number of large companies using 1Password, but we do not talk about our customers without their express permission. Note also that we can't see what is being stored where, so we can't really infer from what we can see how they are handling some of the questions very good management questions you asked. However, we sometimes ...


30

I think the general answer here is that passwords are not normally logged by any legitimate service. Usernames certainly are. To record passwords is a problem, even for the "correct" site. Services should not know what your passwords are, which is why there are some complicated processes used to store passwords. I have seen some very poorly designed ...


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