NYU Group Says Its Scheme Makes Cracking Individual Passwords Impossible 277
An anonymous reader writes "Researchers at New York University have devised a new scheme called PolyPassHash for storing password hash data so that passwords cannot be individually cracked by an attacker. Instead of a password hash being stored directly in the database, the information is used to encode a share in a Shamir Secret Store (technical details PDF). This means that a password cannot be validated without recovering a threshold of shares, thus an attacker must crack groups of passwords together. The solution is fast, easy to implement (with C and Python implementations available), requires no changes to clients, and makes a huge difference in practice. To put the security difference into perspective, three random 6 character passwords that are stored using standard salted secure hashes can be cracked by a laptop in an hour. With a PolyPassHash store, it would take every computer on the planet longer to crack these passwords than the universe is estimated to exist. With this new technique, HoneyWords, and hardware solutions all available, does an organization have any excuse if their password database is disclosed and user passwords are cracked?."
Hmm (Score:5, Funny)
Maybe I should look at this implementation for my upcoming MMO, which will likely go live somewhere in 2030 :)
WTF? (Score:4, Insightful)
To be useful, the system still needs to be able to tell whether a single user password is correct (and needs to do so reasonably efficiently). So if someone has a 6 character password (which is dumb) you can just try all possible passwords (there isn't that many possible 6 realistic character passwords). Either lots of them work (which would a problem) or you found the password. And it didn't take all the computers in the universe forever to do so.
Maybe this is a great system, but the hyperbole in the summary is ridiculous.
Re: (Score:3, Insightful)
Re:WTF? (Score:5, Insightful)
Instantly, since all possible combinations will occur simultaneously.
Re:WTF? (Score:5, Funny)
I'll lease it to you for the low low price of
Re:WTF? (Score:5, Informative)
Does it come with an actual monkey? I wouldn't want to end up with an MSCE or some other poor substitute, monkeys are both cuter and put less shit on your servers. Of course both could be replaced by a very small shell script. but I need one for the head count and scripts run headless so that won't do.
Re:WTF? (Score:4, Funny)
Plus the monkeys smell better.
Re:WTF? (Score:4, Insightful)
Hook the keyboards up in parallel and combine all the inputs to produce infinite outputs and you get instant monkey cracking. Thought now you're stuck with infinite monkeys with nothing to do.
Re:WTF? (Score:5, Funny)
That was a flaw with early experiments, but we've since worked it out. With our updated business model, we only provide you with one monkey and typewriter in this universe. At the same time, in each of infinite parallel universes, the parallel 'we' give the parallel 'you' a monkey and typewriter as well. Each typewriter is equipped with a lovingly crafted and painstakingly entangled transceiver to broadcast and monitor an infinity of random typing, listening and waiting for your answer to ephemerally cross its antenna.
Great news! It's statistically certain that one of the infinite monkeys has already typed the answer you seek. However, due to information propagation delays, it may take between zero and infinite time to reach your universe. Rest assured, though, it's on its way. While you wait, please enjoy your monkey. And typewriter.
Thank you for your business!
Re: (Score:2)
they already have...an infinite numbers of times.
Re:WTF? (Score:5, Insightful)
Even if all of them typed the same thing the rest of them would type the other combinations.
Re: (Score:3, Insightful)
There is nothing to suggest that an infinite amount of monkeys wont produce an infinite amount of "a"s. Adding more monkeys could produce more "a"s.
Re: (Score:3, Funny)
Somebody actually gets what "infinite" actually means.
Perhaps there is hope for the human race, after all.
Re:WTF? (Score:5, Interesting)
To be useful, the system still needs to be able to tell whether a single user password is correct (and needs to do so reasonably efficiently). So if someone has a 6 character password (which is dumb) you can just try all possible passwords (there isn't that many possible 6 realistic character passwords). Either lots of them work (which would a problem) or you found the password.
No, as I understand it from the article, you can't tell if a single user password is correct, because you don't have a measure for "correct"-- all that you check whether that password points to the same place (in a multidimensional phase space) that other passwords project to. (It does seems to only work is you can assuming that all, or at least "most," of the other passwords people enter are correct).
Re: (Score:2)
To be useful, the system still needs to be able to tell whether a single user password is correct (and needs to do so reasonably efficiently). So if someone has a 6 character password (which is dumb) you can just try all possible passwords (there isn't that many possible 6 realistic character passwords). Either lots of them work (which would a problem) or you found the password.
No, as I understand it from the article, you can't tell if a single user password is correct, because you don't have a measure for "correct"-- all that you check whether that password points to the same place (in a multidimensional phase space) that other passwords project to. (It does seems to only work is you can assuming that all, or at least "most," of the other passwords people enter are correct).
So... how do you know if a user can log in? You have to wait until a bunch of users want to log in simultaneously?
Re:WTF? (Score:5, Informative)
Re:WTF? (Score:4, Informative)
Exactly. The first of those users will experience the password validation taking longer than usual. How much longer depends on various parameters in the system. If some of the users gave up and closed the connection, you still have the information needed for unlocking, so you don't need all of those users to log in simultaneously. You just need enough different users trying to log in after a restart. Once the threshold is reached, that user will get logged in after having to wait at most a couple of seconds. Earlier users will get logged in at the same time if they are still waiting.
But I suspect you might be able to DoS that process by just submitting a stream of invalid passwords. They may be able to avoid that through the partial validation described in the paper, but the partial validation sounds like it leaks so much information, I would rather trust an old-school salted hash.
Clarification (Score:5, Interesting)
So it turns out their system, after a reboot, can't just validate a single user (I guess that was a crazy assumption on my part) - it has to have logins from a number of users before it can authenticate anyone. And if you don't want the system breakable by someone just creating a bunch of accounts (eg. normal users on a public website), these prime logins have to be more "special accounts".
Practically, if you need some special logins after every reboot in order for the system to come online, you're going to have to have multiple people assigned this job. Or one person with N passwords he logs in with. In which case, why not just give that guy a one time pad sort of thing that he primes each server with? I mean, these passwords are going to be unrecoverable and encrypted with, effectively, an unchanging key. So... uh, we have ways to do that.
Oh wait, there's an extension that gets around this, and has the property of "the server can check and eliminate most wrong passwords right after reboot". I'm sure a lot of bosses will like that - it'll reject most wrong passwords. Great.
It's a clever idea, but I think there's some real hard sell problems there.
Re: (Score:2)
Fine, I'll just go buy N wrenches.
Re:Clarification (Score:4, Insightful)
why would you need multiple people assigned to this job? seems to me if you are really concerned you could 'prime' this system by using an attached HSM with however many random accounts/passwords you'd like to be logged in at bootup: outside of somebody physically breaking into your server room and stealing your keycard it would seem quite secure to me...
Re: (Score:3)
Yeah - but that system would have nothing to do with this. If you want to do that, it's cool and it'll work.
The interesting part of THIS system is that it can recover the secret it needs just by having multiple users authenticate. Which is a really cool property for some possible purpose, but I don't see how it fits well with the requirements of a "normal" authentication system and how that needs to respond.
Rediculous (Score:4, Interesting)
So this system would work for a web-server where a bunch of people are logging in all the time. It passes test #1: It can be implemented.
However, the security that this system imparts would only help for the first few (N - 1, depending on how many blocks are required to overlap) passwords. Once you have those first few passwords this system provides zero benefit, since you can use the passwords you know as keys to crack any future ones. If users can make user accounts then all you need to do is make N - 1 user accounts and you have completely defeated this system.
So this system creates a HUGE new constraint on your user management system: No accounts can ever be issued to any parties outside of your home trusted zone. I suppose there might be one situation in which this solution might be useful: classified government work. In all other situations this solution is worthless.
Re:Clarification (Score:4, Funny)
I fucking love this!
I hope every web company uses it. That way when users realize their boycotts have the potential power of cascading effects they'll finally have to bow to our demands and implement a better password system!
Re: (Score:2)
This. If you need "special" accounts just have it supply an AES key to decrypt the password database with, if you can crack that without having the key we're all in deep shit. Pseudo:
If (databaseLocked)
TryDecrypt(database,password)
If (ok)
Print "Alright, have fun"
Else
Print "Sorry, service down"
EndIf
Else
LoginUser(username, password)
EndIf
I guess you could do
Re: (Score:2)
Actually for that we can just use a single strong password which could for example have 128 bits of entropy. So you just need to have one employee capable of memorizing a strong password, probably it would be a good idea to have a few such employees for redundancy.
Re:WTF? (Score:5, Insightful)
No, it doesn't work that way; that's the whole point. If you have the hash and are trying to compare against it, you can't just try all the possible passwords because if haven't cracked the other passwords you don't know how to produce the hash that corresponds to a given password. If you're just trying passwords at a login prompt, brute force is trivial to defeat (best method will most likely be simply imposing an increasing login delay with each wrong attempt).
Re: (Score:3)
Yeah - I was wrong. I had assumed that the system would need to be able to log in a single user based on their password (crazy me!) and that was incorrect.
Re: (Score:3)
More like you have the hashes for all the passwords (you downloaded it when you cracked their server).
And you have ONE password that you created on their system. So you have a password and a hash for that password. From which you can probably deduce the "salt" used.
But you cannot get the passwords from the other hashes because they each use a different "salt".
The problem is that the "salt" for each password is calculated by that machine based upon "special" accounts providing correct passwords that provide
Special accounts not required (Score:3)
There's no requirement for "special" accounts, though that could be used.
The other option is to just allow your regular users logging in after a reboot to hit the threshold. This would be good for a busy site, where 1,000 users try to log in sooner than an admin can be alerted. That brings up the question of how you authenticate those first N users. The solution is the paper allows a weak authentication before the threshold is hit, so the server could allow "slightly wrong" passwords for the first 30-60 s
Re: (Score:3)
Yeah, I think that's a problem. There shouldn't be any way to tell a "slightly wrong" password from any other wrong password.
Which is a different problem with that approach.
They could have also had the server admin type in the formula for the line that the
Re: (Score:2)
The point here is that you cannot test a single password. You must test, say three, at a time. (So you'd have to try all combinations of 18 characters in this case.)
The downside of the method is that after a server reboot you will have to wait for three trusted people to log in before you can authenticate any of them (unless you also have a weaker system to use for the first few logins.)
Re: (Score:2)
> The downside of the method is that after a server reboot you will have to wait for three trusted people to log in before you can authenticate any of them
Or automate 3+X system-known accounts that the system randomly logs into, as part of the bootup process?
Re: (Score:3)
Re: (Score:2)
and needs to do so reasonably efficiently
If you're using bcrypt or some other stretcher, the last thing you're thinking about is efficiency. The whole point of a stretcher is to be inefficient.
This idea is really BS (Score:2, Troll)
This scheme fails in practice (another over-hyped idea that fails to deliver as has gotten so common these days): It requires a number n of users to log-in before any password can be checked! That is right, the first n-1 have to wait until n are there, because before n good (!) passwords are available to the server, it cannot verify even one. Unfortunately, n is also the security gain. That means if you require 10 different login-attempts before you can login anybody, you just get a factor of 10 in addition
Re: (Score:2, Informative)
This scheme fails in practice (another over-hyped idea that fails to deliver as has gotten so common these days): It requires a number n of users to log-in before any password can be checked! That is right, the first n-1 have to wait until n are there, because before n good (!) passwords are available to the server, it cannot verify even one.
You must have skipped reading TFA. The "different" logins can be administrative passwords, so that whenever a login is attempted, the user passwords is only one of multiple passwords, where the other passwords can be administrative passwords. The point is to make the password file, when stolen, be safer. If you do not have aceess to the administrative passwords, the cracking of the passwords from the stolen file gets too computationally intensive.
Re: (Score:3)
Re:This idea is really BS (Score:5, Funny)
Get them to write their passwords on a post-it(tm) note and stick it to the server.
Do I have to do all the thinking around here?
Re: (Score:3)
That completely breaks security, as these passwords have to come from some place and are vulnerable there. Or it means that a large number of people (remember that it requires n users for a security-factor of n?) have to log-in (or rather attempt to) manually.
Sorry, but you do not understand the security and attacker models at work here at all. Sure, this thing looks like a good idea, but only as long as you ignore reality. And BTW, whenever has a server password-list stolen from a not-running server or at
Re: (Score:2)
Plus, for most websites, you can just register 10 accounts, giving you the 10 known passwords.
In any case, the treat model is that you can access all the data in the db, but not all the data in memory (as
is the case with SQL injection and most other attacks). The
memory is used to cache the first n-1 passwords. The n-th guy needs to wait only after the system crashes
and the cache data is lost.
But in such a treat model, the problem can be solved in a way simpler fashion: just store in memory a key
with which a
Re: (Score:2)
Indeed!
As for root on the machine: Password hashes (properly stretched and salted) protect only the users that do not log-in while the machine is rooted, but these they do protect well. As password-stealing for large password files usually gets noticed pretty soon and often before the password file is completely stolen, this does offer some level of protection.
Re: (Score:2)
Re: (Score:2)
The latter is not feasible, because you don't need to guess passwords, you need to guess user-password pairs.
Re: (Score:2)
It would be interesting to know what the dynamics are of password database size vs login frequency. A lot of systems get huge numbers of login requests in very short timeframes, so it may not be a problem for them. But the flip side is that user bases that huge often have large
He pretty much agrees with you on page 12. (Score:2)
>> Sane people will stay with salting and stretching, ideally with scrypt() to neutralize GPUs.
"Key stretching is orthogonal to PolyPassHash and could be trivially used in conjunction."
Hell, just the bit about bcrypt, etc. using a unique hash per password would have stopped most of these "grab the file then crack the table" hacks; the current focus of developers should probably just be to replace anything still using unsalted (or common salt) MD5/SHA1/SHA256 schemes.
Re: (Score:2)
Salts do not help that much today, as brute-forcing is faster than generating rainbow-tables. The stretching (i.e. hash iteration) is what brings the real gain. Sadly, even people that develop security software in the financial sector often do not seem to know that.
Re: (Score:2)
What really needs to happen is separation of duties and storing the hashes the same way companies store private keys used for signing... a physically secure, hardened appliance with a limited interface out. Backups are done to a USB port physically on the appliance, and the data never is exposed on the network, only calls to use it.
We can use bcrypt, initial hashes, and such, but it might be better to consider a different protection method -- keep the data separate and physically isolated from everything e
Re: (Score:2)
Salting provides lots of security against brute force attacks. Let's assume you have a system with one million users and you have a list of the 10 million most common passwords. If the system uses unsalted hashes, you only have to hash those 10 million passwords once to know which users have been using a password from that list. If OTOH the hashes are salted, you have one million salts and 10 million passwords. That
Re: (Score:2)
Salting actually provides no security at all against brute-forcing. Salting helps against rainbow-tables, but that is a different attack.
Re: (Score:2)
Yes, and there is no way to protect against that directly. But there are other ways, for example requiring users to solve a captcha in addition or rate-limiting individual IP addresses.
Re: (Score:3)
While I'm not necessarily all that impressed by this, your specific criticism doesn't seem to be valid. It appears that n accounts are pre-created with null information and assigned out as needed. When those are about to get used up another n are created. There would appear to be a possible attack on a new account by creating lots of dummy accounts to have a big chunk of the password space under your control, but that seems like a pretty uncommon circumstance.
What I like about it is that it seems to protect
Re: (Score:2)
It is a "threshold-scheme" any n passwords out of the whole set of passwords will do.
Re: (Score:2)
Hehehe, nice! And obvious. So for anything where anybody can make an account, this is completely broken!
Re: (Score:2)
Talk about silly requirements: if an attacker can read your secret from memory being root, you have already been hacked.
On the surface you are right, but that is not the attack model. The main attack model for this scenario is to break the passwords and try them on other systems (Facebook pwd also working on google? Oops...). With properly stretched and salted passwords, the passwords stay secret even on a rooted system until the users log in.
Any Excuse? Yes. (Score:5, Insightful)
Security isn't about safety. The vast majority of passwords are for identification, rather than security. And the ones that are for security, are for a "reasonable" amount of security. The biggest point is to make breaking it an obviously-intentional exercise -- because that can be made illegal. It's not about stopping criminals. It's about defining criminals.
So go ahead and make your twitter account password super-secure so that no one can ever hack in. And then go home to your cylinder lock, easily pickable, next to the big glass window. Then tell us how safe you are -- remembering that whether or not you keep your twitter password on a sticky note, and whether or not your desktop e-mail is accessible within your home without a password, your children and your wife, and your dog are sleeping behind not such password.
And any locksmith can break into any car, as a ten-second paid-for emergency service. And so can anyone who's watched them do it.
Stop trying to feel safe. Just feel safe. It's a lot easier, cheaper, and much more valid.
Did you leave your oven on?
No? Maybe? (Score:5, Funny)
Did you leave your oven on?
You bastard. Did you have to do that?
Re: (Score:2)
No. No I didn't.
Did you lock your car?
Re: (Score:2)
Your argument is dumb.
Security is about accessibility, integrity, and confidentiality. Passwords are used to authenticate, while access control schemes are used to authorize. Authentication and authorization come together to tell you if a person is allowed to read or modify data and permissions on data. Other security systems (High-availability, etc.) help ensure accessibility--integrity as well, since destroying data makes it non-accessible.
Security is a risk management scheme. If the severity of
Re: (Score:2)
Oh, I very much am not.
That's a nice technical solution you have there (Score:3)
The problem is a human one, however.
Yes, this makes it harder should someone get to your stored hashes. But it doesn't make it any more secure if people continue to use "123ABC" as a password. Which they will do since that's an easy thing to remember.
Re: (Score:2)
Yes, it does make it more secure. The security of the hash files relies on a secret stored in memory. To
get that secret, you either need to know the password of K users (user i has password p_i) or you need
access to memory. The point is that access to disk is not sufficient (regardless of how weak the passwords
of the users are).
Re: (Score:2)
Yes, you could. This doesn't have any better security guarantees than just doing that.
His whole argument however is that the salt needs to be reentered in the memory manually
after a system crash, whereas with his mechanism the memory gets the needed data automatically
after a few users login.
Comment removed (Score:4, Informative)
Re: (Score:2)
Make passwords 20 characters. Lower case letters and the underscore or space. Expire once per 100 years. More than 60 attempts in 60 seconds gets a 60 second ban. Tell the user to slap 4 random dictionary words together. Use a random salt value per-password and a strong hash.
QED.
Running memory (Score:4, Informative)
The article says: "if an attacker can read memory on a running server, they can steal passwords unencrypted regardless of the technique that is used".
The article concludes that al we're trying to do is to resist passwords stored on-disk. Congrats. So here's my fix-all solution. When the server is booted, it loads all of the passwords into memory, and then physically disconnects the disk. And we're done. You know, except for the whole entire memory space.
This is just another one of those "make this link in the chain even stronger because once someone broke through it" forgetting that there are dozens of other weaker links that simply have yet to be targetted.
Re: (Score:2)
This is just another one of those "make this link in the chain even stronger because once someone broke through it" forgetting that there are dozens of other weaker links that simply have yet to be targeted.
If you can think of a way to strengthen all of the links simultaneously, by all means post it and/or start a company and get rich selling your perfect-security technique.
If, on the other hand, you can't, then strengthening the links one at a time may be the best we can do. Unless you think it's better to leave them unnecessarily weak?
Re: (Score:2)
Think harder boy. I believe in removing links, having fewer links to strengthen. It's called reducing the surface area of attack -- at least it was in the 80's, when I did start my own successful company.
You may be forgetting, if you've ever actually known, that chains are used because they are inexpensive to produce. They aren't better than cables, and they aren't better than lines, and they aren't better than rope -- when better equals stronger. But they are more flexible than cable, way faster to pr
Re: (Score:2)
A physical disconnect is easy to set up. It's at reboot. It's actually a physical-but-momentary connect. That's not high-robotics.
But even a soft disconnect, even something as simple as a dismount. Or a wireless momentary connection. How many hackers are going to have access to mount/connect an invisible disk?
Or, if you like, just overheat the drive after a few minutes of use, and it'll dismount all by itself.
Re: (Score:2)
No, secure the access, not the information. Encryption is relevant in a scenario where the data needs to be there, and be inaccessible. It doesn't work when the data needs to be accessible at all times. If the data is completely inaccessible, it need never be secured.
So, in this case, since all of the fancy encryption being discussed is entirely absent once the data is in memory, and since that's reported as being acceptable, then we can just put it all there, be the very same acceptable, and then we don
Re: (Score:2)
true.
cached, in-memory for the day?
Impossible, or just NP hard? (Score:2)
Given enough opportunities to try different combinations, any password can be guessed in a finite amount of time, eventually.
Or maybe they just mean impossible for all practical purposes...?
Re: (Score:2)
Obligatory (Score:2)
PolyPassHash want a cracker?
I'm skeptical. (Score:2)
Impossible? Hmmm, I don't know about that. Chin Ho Kelly on Hawaii Five-0 can crack any password within a couple of minutes. I seen it.
longer to crack than the age of the universe? (Score:5, Funny)
...it would take every computer on the planet longer to crack these passwords than the universe is estimated to exist.
Let's hope they're not creationists.
Re: (Score:2)
I think both creationists and sane people mostly agree the universe exists. Maybe they mean "estimated to have existed".
Re: (Score:3)
10K years is more than enough for anybody.
SRP (Secure Remote Protocol) (Score:5, Interesting)
Re: (Score:2, Informative)
Sadly thats not true. When the attacker has the password database SRP degrades to being just a regular salted password.
Re: (Score:2)
really? (Score:3, Interesting)
To put the security difference into perspective, three random 6 character passwords that are stored using standard salted secure hashes can be cracked by a laptop in an hour.
Really? Okay, here are three NONrandom 6 character passwords that are stored using standard salted secure hashes:
a44a6d60ebc202a7d296d82a7eac5748b7a93474c996e533795d769b297e613c
5529ce75d4bf3bc7b488c8591906cc39bf5ac90feeeb9fbc278b0f98e03cafc6
9de700d2bc4fa3ed30a3459a9cffd7785c10f465c5b9cfb4a83d417e9347f0f9
Start your laptops, gentlemen. I'll even give you a hint. The first password is 123456. The second is abcdef.
Is this different than a "secret salt"? (Score:3)
Is this really different than a "secret salt" that someone has to load into the server upon reboot?
Instead of requiring N correct passwords to let the server build up its Shamir Secret Store data structure that lets it validate passwords, why not just have an admin type in the secret salt that is hashed with each password?
Without that secret salt, the password file is useless. The secret salt can be protected by N passwords (or maybe it's a hash of those N passwords) just like the Shamir Secret Store data, the only difference is that instead of the server computing it the secret data, the administrator(s) types it in directly. If someone can compromise the server to get the secret salt (or can social engineer the administrator password(s), they can also get to the Shamir Secret Store data, so it doesn't seem any less secure.
Re: (Score:2)
Secret salt? Isn't that what we normally call a key?
Re: (Score:2)
Secret salt? Isn't that what we normally call a key?
I don't know -- who is "we"?
I called it a "secret salt" since it's not really an encryption key, it's just another input to the password hash function just as a normal salt is. But it's meant to be secret unlike a regular salt which is generally stored with the password hash.
Re: (Score:2)
Right, but Hash(data=(secret_salt || plaintext)) looks very much like message_authentication_code(key=secret_salt, data=plaintext).
Not all keys are for encryption.
Having to social engineer more administrators (Score:3)
Is this really different than a "secret salt" [or key] that someone has to load into the server upon reboot?
It's a way to require a quorum of administrators to load the key.
why not just have an admin type in the secret salt that is hashed with each password?
Because then you have to social engineer one administrator. With PolyPassHash, you have to social engineer n administrators.
Re: (Score:2)
Is this really different than a "secret salt" [or key] that someone has to load into the server upon reboot?
It's a way to require a quorum of administrators to load the key.
why not just have an admin type in the secret salt that is hashed with each password?
Because then you have to social engineer one administrator. With PolyPassHash, you have to social engineer n administrators.
Doesn't this part of my post solve than problem?
The secret salt can be protected by N passwords (or maybe it's a hash of those N passwords)
1 < n < m (Score:2)
Re:1 n m (Score:2)
PolyPassHash is a way of protecting what you call "the secret salt" with any n of m passwords, where 1 < n < m.
Ok, so that makes sense -- it really has nothing to do with protecting password hashes, it's just an "n of m split secret" algorithm.
Crypto pointless now it seems. (Score:4, Interesting)
Crypto is being supplanted by a lack of rights.
Ob. XKCD:
http://xkcd.com/538/ [xkcd.com]
Now a days you don't have to worry so much about some criminal beating you with a wrench, however you do have to worry about the NSA going to everywhere you actually store information online and forcing them to give the information over "voluntarily" by creating laws under some pretense and threatening legal repercussions, or by just doing it illegally anyway using the usual scare tactics. The same can happen to you personally, and they can pretty much throw you in jail for an infinite amount of time until you produce the password in question anyway.
Anyway criminals are NOT brute forcing huge lists of passwords in the first place. They either take advantage of terrible security in the first place (Hey lets store all the passwords in an unencrypted text file which anyone can access if they know where to look!), software vulnerabilities (Hey your password is super safe, too bad there is that gaping security flaw that lets people bypass passwords altogether!), or social engineering (Hey sure I will give out your password, I'm an IT guy that gets paid 10$ an hour and I really don't give a shit anyway).
So while in an interesting sort of puzzle way this is neat, the actual protections it will afford you is probably very little.
Re: (Score:2)
Also I forgot about what I call the FB rule.
Your password is super safe and invulnerable. However you signed a EULA (that is 862 pages long, stored in some obscure location, that can be changed at will) by glancing at it for about 5 seconds to find the next button, that basically gives the rights to all the information you were protecting in the first place, and your first born son, to the company that stores the information, who can and will sell it all to the highest bidder anyway.
Multiple $5 wrenches (Score:2)
good engineering RIP (Score:2)
Once upon a time, real engineers solved the solvable problems in whatever order solid solutions presented themselves, so that presently unsolvable problems evolved into greater relief.
I thought it was a good system. Good engineering, RIP.
You lost me (Score:2)
Can someone explain it in terms of a car? Or perhaps two cars, with Alice in one and Bob in the other.
Bob's car won't start until Alice blows his Breath (Score:2)
Bob's car won't start until Alice blows his Breathalyzer, because Bob's a drunk.
Seriously it's more like Bob's key won't start Bob's car, and Alice's key won't start Alice's car, unless both Bob and Alice turn their keys at the same time. The keys have transponders in them that talk to each other.
Therefore, you can't make an unauthorized spare key by examining Bob's lock - your unauthorized key has to match both Bob's lock and Alice's key.
Open PDF, Ctrl-F "Impossible"... (Score:2)
~Sticky
yes (Score:2)
Yes: 1. hiring incompetent morons
2. insufficient budget for IT work
3. idiot contractors/vendors
call/cc (Score:2)
Of course. They wrote it in Scheme and used call/cc wherever possible. Now nobody can get in because nobody can understand it, not even the guy who wrote it.
Need a quorum of admins (Score:2)
Re: (Score:2)
The minute they said that a single-round digest of a salted password is standard practice, I stopped reading. Apparently they've never heard of PBKDF2 or scrypt. I now have zero confidence that these researchers know anything at all about password security.
Real security is achieved with large exponents. Anything short of that (multiplication, assorted amplification techniques) exist to make people feel better. But but but my password is a thousand times more secure now!!