A researcher has devised a method that reduces the time and resources required to crack passwords that are protected by the SHA1 cryptographic algorithm.

The optimization, presented on Tuesday at the Passwords^12 conference in Oslo, Norway, can speed up password cracking by 21 percent. The optimization works by reducing the number of steps required to calculate SHA1 hashes, which are used to cryptographically represent strings of text so passwords aren't stored as plain text. Such one-way hashes—for example 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 to represent "password" (minus the quotes) and e38ad214943daad1d64c102faec29de4afe9da3d for "password1"—can't be mathematically unscrambled, so the only way to reverse one is to run plaintext guesses through the same cryptographic function until an identical hash is generated.

Jens Steube—who is better known as Atom, as the pseudonymous developer of the popular Hashcat password-recovery program—figured out a way to remove identical computations that are performed multiple times from the process of generating of SHA1 hashes. By precalculating several steps ahead of time, he's able to skip the redundant steps, shaving 21 percent of the time required to crack large numbers of passwords. Slides from Tuesday's presentation are here.

"This technique reduces the computational cost of testing candidate passwords when one is given the SHA1 hash of an unknown password," Jean-Philippe Aumasson, a Switzerland-based cryptography expert, wrote in an e-mail to Ars. "In mathematical terms, it does so by avoiding redundant operations—that is, operations that have to be performed regardless of the password tested."

Because SHA1 uses a single iteration to generate hashes, it took security researcher Jeremi Gosney just six days to crack 90 percent of the list. Had the same passwords been hashed using an algorithm specifically designed to protect passwords—algorithms such as Bcrypt, PBKDF2, or SHA512crypt—it would have taken Gosney years or even centuries to accomplish the same feat. The latter three hashes are better suited to password storage because they require significantly more time and computation to convert plaintext into hashes.

"Note that using SHA1 for password storage (with or without a 'salt') is not a very good practice anyway," Aumasson wrote.

Steube's research is only the latest method for speeding up the process of generating SHA1 hashes. The official SHA1 specification calls for 1,448 distinct steps to calculate a hash. Before now, Gosney said, crackers had already figured out how to reduce the number to 1,372, and by using special hardware instructions supported by graphics cards manufactured by AMD, many crackers were further able to cut the steps to 868.

"This is where we have been for a few years now, and we all thought this was pretty damn good," Gosney told Ars.

Steube's optimization cuts an additional 134 steps out of the SHA1 hashing process. The method works by eliminating XOR logical operations during the expansion phase of generating a SHA1 hash. Expansion acts as an amplifier of sorts that allows a hash to contain more data than is found in the originating plaintext. Because many of the steps in the process don't rely on the plaintext, they can be carried out using precalculated data.

A 21 percent optimization is impressive, but it's modest when compared with the password-cracking gains that have been achieved in the past few years. The use of graphics cards alone allows inexpensive computers to work thousands of times faster than they did just a decade ago on similarly priced PCs that used traditional CPUs alone. As a result, a PC running a single AMD Radeon HD7970 GPU can try on average 8.2 billion password combinations each second, depending on the algorithm used to protect them. So while the technique unveiled on Tuesday is impressive, it's important to put it in perspective, cracking experts said.

"I don't want to downplay 20 percent, which is significant," Rob Graham, CEO of penetration testing firm Errata Security, told Ars. "But it's not on the order of, say, switching from a CPU to a GPU."

Promoted Comments

Note that this is _NOT_ a SHA1 vulnerability. This discovery simply allows to optimize SHA1 implementations, which was exactly one of the main design goals of SHA1 (as it is for most other hash algorithms, including the newly selected SHA3).In fact, this discovery has hence _IMPROVED_ SHA1.

Ars could as well have titled: "Intel has released a 20% faster CPU - Oh noes, now all of your passwords can be broken 20% faster!!!"In fact, why didn't Ars declare all hash functions to be broken when people started using GPUs, which are a thousand times faster at this task?

However it is true that it is a "weakness" of all general-purpose has functions such as SHAx, MD5, etc. that they are not designed for passwords but rather for large files. For passwords, thousands of runs of SHA1 have been used by advanced operating systems for years, but hash functions that require huge amounts of memory as well as CPU power should be preferred, with one example being scrypt.

