I've been doing .NET development since 2006 and have never had to buy commercial components. Every time I have needed something there has been free/open source stuff. I'm guessing it depends on what type of software you are working on?
Your suggestion is bad for a ton of reasons. For example, how do you change your password for a specific site after it had been compromised or due to normal password rotation?
Another downside is that changing master password means you need to change passwords for all sites or have multiple master passwords.
Another is that an attacker can use the knowledge of your password on site A to bruteforce your master password offline.
Why on earth is this being downvoted? If you've used a hashing generator for any length of time you'll know how multiple master passwords inevitably creep in. Also, when your generator no longer works because the login FQDN changes (which happens alarmingly often) you'll have all the fun of resetting your password. For no good reason.
Re. portability, KeePass and its siblings are compatible with every major platform.
...an attacker can use the knowledge of your password on site A to bruteforce your master password offline.
This might be a concern if you're the victim of a state-level targeted attack. That's not a threat most of us have to deal with. Hackers aren't likely to spend a lot of effort cracking John Doe's password list; they want to steal a few million password hashes and sift out a few thousand easy or re-used ones.
Your other points about the weaknesses of the scheme stand. Still, if we could get more users to use not-terrible, not-duplicated passwords, even with a flawed scheme like this, overall internet security would improve immeasurably.
You don't need to be the victim of a state-level targeted attack. You just need to be a public figure online[0] and attract the attention of a bored hacker.
I'm not super familiar with the Honan story but I recall (and quick skimming seems to confirm) that it was more about lax security policies at Apple et al, the interconnectedness of social media accounts, and social engineering than it was about reversing a computed hash or human "hashing" scheme.
Did those attackers guess or compute even one password at all?
Not in this specific instance, but they could have. And that level of scrutiny would have enabled a complete digital takeover like Honan suffered if his accounts were poorly protected by a system of passwords proposed above.
There are many types of targeted attacks on passwords that don't come close to including state-level actors. Divorces. Corporate Espionage. Any one of the people on Judge Judy who posted information online about their co-workers.
As far as I can tell, we're talking here about reversing a cryptographic hash and sifting the one true master password out from the much more numerous hash collisions. Do you really expect that level of effort to be common in a divorce?
I _know_ that level of effort has already been expended in divorces. Targeted attacks do not need to be common. The point is that there are many types of targeted attacks.
That's assuming that the master password is really strong. Otherwise you could bruteforce it by testing millions of passwords ("password", "secret", short ones and so on). I assume most people will choose somewhat weak master passwords.
With this scheme ANY site where you register can attempt to brute-force your master password offline. I fail to see how it's a good scheme.
You're right. If you choose a weak password, nothing can save you. This holds in any case, so this is not specifically an argument to this use. Let's do some math to see if your argument about bruteforcing holds stake (spoiler: it doesn't).
Let's say you're master password only uses letters, numbers, and special characters. Just counting keys on my keyboard, there are 94 such characters. You should pick a random sequence as master password (very important).
Let's say you use the Antminer S9 (which can compute 1 gigahash per joule). For ease of analysis, let's say you can recognize the master password instantly. Also, say we're paying $0.2 per kwh. Then we can define the average cost c of finding the master password as a function of the master password length l:
c(l) = 94^l/(1.8*10^10)
c(5) is about 40 cents, c(6) about 40 dollars
c(8) is more than 300k, c(12) = 26e12
In comparison, the estimated amount of money in the world (in 2009) is 52e9 dollars. By the way, this is if you use a single SHA256 hash. You can make the hash arbitrarily expensive by iterating (computing h(h(h(master_pass)))).
The one and only argument against using a master password that is used to derive passwords is the single point of failure. If someone catches you typing your master password on video, you're pretty much fucked. But I guess this is the same for password managers.
You can add something (e.g. a number) to the end to make a different password. The idea is that you have a _very_ secure master password (so bruteforcing it is not practical - to make this even more true you could hash a huge number of times instead of just once) and never change it.
There is still some truth in your arguments. I'm curious what you consider a good alternative?
It’s better because going through the same process as the official banking apps means that you should end up using tokens etc rather than actually storing the original credentials.
Until you need to reseed the original master, want to do quick rolling restarts or want any automation in automatic failover. PG has a long way to go.
A
