×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

NYU Group Says Its Scheme Makes Cracking Individual Passwords Impossible

timothy posted about 8 months ago | from the impossible-is-difficult dept.

Encryption 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?."

Sorry! There are no comments related to the filter you selected.

Hmm (5, Funny)

war4peace (1628283) | about 8 months ago | (#46649711)

Maybe I should look at this implementation for my upcoming MMO, which will likely go live somewhere in 2030 :)

WTF? (3, Insightful)

JMZero (449047) | about 8 months ago | (#46649751)

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:WTF? (3, Insightful)

pastafazou (648001) | about 8 months ago | (#46649777)

Posit: An infinite number of monkeys on an infinite number of keyboards will eventually crack all your passwords.

Re:WTF? (5, Insightful)

CastIronStove (2602755) | about 8 months ago | (#46649797)

Instantly, since all possible combinations will occur simultaneously.

Re:WTF? (4, Funny)

g0bshiTe (596213) | about 8 months ago | (#46649937)

I call it, "Monkey Improbability Hacking".

I'll lease it to you for the low low price of .0000024 btc

Re:WTF? (0)

Anonymous Coward | about 8 months ago | (#46649947)

Monkey-bias might prevent an instant crack. Monkey input might be biased - as a function of their neural network connections - towards, say bananas.

Re:WTF? (0)

Anonymous Coward | about 8 months ago | (#46650923)

Nope, it takes a linear time relative to password length if the keyboards don't have an infinite number of keys. If the password length is 12 characters, no monkey has cracked the password before at least one has typed all 12. Even if every monkey has typed 11 keys, none has typed the full password yet.

Re:WTF? (0)

Anonymous Coward | about 8 months ago | (#46650165)

Wouldn't an infinite number of monkeys on an infinite keyboards INSTANTLY crack all of your passwords? Or at least as long as it takes them to type the keyboard? Since among the infinite number of them, one of them has to have the correct password.

Re:WTF? (0, Insightful)

Anonymous Coward | about 8 months ago | (#46650269)

What is to stop an infinite number of monkeys from all typing the same thing?

Re:WTF? (5, Insightful)

Anonymous Coward | about 8 months ago | (#46650431)

Even if all of them typed the same thing the rest of them would type the other combinations.

Re:WTF? (1)

Anonymous Coward | about 8 months ago | (#46650561)

you're my hero.

Re:WTF? (0)

Anonymous Coward | about 8 months ago | (#46650663)

but none of them could type it instantly.

Re:WTF? (1)

Connie_Lingus (317691) | about 8 months ago | (#46650441)

they already have...an infinite numbers of times.

Re:WTF? (4, Interesting)

Geoffrey.landis (926948) | about 8 months ago | (#46649829)

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:WTF? (1)

Rhaban (987410) | about 8 months ago | (#46650051)

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? (4, Informative)

parallel_prankster (1455313) | about 8 months ago | (#46650107)

Yes, did you RTFA? They specifically mention that this step is needed everytime the system boots. They have also provided some ideas on how to achieve this automatically.

Re:WTF? (0)

Anonymous Coward | about 8 months ago | (#46649857)

This article is a bit strange. The security seems to be from the hash side, not the password side. Can still brute force / exploit with password guessing, but can't guess the password from the has.

I'm just trying to garner from the summary if a "threshold of shares" is required to be met to authenticate on the system.

Clarification (5, Interesting)

JMZero (449047) | about 8 months ago | (#46649893)

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:Clarification (1)

bob_super (3391281) | about 8 months ago | (#46650003)

Fine, I'll just go buy N wrenches.

Re:Clarification (3, Insightful)

MarcoAtWork (28889) | about 8 months ago | (#46650081)

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:Clarification (2)

JMZero (449047) | about 8 months ago | (#46650175)

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.

Re:Clarification (3, Funny)

VortexCortex (1117377) | about 8 months ago | (#46650553)

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:Clarification (1)

MobSwatter (2884921) | about 8 months ago | (#46650605)

True, but somehow I do not believe the NSA would be compelled to support this.

Re:Clarification (0)

Anonymous Coward | about 8 months ago | (#46650943)

Most sufficiently complex user systems require some type of manual intervention to bring them up to a useable state. Automatic configuration a la "service mysqld start && service httpd start && service fail2ban start" just doesn't scale to large, production environments. "Process initial logins," then, will simply become a part of the normal application startup checklist.

SAs are quite used to developers handing us unfinished applications with confounding startup/shutdown procedures. Trust me: this is nothing special.

Re:WTF? (4, Insightful)

Chris Mattern (191822) | about 8 months ago | (#46649993)

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).

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:WTF? (2)

JMZero (449047) | about 8 months ago | (#46650181)

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:WTF? (2)

khasim (1285) | about 8 months ago | (#46650199)

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 the information needed to generate the line that is used instead of a traditional "salt".

Which means that those "special" accounts are now ONE SET of keys to cracking that entire system. And they have to be secured.

And I'm still not convinced that, given enough passwords, their system does not fail anyway. And password re-use is a major problem with users and their passwords.

Special accounts not required (2)

raymorris (2726007) | about 8 months ago | (#46650465)

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 seconds after it starts up.

Re:Special accounts not required (2)

khasim (1285) | about 8 months ago | (#46650773)

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 seconds after it starts up.

Yeah, I think that's a problem. There shouldn't be any way to tell a "slightly wrong" password from any other wrong password.

That brings up the question of how you authenticate those first N users.

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 system will use.

About the only issue this "solves" is having ONE secret that has to be shared between the admins. So you won't have the "disgruntled" problem. Each admin gets his/her own portion of the secret.

Just like requiring two keys to launch a missile.

Re:WTF? (1)

Sqr(twg) (2126054) | about 8 months ago | (#46650153)

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:WTF? (1)

Jack9 (11421) | about 8 months ago | (#46651033)

> 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:WTF? (2)

donaldm (919619) | about 8 months ago | (#46650235)

Actually if a cracker wanted to get a user's password all they need to do is contact the target in a so called official manner stating that they think that their account has been compromised and they need their password to check. Surprisingly many people would actually fall for this so a cracker would prefer to use social engineering to get a password rather than try the brute force method which would normally raise alarm bells with System Administrators. Of course this assumes that the System Administrators of a targeted machine have some level of competence and integrity.

Actually brute force cracking is the stuff of Hollywood movies since most operating systems have a policy that is set to 3 or 4 strikes and the account is locked. Although I have seen sites were this was not enforced. Of course there are ways of restricting access even further such as one time passwords but the problem of security is still the weakest link in the chain and that is the user.

Maybe this is a great system, but the hyperbole in the summary is ridiculous.

Could not agree more.

Re:WTF? (1)

Bengie (1121981) | about 8 months ago | (#46650539)

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.

bullshit (0)

Anonymous Coward | about 8 months ago | (#46649789)

bullshit; if you can verify the password then you just copy the entire system for verification and try each variation through it . if you can't then the entire system is useless .

Need a quorum of admins (1)

tepples (727027) | about 8 months ago | (#46650529)

If you copy the whole system, you still need a quorum of administrators (users whose passwords contribute to the threshold) to connect to your copied system and attempt authentication.

How many times ... (0)

Anonymous Coward | about 8 months ago | (#46649799)

... must we reference this to prove that your passwords are still weak? http://xkcd.com/538/

This idea is really BS (1, Troll)

gweihir (88907) | about 8 months ago | (#46649803)

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 additional security. And then there is the little problem that an attacker that gets root-access to the running system does not suffer this slowdown, as they can just read the secret the system computes from the first n passwords from its main memory.

Whoever dreamed up this hare-brained idiocy has no experience with real systems or system security. Sane people will stay with salting and stretching, ideally with scrypt() to neutralize GPUs.

Re:This idea is really BS (2, Informative)

Anonymous Coward | about 8 months ago | (#46649931)

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:This idea is really BS (2)

tepples (727027) | about 8 months ago | (#46650543)

Good luck contacting the administrators every time you have to reboot any of the servers, especially if it's night in their time zone.

Re:This idea is really BS (4, Funny)

Hognoxious (631665) | about 8 months ago | (#46650679)

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?

Another practical problem. (1)

Anonymous Coward | about 8 months ago | (#46649973)

All the attacker needs to do is create 10 (or whatever the threshold is) user accounts before compromising the server, and then you can recover the secret. So, this won't work for any of the cloud services mentioned in the abstract.

However, the attacker doesn't have the ability to create accounts, and the threshold is set high enough, then even having a bunch of users (say 10) with passwords like "password", "qwerty", etc, won't necessarily let you in, since you have to correctly guess *which* account uses which weak password. So, if there are 100 weak passwords in your database, all the passwords are drawn from the weak password database, and the threshold is 10, it sounds like this system is similar to setting a 10 character master password on the database, where the strings come from an alphabet of ~ 100 characters. (Of course, the strings aren't drawn randomly from the database, since some weak passwords are more popular than others, but it's still better than nothing.)

Re:This idea is really BS (1)

mstefanro (1965558) | about 8 months ago | (#46649985)

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 all the hashes are encrypted. Write the key down on a piece of paper. If the machine crashes,
just reload the key from the paper into the server's ram.

And this is the only threat model you can work on anyway: if you assume the attacker gets root,
then there's obviously not much security to preserve. This is why authentication should be interactive (
EKE protocols).

Re:This idea is really BS (1)

Copid (137416) | about 8 months ago | (#46650049)

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.

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 numbers of weak passwords floating around, so the hit rate for a password cracker would be much higher. I certainly wouldn't use it for any of the piddly little systems I put together, but larger sites may have better luck (or just have a bunch of different admins log in when they reboot a server).

That means if you require 10 different login-attempts before you can login anybody, you just get a factor of 10 in additional security.

What do you mean by a factor of 10, exactly? If your threshold is 10, you don't get any feedback on whether you got a password right until you get 10 passwords right, so it's a factor of 10 in effective password "length" but substantially more than that in work time. That's potentially a pretty big win.

And then there is the little problem that an attacker that gets root-access to the running system does not suffer this slowdown, as they can just read the secret the system computes from the first n passwords from its main memory.

They note in the paper that the "root access to the server and read from memory" problem is not one that this system is designed to solve. In fact, it's really not one that any system can solve. If anybody ever solves the "letting somebody have the information without actually letting them have any information" problem, we'll know about very quickly as DRM schemes that actually work will start to appear.

He pretty much agrees with you on page 12. (1)

xxxJonBoyxxx (565205) | about 8 months ago | (#46650057)

>> 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:This idea is really BS (2)

RKThoadan (89437) | about 8 months ago | (#46650135)

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 stupid users from themselves. All the salt in the world doesn't do much for people who just use "password" for their password. It will still fall in the blink of an eye. We often seem to have the opinion that they deserve it for choosing a poor password, but it's still a compromised account.

The threat model is very limited to "attacker got the password hashes", but that is a common threat currently. If you're going to pick one, that's not a bad choice. It's biggest issue may be if tomorrows threat model is significantly different.

Re:This idea is really BS (0)

Anonymous Coward | about 8 months ago | (#46650155)

Talk about silly requirements: if an attacker can read your secret from memory being root, you have already been hacked. You could as well replace the binary on the system with a version which dumps the raw data to a /tmp file. Or if the program is likely using dynamic libraries, replace the system library with one which logs all secrets.

Unless you want to sell us now your tested "secure-in-practice-method" to prevent a root user from being able to do what root does, please spare us the negative silliness.

Any Excuse? Yes. (5, Insightful)

holophrastic (221104) | about 8 months ago | (#46649805)

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?

Re:Any Excuse? Yes. (0)

Anonymous Coward | about 8 months ago | (#46650163)

All the more reason to practice your second amendment rights (if you're in the USA).

Re:Any Excuse? Yes. (1)

holophrastic (221104) | about 8 months ago | (#46650367)

Oh, I very much am not.

No? Maybe? (4, Funny)

OglinTatas (710589) | about 8 months ago | (#46650635)

Did you leave your oven on?

You bastard. Did you have to do that?

Re:No? Maybe? (1)

holophrastic (221104) | about 8 months ago | (#46650757)

No. No I didn't.

Did you lock your car?

That's a nice technical solution you have there (2)

H3lldr0p (40304) | about 8 months ago | (#46649809)

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:That's a nice technical solution you have there (1)

mstefanro (1965558) | about 8 months ago | (#46650229)

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:That's a nice technical solution you have there (0)

Anonymous Coward | about 8 months ago | (#46650975)

Couldn't you do that with an ordinary algorithm by keeping the salt in memory instead of disk?

Re:That's a nice technical solution you have there (3, Informative)

squiggleslash (241428) | about 8 months ago | (#46650499)

Just to make it clear, because a lot of posters here appear to be confused as to what this is for:

This isn't about securing individual passwords. This is about securing collections of passwords and doing something about situations where some website's master table of usernames and hashed passwords gets leaked, somehow.

Right now, when that happens, people with the password "123ABC" (or "password" or "secret" or whatever) are easily identifiable because you can look for the hashes of those texts amongst the passwords.

However, with this technology, you would need to already know a large number of existing username/password combinations before you could begin to look for users with easily guessed passwords.

How secure is it? Well, put it this way: if the system is rebooted, then it won't become available until a large enough body of users has tried to log in...

Seriously? (0)

Anarki2004 (1652007) | about 8 months ago | (#46649841)

Fucking pop-up ads and a re-direct to google play? What is this shit!? I was trying to stick it out, but you've gone too far this time. Unbelievable. I quit.

Great. (0)

Anonymous Coward | about 8 months ago | (#46649849)

It's always unbreakable, until someone cracks it.

Embarrassingly poor idea (0)

Anonymous Coward | about 8 months ago | (#46649895)

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.

You know what works even better than their method? Encrypting your entire PBKDF2(10000) password table with a secret key that isn't stored in the database (eg, hardware key or network storage that is unmounted after startup). Because that's exactly what they're describing, just worse.

Re:Embarrassingly poor idea (1)

WaffleMonster (969671) | about 8 months ago | (#46650681)

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!!

Really... (0)

g0bshiTe (596213) | about 8 months ago | (#46649917)

Like NSA would allow that!

Running memory (3, Informative)

holophrastic (221104) | about 8 months ago | (#46649935)

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:Running memory (0)

Anonymous Coward | about 8 months ago | (#46650397)

A physical disconnect may be hard to set up.

However, as I understand it PolyPassHash actually will work very well with the new Intel SGX extension ( http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html ). This makes it so that even the hypervisor / OS cannot read certain memory pages directly.

So, with PolyPassHash + SGX should have a hugely positive security impact on servers. Looks like time to preorder a CPU upgrade!

Re:Running memory (1)

holophrastic (221104) | about 8 months ago | (#46650535)

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:Running memory (0)

Anonymous Coward | about 8 months ago | (#46650475)

so let them just be plaintext, because it's a futile excersize to protect the passwords, since there will always be some way of finding them out?

Re:Running memory (1)

holophrastic (221104) | about 8 months ago | (#46650569)

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't need any of the fancy encryption to begin with.

Look at it this way. Why would you bother locking the front door of your house if you've got three armed security guards and six attack dogs guarding your home?

Re:Running memory (1)

Jeremi (14640) | about 8 months ago | (#46650523)

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:Running memory (1)

holophrastic (221104) | about 8 months ago | (#46650733)

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 produce than rope, and far easier to produce than lines. Useful for many things, but not when strength is the primary requirement. That's why the rock climbing harness is rope, and the hang-glider harness is a canvas strap, and the tower guy-lines are, well, cables.

So why would you want a chain-system for security? Seems dumb. You should want parallel components, not serial ones. Otherwise, you're trying to be more secure by lengthening your rope. That's just foolish. You want a second rope, not a longer rope.

I have no need to post anything. Why would I choose to help you with my ideas? You can develop your own ideas; not that there's any evidence of that here.

Try learning to think differently than the situation-at-hand. That's called creativity.

Impossible, or just NP hard? (1)

mark-t (151149) | about 8 months ago | (#46649963)

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:Impossible, or just NP hard? (1)

tepples (727027) | about 8 months ago | (#46650639)

They mean "it'd take longer than the age of the universe".

Obligatory (1)

ArcadeMan (2766669) | about 8 months ago | (#46650013)

PolyPassHash want a cracker?

I'm skeptical. (1)

wcrowe (94389) | about 8 months ago | (#46650017)

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? (5, Funny)

aneroid (856995) | about 8 months ago | (#46650021)

...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:longer to crack than the age of the universe? (1)

Grax (529699) | about 8 months ago | (#46650351)

Even then it would be longer than many many lifetimes. If that were truly a measure of security, I think it would be adequate.

Re:longer to crack than the age of the universe? (1)

TechyImmigrant (175943) | about 8 months ago | (#46650375)

I think both creationists and sane people mostly agree the universe exists. Maybe they mean "estimated to have existed".

Re:longer to crack than the age of the universe? (0)

Anonymous Coward | about 8 months ago | (#46650463)

That's the future tense. If they would be creationists, they would likely also believe that nobody except their god knows when the end of days is here and the passwords almost cracked. The problem would be to them a nondeterministic one. Oh, many of them also think they can make it come faster by hastening Jewish immigration to Israel. Nevermind.

SRP (Secure Remote Protocol) (4, Interesting)

kye4u (2686257) | about 8 months ago | (#46650059)

That problem is already solved. It is called SRP [stanford.edu] With SRP, even if the attacker has full access to the host, they cannot reverse engineer the passphrase.

Re:SRP (Secure Remote Protocol) (1)

Anonymous Coward | about 8 months ago | (#46650323)

That problem is already solved. It is called SRP [stanford.edu] With SRP, even if the attacker has full access to the host, they cannot reverse engineer the passphrase.

Sure, so long as you will change every client in existence to run special software...

It's "solved" but not practical.

Re:SRP (Secure Remote Protocol) (2, Informative)

Anonymous Coward | about 8 months ago | (#46650331)

Sadly thats not true. When the attacker has the password database SRP degrades to being just a regular salted password.

Re:SRP (Secure Remote Protocol) (1)

Jim Sadler (3430529) | about 8 months ago | (#46650579)

The chances are that we do not completely understand what they are doing. A major university making an announcement has a lot at stake when it releases such statements. Even monetary liability comes into play if someone suffers harm after using an "unbreakable" password and it gets broken. My greatest concern would be that our government is the author of such a scheme with a method in hand of getting through that password system. These days any encryption scheme may be tainted by government agencies. Operating systems might also be a huge playground for spooks with too much time and money and power backing them up.

really? (2, Interesting)

amaupin (721551) | about 8 months ago | (#46650093)

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.

Re:really? (1)

NathanWoodruff (966362) | about 8 months ago | (#46650697)

ihateu That wasn't hard.

Is this different than a "secret salt"? (2)

hawguy (1600213) | about 8 months ago | (#46650157)

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:Is this different than a "secret salt"? (1)

TechyImmigrant (175943) | about 8 months ago | (#46650395)

Secret salt? Isn't that what we normally call a key?

Re:Is this different than a "secret salt"? (1)

hawguy (1600213) | about 8 months ago | (#46650693)

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.

Having to social engineer more administrators (2)

tepples (727027) | about 8 months ago | (#46650677)

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:Having to social engineer more administrators (1)

hawguy (1600213) | about 8 months ago | (#46650723)

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 (1)

tepples (727027) | about 8 months ago | (#46650813)

PolyPassHash is a way of protecting what you call "the secret salt" with any n of m passwords, where 1 < n < m.

Crypto pointless now it seems. (3, Interesting)

DarthVain (724186) | about 8 months ago | (#46650177)

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:Crypto pointless now it seems. (1)

DarthVain (724186) | about 8 months ago | (#46650219)

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 (1)

tepples (727027) | about 8 months ago | (#46650703)

The point of PolyPassHash is that instead of torturing one administrator with a $5 wrench, you have to torture n administrators at the same time with multiple $5 wrenches. This pushes the torture further into organized war crimes as defined in applicable treaties.

Re:Multiple $5 wrenches (0)

Anonymous Coward | about 8 months ago | (#46651021)

That presumes a company would employ the n administrators. The likely process would be n administrators acting as n administrators. Or, an outsourced IT service having the n passwords stored in the clear for quick access.

LMAO (0)

Anonymous Coward | about 8 months ago | (#46650183)

I'll leave this here:

http://xkcd.com/538/

You lost me (1)

Hognoxious (631665) | about 8 months ago | (#46650255)

Can someone explain it in terms of a car? Or perhaps two cars, with Alice in one and Bob in the other.

Re:You lost me (1)

Grax (529699) | about 8 months ago | (#46650393)

OK. Alice is in the Tesla that plays vroom-vroom sounds on the Blaupunkt stereo. Bob is in the Chevy. They both turn their keys but neither car starts. Carl turns the key in his Civic and all three cars start. I think.

Bob's car won't start until Alice blows his Breath (1)

raymorris (2726007) | about 8 months ago | (#46650551)

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.

Uncrackable? Unthinkable! (1)

augahyde (1016980) | about 8 months ago | (#46650295)

As soon as I hear anybody say that they've developed an impenetrable password scheme, I call their bluff. No, I'm not going to be the one break their scheme, but it will surely be broken.

Re:Uncrackable? Unthinkable! (0)

Anonymous Coward | about 8 months ago | (#46650721)

I can make an impenetrable password scheme. The only problem is that you'll never be able to log into the same account twice!

Open PDF, Ctrl-F "Impossible"... (1)

StickyWidget (741415) | about 8 months ago | (#46650343)

.... No results found.

~Sticky

yes (1)

slashmydots (2189826) | about 8 months ago | (#46650417)

"does an organization have any excuse if their password database is disclosed and user passwords are cracked?."
Yes: 1. hiring incompetent morons
2. insufficient budget for IT work
3. idiot contractors/vendors

Clever, but easily subverted. (0)

Anonymous Coward | about 8 months ago | (#46650791)

It's a clever solution. Don't store the password hashes, instead store a value which could be used to find the password hash *IF* you knew the coordinates of a certain line. Don't store the line on the server, instead, at boot time the server fails the first few people who try to log in (or at least slows them down) until it gathers enough information to figure out where the line is. An attacker who steals ALL data from the server (eg: steals the virtual machine image the server runs from) still can't even validate whether a password is correct because they don't have a stream of people with correct passwords trying to log in.

I think it is completely undermined by a very simple attack: the attacker simply needs to know several correct passwords (where "several" is around the same number as the number of logins needed before the server can correctly validate passwords after it boots up). Seems like you could just open dummy accounts on a system before you steal their data file, or after the fact try a few username-passwords gleaned off some other password leak, a substantial percentage of which will be people reusing passwords.

One version (described in the paper) had the system waiting for a certain number of administrators to log in before allowing the system to function. That seems clearly inferior to simply encrypting the entire data store and not functioning until an administrator logs in and enters the decryption key (which is then kept only in memory).

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?