I think you misunderstood the 20%. The new method allows 20% faster cracking on the same hardware.

Should we get used to this...? Changing all of our underlying password systems every ten years? I remember in 2000 how MD5 was adequate and SHA1 was the new future-proof kid on the block. How things have changed.

Not really. As far as I know SHA1 is still considered "safe" in the sense that it is infeasible to forge data so that it has the same hash as something else (to e.g. inject malicious code into a signed executable). MD5 does have a number of vulnerabilities in that regard.

However, SHA1 and MD5 were never really suited for the task of hashing a password, e.g. for securely storing the password hash associated with a user on a website (so that when the user later on enters their password, we hash it and compare with what is stored to see if it's the same). These hashing algorithms are supposed to be fast, so they can quickly create a hash for many different situations.

However, when storing passwords, we actually want them to be slow, so something else, like bcrypt should be used. The scenario is one like the LinkedIn leakage, where attackers have gotten a hold of the user database, and then try to "mine" as many passwords as possible. Assuming the database is salted, so they have to bruteforce it, then using a "slow" algorithm like bcrypt could mean that it takes orders of magnitude longer for them to crack a given password. That it takes e.g. 300 ms to do the hash, is no big problem when the user logs in (because it's only done once) but very important when an attacker is doing it millions and millions of times in a row. Even better, bcrypt has what is basically a "do this x times" parameter, so as time goes by and computers get faster, we can just increase X to make sure it's still "slow enough" on recent hardware and stay ahead of the attackers.

TL;DR. Don't use SHA1 for password hashing, use bcrypt (and remember to salt)

71 Reader Comments

Should we get used to this...? Changing all of our underlying password systems every ten years? I remember in 2000 how MD5 was adequate and SHA1 was the new future-proof kid on the block. How things have changed.

Should we get used to this...? Changing all of our underlying password systems every ten years? I remember in 2000 how MD5 was adequate and SHA1 was the new future-proof kid on the block. How things have changed.

SHA1 is a secure hash, the problem is that hashes are not designed to protect passwords. That was true a decade ago, but has become more obvious now that any casual hacker can test billions of passwords a second.

A good hash is supposed to run quickly, so being able to run billions of hashes a second is a feature, not a bug, in terms of hash algorithm design. A good password protection algorithm is designed to run slowly (tens to hundreds of milliseconds), and preferably should use lots of resources (e.g. memory). The Scrypt algorithm is an interesting new technique for password hashing that tries to maximize the amount of memory used, because a CPU running one PW hash has tons of memory; a GPU running 1000s of hashes simultaneously has very little memory per hash.

Note that this is _NOT_ a SHA1 vulnerability. This discovery simply allows to optimize SHA1 implementations, which was exactly one of the main design goals of SHA1 (as it is for most other hash algorithms, including the newly selected SHA3).In fact, this discovery has hence _IMPROVED_ SHA1.

Ars could as well have titled: "Intel has released a 20% faster CPU - Oh noes, now all of your passwords can be broken 20% faster!!!"In fact, why didn't Ars declare all hash functions to be broken when people started using GPUs, which are a thousand times faster at this task?

However it is true that it is a "weakness" of all general-purpose has functions such as SHAx, MD5, etc. that they are not designed for passwords but rather for large files. For passwords, thousands of runs of SHA1 have been used by advanced operating systems for years, but hash functions that require huge amounts of memory as well as CPU power should be preferred, with one example being scrypt.

Should we get used to this...? Changing all of our underlying password systems every ten years? I remember in 2000 how MD5 was adequate and SHA1 was the new future-proof kid on the block. How things have changed.

Yes, and in 2000 the fastest supercomputer had less processing power than my 2 year old video card does. You should be changing a lot more than just password encryption every 10 years.

New systems have no excuse whatsoever. I can't imagine what kind of idiot would choose SHA-1 when designing security for a service like LinkedIn.

We need to stop trying to be "good enough" with our passwords and step up our game. As end-users, there is nothing that we can do besides use Loooooooooooooooooooooooooong, unique, passphrases for our logins. Stop screwing around with 12, 14, 25 characters. Use a password manager and you don't care how long the password is anymore except for a few accounts, once every few years. For the rest of the accounts, it doesn't matter at all - think 60+ characters. When you do care about those few passwords (new android device/gmail connecting), just change the password to something shorter for the short period you need it short, then pull your password DB over to that device and make it long again. It doesn't happen THAT often. Then we are back to our 60+ character passphrases that we never type again.

Seriously, governments have been storing encrypted data from the last 30 yrs and are using current hardware to crack passwords. We may not be important today, but we each my become very important in the future and not want our data easily viewed. 60+ characters means brute force methods probabaly will not be useful. It doesn't mean that other attacks won't work or weaknesses in the cypher won't be discovered and used, but with a password manager - password length really isn't an issue anymore.

None of this will prevent noob developers from choosing bonehead or insecure password handling methods. None of this will prevent CEOs, Marketing VPs, and company presidents from asking "are you done with that yet?" well before it is secure either.

Start thinking about creating long enough passphrases that won't be broken for 30-50 yrs. You never know what use your data may have.

In any case, what I found interesting was that they were still using password guesses, just doing them very quickly. You can foil this by merely having an unguessable password. Yes, OK, with enough free time all passwords are guessable, but some have more entropy than others.

Note that this is _NOT_ a SHA1 vulnerability. This discovery simply allows to optimize SHA1 implementations, which was exactly one of the main design goals of SHA1 (as it is for most other hash algorithms, including the newly selected SHA3).In fact, this discovery has hence _IMPROVED_ SHA1.

Ars could as well have titled: "Intel has released a 20% faster CPU - Oh noes, now all of your passwords can be broken 20% faster!!!"In fact, why didn't Ars declare all hash functions to be broken when people started using GPUs, which are a thousand times faster at this task?

However it is true that it is a "weakness" of all general-purpose has functions such as SHAx, MD5, etc. that they are not designed for passwords but rather for large files. For passwords, thousands of runs of SHA1 have been used by advanced operating systems for years, but hash functions that require huge amounts of memory as well as CPU power should be preferred, with one example being scrypt.

I think you misunderstood the 20%. The new method allows 20% faster cracking on the same hardware.

Should we get used to this...? Changing all of our underlying password systems every ten years? I remember in 2000 how MD5 was adequate and SHA1 was the new future-proof kid on the block. How things have changed.

Not really. As far as I know SHA1 is still considered "safe" in the sense that it is infeasible to forge data so that it has the same hash as something else (to e.g. inject malicious code into a signed executable). MD5 does have a number of vulnerabilities in that regard.

However, SHA1 and MD5 were never really suited for the task of hashing a password, e.g. for securely storing the password hash associated with a user on a website (so that when the user later on enters their password, we hash it and compare with what is stored to see if it's the same). These hashing algorithms are supposed to be fast, so they can quickly create a hash for many different situations.

However, when storing passwords, we actually want them to be slow, so something else, like bcrypt should be used. The scenario is one like the LinkedIn leakage, where attackers have gotten a hold of the user database, and then try to "mine" as many passwords as possible. Assuming the database is salted, so they have to bruteforce it, then using a "slow" algorithm like bcrypt could mean that it takes orders of magnitude longer for them to crack a given password. That it takes e.g. 300 ms to do the hash, is no big problem when the user logs in (because it's only done once) but very important when an attacker is doing it millions and millions of times in a row. Even better, bcrypt has what is basically a "do this x times" parameter, so as time goes by and computers get faster, we can just increase X to make sure it's still "slow enough" on recent hardware and stay ahead of the attackers.

TL;DR. Don't use SHA1 for password hashing, use bcrypt (and remember to salt)

Using an English word with a misspelling or number tucked in: Bad, easily crackable.

Picking four random English words: This SHA1 technique won't work at ALL.

Something to think about.

Offline cracking will work very well on a four-word XKCD-style password. 44 bits of entropy (like in XKCD) takes 36 minutes to crack at 8.2 billion guesses a second (1 GPU, from the article).

If you're worried about offline password cracking, the only solution is to use a password manager, with 20+ character completely random passwords (6 bits/char gives 120 bits of entropy, which takes billions of years to crack).

I recently revisited/updated all my online passwords to eliminate duplication across sites, and encountered many different insecure password limitations on some pretty big financial sites. Limits like 'no more than eight characters' (seriously) and 'A-Z and 0-9 only'. With policies like these who needs hackers?

I'd love to see Ars or some other visible tech site review the top 100 banking/commerce sites and publish their password limitations (and also reveal their [in]security questions as well). Then publish the results in hopes of shaming the worse offenders. This is happening now each time there's a newsworthy security breach, but it's only piecemeal. Let's see just how amateurish the big sites really are in terms of so-called 'security'.

SHA1 was not designed to store passwords, it was designed for message signing. This distinction is important because if you want to determine if a message is authentic (ie, it is "signed") you want this operation to occur as fast as possible while also having 0 rate of false positives (collisions).

SHA1 was used for passwords because it provided a one way hashing function and would not allow 2 passwords to have the same hash. On the downside, it also inherited the fact that it could perform these calculations extremely fast which is a huge disadvantage when we are talking about brute forcing. I believe it was merely out of convenience, since the algorithm was available with no significant flaws, that it gained popularity for hashing passwords. Also, at the time it was first used the computing power needed to brute force was too high and thus SHA1 was "good enough".

mic_e was correct when they stated this IMPROVES SHA1. Now any messages signed with SHA1 can be verified 20% faster which was the whole intent. If you want to hash passwords, you should use an algorithm INTENDED for hashing passwords like bcrypt, scrypt, pbkdf2 as mentioned in the article.

I recently revisited/updated all my online passwords to eliminate duplication across sites, and encountered many different insecure password limitations on some pretty big financial sites. Limits like 'no more than eight characters' (seriously) and 'A-Z and 0-9 only'. With policies like these who needs hackers?

I'd love to see Ars or some other visible tech site review the top 100 banking/commerce sites and publish their password limitations (and also reveal their [in]security questions as well). Then publish the results in hopes of shaming the worse offenders. This is happening now each time there's a newsworthy security breach, but it's only piecemeal. Let's see just how amateurish the big sites really are in terms of so-called 'security'.

That's a good start, but I'd like to see a big matrix with the top sites listed down the side and security policies across the top. Color-code the weakness/strength of each site's implementation and provide a score-card on the right-most column.

Update the chart until the sites clean up their acts, or get a bright red entry when the inevitable security breach occurs.

We need to stop trying to be "good enough" with our passwords and step up our game. As end-users, there is nothing that we can do besides use Loooooooooooooooooooooooooong, unique, passphrases for our logins. Stop screwing around with 12, 14, 25 characters. Use a password manager and you don't care how long the password is anymore except for a few accounts, once every few years. For the rest of the accounts, it doesn't matter at all - think 60+ characters. When you do care about those few passwords (new android device/gmail connecting), just change the password to something shorter for the short period you need it short, then pull your password DB over to that device and make it long again. It doesn't happen THAT often. Then we are back to our 60+ character passphrases that we never type again.

Seriously, governments have been storing encrypted data from the last 30 yrs and are using current hardware to crack passwords. We may not be important today, but we each my become very important in the future and not want our data easily viewed. 60+ characters means brute force methods probabaly will not be useful. It doesn't mean that other attacks won't work or weaknesses in the cypher won't be discovered and used, but with a password manager - password length really isn't an issue anymore.

None of this will prevent noob developers from choosing bonehead or insecure password handling methods. None of this will prevent CEOs, Marketing VPs, and company presidents from asking "are you done with that yet?" well before it is secure either.

Start thinking about creating long enough passphrases that won't be broken for 30-50 yrs. You never know what use your data may have.

I agree with the idea, but unfortunately I've been using a password manager for ages and I'm constantly left disappointed with the narrow limitations set by the sites that I end up having to create accounts on. 16 characters max is pretty common (wtf?), but I've even seen as narrow requirements as 8-10 characters, only a-z, A-Z, and 0-9... There's just no way you can make a secure password out of that. I'd like to see some pressure on sites to allow a much wider range of passwords, including ANY printable character (why should this be limited to A-Z??) and up to at least 100 characters for those that want it. It's really not going to have a major impact on their storage after all.

Everyone needs to remember that even if their bank / whatever is using asinine 8-character alphanumeric maximums (because their legacy system doesn't allow better) that in a properly-designed security system there are many layers between your password and its offline analysis. Don't lose sleep if you're fully insured against losses due to fraudulent online activity. Hotmail was a good example: they have a 15-char password limit left over AND seem to hint when you get the first 15 right, but their system was most recently cracked by a flaw in the password reset mechanism and not someone leaking the DB.

As a site's account DB isn't getting breached more often than you're rotating your passwords (which a good site or password manager should enforce) then fast offline analysis isn't significantly altering the threat model all by itself.

Adam.S wrote:

Yes, and in 2000 the fastest supercomputer had less processing power than my 2 year old video card does. You should be changing a lot more than just password encryption every 10 years.

Sorry but the fastest single-card GPUs are still around 25% as fast as ASCI White (measured in FLOPS) and don't have anywhere near the amount of memory. The biggest advantage is they don't require 3 MW to operate and another 3 MW to cool.

Whether your GPU can simulate the US nuclear arsenal as well as it cracks passwords is something I don't think anyone here is classified to discuss.

We need to stop trying to be "good enough" with our passwords and step up our game. As end-users, there is nothing that we can do besides use Loooooooooooooooooooooooooong, unique, passphrases for our logins. Stop screwing around with 12, 14, 25 characters. Use a password manager and you don't care how long the password is anymore except for a few accounts, once every few years. For the rest of the accounts, it doesn't matter at all - think 60+ characters.

If you're using the full 96 chars that are type-able on a standard USA keyboard, you only need 19 chars to really max out your security. Last I read, trying to brute force a 128bit key would require consuming all the energy of our sun and 19.4 positions with a 96 char alphabet gets you the same protection.

So, unless you think someone will find a way to harness 100% of the energy in the sun, don't expect them to break even one 20 char password. So why waste CPU time and bandwidth with a 60 char password? That's not eco-friendly.

Actually, a 60 char password has the effective strength of a 395bit key. A 256bit key would require more energy to break than the observable universe has. It would take 6.97e+41 universes of energy to break a 60char password.

I'd love to see Ars or some other visible tech site review the top 100 banking/commerce sites and publish their password limitations (and also reveal their [in]security questions as well). Then publish the results in hopes of shaming the worse offenders. This is happening now each time there's a newsworthy security breach, but it's only piecemeal. Let's see just how amateurish the big sites really are in terms of so-called 'security'.

I would LOVE to see this review. Every time I log into my banking site I cringe about how short my password is. Everything financial seems to have the worst limitations on passwords. I don't understand why security is so archaic in all the places passwords matter most.

Edit: Just saw the Plain Text Offenders link I missed earlier. Interesting, but would also like to see what dlux mentioned.

Also some have mentioned that bad password policy is often not the weakest link. Even if there are other weak links, that's not an argument for an 8-12 character password limited to A-Z, a-z, 1-9, and a handful of special characters.

Does anyone know WHY these password limitations exist? Is/was there some software or hardware limitation that makes limiting passwords to short lengths with a limited number of characters reasonable?

Currently 18 minimum with 2 special characters, caps and lower case required.

So PasswordPassword!! would be fine? Generating 8 character long random passwords for the end user instead of making the user come up with one would be better. Though check the desks, people might write them down on a post-it note.

In any case, what I found interesting was that they were still using password guesses, just doing them very quickly. You can foil this by merely having an unguessable password. Yes, OK, with enough free time all passwords are guessable, but some have more entropy than others.

It's worth noting that with many possible uses of SHA-2, a lot of them are still impractical using mobile devices or web technologies like Javascript.

For example if you need to hash data of any significant size on an iPad 4 (using native code), it's really slow. Same for Javascript which comes into play with offline HTML5 applications that need to encrypt data.

Just saying there still cases where SHA2 is not used deliberately. Of course the trade-offs of lesser algorithms should then be mitigated by design choices elsewhere.

Adam.S wrote:

New systems have no excuse whatsoever. I can't imagine what kind of idiot would choose SHA-1 when designing security for a service like LinkedIn.

We need to stop trying to be "good enough" with our passwords and step up our game. As end-users, there is nothing that we can do besides use Loooooooooooooooooooooooooong, unique, passphrases for our logins. Stop screwing around with 12, 14, 25 characters. Use a password manager and you don't care how long the password is anymore except for a few accounts, once every few years. For the rest of the accounts, it doesn't matter at all - think 60+ characters. When you do care about those few passwords (new android device/gmail connecting), just change the password to something shorter for the short period you need it short, then pull your password DB over to that device and make it long again. It doesn't happen THAT often. Then we are back to our 60+ character passphrases that we never type again.

There certainly are other options, even if we as the end users can't implement them unilaterally.

The reason people use simple passwords and use those passwords everywhere is that there are simply so many to remember. If I had to store a different, random password for every site I visited, I'd be in trouble. I access web sites from my mobile phone, multiple home PC's, and several work PC's. I don't have the ability to securely store every password I use every place I use them. So my strategy is to tier my sites: the highest tier gets unique passwords. The second tier uses a small group of passwords. The third tier uses a smaller group of passwords shared among more sites.

For example, a forum I'll only visit once or twice will get a burner password, but one I'll remember 2 years from now if I have to go back there. My banking passwords are unique to each institution, as are my Google, Live, and Facebook passwords, since all of those act as authentication services to multiple systems, and my Google account has 8 years of messages stored away.

Another important thing is multi-factor authentication. I think the industry has barely reached the tip of the iceberg on this. The Entrust or RSA token is one way to do this. Another method, one Steam has started using, is to email or text the user with a login token the first time you use a new device.The primary consideration here is that you use two completely different channels for communicating with the end user. An attacker would have to have my email password or physical possession of my mobile phone to gain access to my Steam account, for example.

Finally, I don't think most websites should host their own authentication services. Ars, for example, doesn't actually need to store user credentials. Instead, rely on known, secure signon services, such as Google or Microsoft Live. By removing password storage from your average, easily attackable web site, you reduce the possibility of hashes being stolen in the first place. You also make it easier for user to log in to sites on devices such as mobile phones, where entering a 32-digit password with symbols, caps, and numbers is a pain in the... fingers. This also makes it VERY easy to nuke a compromised account: just change my one, universal password, and I'm good.

Personally, I would like to see several new systems put in to play to help protect users:

1. Universal sign-on services.

2. Geographically aware authentication. A service should take extra precautions when a user who lives in Texas suddenly tries to log in from Asia, for example.

3. Multi-factor authentication. Already discussed.

4. PC's and mobile devices should be required to have a simple, fast, remote method to remotely wipe their data and credential stores.

5. Secure services like banks should supplement universal sign on with an additional passcode.

For example: to get to my on-line banking site, I have to be logged in to Live first. The bank then asks for an additional password. Since I'm logging in from a new computer, the bank texts me a code, and I use that to finalize my login.

All of this is already in place, it's just used inconsistently. Part of this may be laziness, but part of it may simply be that implementing all this takes time and money to develop. I'd like to see more public, easily accessible code that makes this stuff standard and easy to implement... basically black box plug and play classes that any programmer can just drop in to his program. If I could go to Sourceforge and grab a c# class that lets me automatically get a user's credentials from Facebook, Google, Microsoft, Yahoo, or Twitter, and I don't have to do the hard work of building my own password system... which do you think I'm going to do?

...I'd like to see some pressure on sites to allow a much wider range of passwords, including ANY printable character (why should this be limited to A-Z??) and up to at least 100 characters for those that want it. It's really not going to have a major impact on their storage after all.

There would be no impact on storage as the hashed passwords are all the same length. The only storage impact would be if they were keeping them in plaintext.

Actually, a 60 char password has the effective strength of a 395bit key. A 256bit key would require more energy to break than the observable universe has. It would take 6.97e+41 universes of energy to break a 60char password.

We need to be concerned about what might be possible in 20, 30 or 40 yrs, not today. Again, since we use password managers, there is no difference between typing 1 or 60 characters. Since that is the case, why not use the longest possible passphrase?

As others have stated, many logins prohibit longer passwords with unreasonable length and character set limitations. Banks and insurance companies are the main offenders, probably because their back-end systems are running 20+ yr old mainframe software. Until these offenders are sufficiently embarrassed and have NYT front-page coverage about their old fashioned security limitations, nothing will change. Some banks have learned and will provide a 2-factor FOB for some account holders.

I am gonna have to hope that having 60+ long character/number/symbol passwords suffices for at least a few years (if not the end of the universe). The odd thing is, running into sites that only allow short passwords - c'mon people, let us have proper (and long) passwords!

The reason people use simple passwords and use those passwords everywhere is that there are simply so many to remember. If I had to store a different, random password for every site I visited, I'd be in trouble. I access web sites from my mobile phone, multiple home PC's, and several work PC's. I don't have the ability to securely store every password I use every place I use them.

I and others like me avoid centralized authentication services. I don't trust them and do not want 1 "holder" having that much power. I'm paranoid, but if google has access to all my credentials, what will stop a government from demanding access to all 3rd party websites that I access? It doesn't matter whether I **need** this protection or not. It is my right and I will not give it up.

Password managers are cross platform, just push the DB to all the systems you need it on. The one I use, KeePassX, supports Windows, OSX, Linux, Android, IOS .... portable versions of the app are available too. It isn't that big of a deal and after the first push, having the latest version of the file isn't really that important. After I change a password to an important login, I'll push the changes everywhere again. Not a big deal at all if the latest version isn't available everywhere. Most logins aren't used every day or even every month.

I stopped typing almost all passwords years ago, just 3 remain. I bet you can guess which logins those are. I'll provide a hint - no banks and no email accounts.

I can't type in the password for most logins, I do not know them. Once I started using a password manager, I became addicted. I can never return to the old way.

There would be no impact on storage as the hashed passwords are all the same length. The only storage impact would be if they were keeping them in plaintext.

The correlation of sites that store passwords in plaintext and for whom storage of text is a concern is probably close to one. (And don't think they don't exist.)

Seriously, though, you're correct. There should be absolutely no justification these days for not allowing passwords as long as 256 characters, if so desired. (And while such a length might exceed practical security requirements, it allows for long, memorable non-truncated pass-phrases if someone actually wants to type or copy/paste all that in. Why limit this flexibility?)

I and others like me avoid centralized authentication services. I don't trust them and do not want 1 "holder" having that much power. I'm paranoid, but if google has access to all my credentials, what will stop a government from demanding access to all 3rd party websites that I access? It doesn't matter whether I **need** this protection or not. It is my right and I will not give it up.

Good point. However, there's absolutely no reason not to offer third party authentication to anyone who chooses to use it, and some sites and services have already done away with local password storage. Spotify, for example, does not allow users to sign up without Facebook any more. My only complaint there is that FB is the only option. I'd be a lot happier if I could choose to also authenticate through Live and Google.

However, my vision involves a truly neutral authentication engine that would allow a user to specify any authentication provider. The simplest method would possibly be using an @ name and pinging an LDAP server.

For example: me@mypersonaldomain.com would look for an LDAP server at the mypersonaldomain.com DNS address, then request authentication for "me". If "me" is already logged in to this browser session, the site logs in the user. If not, the site redirects to something like "login.mypersonaldomain.com", and lets the user authenticate.

So if you don't trust Google or Microsoft, you could host your own LDAP server. Yes, setting up an LDAP server right now is no picnic, but if this solution started to gain acceptance, and someone actually built a set of open source libraries in all the common web languages, then a lightweight, simple to install LDAP server would be part of that project.

Taken to the next level, I could see using this to log on to your home PC's as well... set up a PC once with a client for this service, and after that, the computer lets your family use your computer without you having to set up everybody's user accounts on every PC in the household.

We don't have a truly platform-neutral service like this yet... I think its an idea whose time has really come.