DARPA Wants To Kill the Password

jfruh writes Many security experts agree that our current authentication system, in which end users are forced to remember (or, more often, write down) a dizzying array of passwords is broken. DARPA, the U.S. Defense Department research arm that developed the Internet, is trying to work past the problem by eliminating passwords altogether, replacing them with biometric and other cues, using off-the-shelf technology available today.

Comments

There we go again

[ArcadeMan]

Kill and eliminate passwords? Violence is not the answer.

Re:There we go again

[Anonymous Coward]

You say that now, but wait until you watch a password facehug and implant an embroy in your friend. He might seem fine then, but you'll be convinced when a password bursts out of his chest and start running around.

Take off and nuke the entire website from orbit. It's the only way to be sure.

Re: There we go again

[Anonymous Coward]

We don't need to kill and eliminate passwords, we just need to modify them. The problem with passwords for the average user is the dizzying array of requirements from various websites (between 8 and 20 characters long, required to have upper/lower case and numbers, must have punctuation except "|~, etc.). I've never understood why passwords can't be sentences, like "I'm going to take my dog, Spot, to the park today." It's much easier to remember for the layperson and pretty quick to type once you've done it a few times. IANAC (I Am Not A Cryptologist), but I thought password strength was a function of length and potential characterset. It seems like everyday sentences would be the way to go since guessing it exactly right would be exceedingly difficult.

Re: There we go again

[Desler]

Only if you're dumb enough to let authentication program be suspceptible to such an attack. Dictionary attacks can be trivially defeated by rating limiting tries and after, say, 5 tries not allowing any more attempts for some cooldown period. No attacker is going to bother if they can only have 5 tries every 15 to 20 minutes.

Re: There we go again

[Desler]

Rating limiting = rate limiting.

Re: There we go again

[Anonymous Coward]

They can be, but it would be incredibly stupid to use something like that. A dictionary attack would crack that password in seconds.

That's not how a dictionary attack works. Like, at all. Unless the ENTIRE phrase is listed as a single entry in the "dictionary", then no, it would not be cracked. A dictionary attack does not try every combination of every word in the dictionary. Your password could be "passworda" and you would stilll be safe if "passworda" wasn't in the word list.

https://en.wikipedia.org/wiki/Dictionary_attack

Re: There we go again

[AC-x]

Dictionary attacks can be trivially defeated by rating limiting tries and after, say, 5 tries

Unless they have a copy of the password hash

Re: There we go again

[Desler]

To clarify, I should say any brute forcing attacks rather than just dictionary attack. Any authentication program that allows unlimited tries without any rate limiting is totally broken.

Re: There we go again

[Anonymous Coward]

Dictionary attack on a >50 character password that includes capitals and punctuation in seconds? I want some of what you are smoking.
Even if the attacker somehow knew that it was using sentances made entirely of valid words and not just random characters/words (how would he know this?) thats still one hell of a lot of words to attack.

Re: There we go again

[Desler]

Yeah, and I can unlock your phone without being locked out by the authentication program if I know your PIN. Were you going for a Captain Obvious award or did you think a tautological statement was somehow insightful? But if the attacker knows the password hash that is not a dictionary attack. In fact, there would be no need for any attack at all.

Re: There we go again

[Desler]

Thanks for suggesting everyone configure their system such that I can DOS them!

It's better than allowing someone to brute force account passwords. When combined with IP banning when seen that someone is just trying to attack the system your DOS attack would be short-lived.

Re:There we go again

[JMJimmy]

Why do they want to kill my password? What's wrong with "@13 unicorn #DARPA gangbang!"? It's secure isn't it?

Re: There we go again

[Desler]

Based on what do you falsely assume that?

Re: There we go again

[Desler]

To add above, just because the brute forcing theoretically might take a long time is no reason to allow someone to have unlimited tries. You never know when exactly their brute forcing will stumble upon the password. The user's password could potentially be within the first billion or so tries which means they could potentially brute force it in the first second with powerful enough hardware.

Re: There we go again

[AC-x]

You seem to have no clue what a password hash actually is. The whole point of a cryptographic hash is it's one way operation; You can turn a password into a hash easily, but you can't turn a hash into a password without brute forcing it.

Having a hash of a sufficiently string password is perfectly safe, in fact here's one now, bet you can't find the password from it. It's a basic SHA1 hash, not even salted: b6faa93a9e6ca445875c6b5511e2153bb51ef43a

However if a chosen password appears in a password dictionary than you can cut down your brute force search space by so much it goes from taking years (even centuries) to crack a password to taking a few hours (sometimes minutes).

Re: There we go again

[Desler]

And to further add, combined with timing attacks and any other potential weaknesses the key space of that 50 character password can be dramatically reduced.

Re: There we go again

[Desler]

You seem to have no clue what a password hash actually is.

Nope, you're just a poor mind reader.

Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker. If they can only have 5 tries every 15-20 minutes the attacker is going to give up unless the user's password just happens to be near the very beginning of the dictionary.

Re: There we go again

[Desler]

Forgot to close my quote tag so fixing it.

However if a chosen password appears in a password dictionary than you can cut down your brute force search space by so much it goes from taking years (even centuries) to crack a password to taking a few hours (sometimes minutes).

Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker. If they can only have 5 tries every 15-20 minutes the attacker is going to give up unless the user's password just happens to be near the very beginning of the dictionary.

Re: There we go again

[CaptainDork]

I think sentences would be OK. Because of proper case and punctuation, a dictionary hack would take some time.

Also, a brilliant idea I came up with is to use web sites that relate, in some way, to the app or web page I'm trying to get into.

For instance for Facebook, a sentence ... "I love Facebook but it takes up a lot of my time."

or

http://www.timesuck.com/

The sentence would take about 40 tresvigintillion years to crack on a PC. The web site, as password, would take about 837 quintillion years (both estimates are according to this site.)

Re: There we go again

[Desler]

Only if the passwords haven't been salted properly. Even then, a rainbow tables attack can also be thwarted by the same techniques I mentioned above. Allowing any attacker the ability to do 10s of millions if not a couple of billion (with powerful enough hardware) tries a second to brute force a password is just the height of idiocy. Using constant time password checking, rate limiting, cooldown periods and as a last resort IP bans makes you such an unattractive target that they usually just move on to some other insecure site.

Re: There we go again

[ncc74656]

I've never understood why passwords can't be sentences, like "I'm going to take my dog, Spot, to the park today."

They can be, but it would be incredibly stupid to use something like that. A dictionary attack would crack that password in seconds.

Are you sure about that?

Re: There we go again

[AC-x]

You probably shouldn't try to write about things you don't know about or understand.

1. The industry accepted way to store passwords securely in a database is with a one-way, salted cryptographic hash (using as CPU intensive algorithm as possible).

2. Many organisations have had database intrusions where these password hashes have been stolen (eg. eBay, Linkedin, LivingSocial etc.)

3. When this happens (i.e. "they have a copy of the password hash") passwords can be cracked offline. Strong passwords are safe (too hard to brute force), but weak passwords can be found using a dictionary attack.

4. Once the password is found offline a hacker can log straight in to the victim's online account with a single password attempt.

Re: There we go again

[AC-x]

Hey Desler I really don't get you, you (appear to) know what a salt is yet you don't understand that an attacker would be performing the attack on the hash offline, with their own hardware. Rate limiting their own hardware would be, as you put it, the height of idiocy.

Re: There we go again

[geekoid]

Depends on the hash used, if its a external attack, or if someone has a copy of the db and is trying to figure out what the passwords are.

If you can see everyone hashed password, patterns will emerge.

Re: There we go again

[Desler]

Hey Desler I really don't get you, you (appear to) know what a salt is yet you don't understand that an attacker would be performing the attack on the hash offline, with their own hardware. Rate limiting their own hardware would be, as you put it, the height of idiocy.

Except what you are talking about was not what I was originally responding to. You basically injected yourself into the conversation and completely changed the context and then started calling me an idiot. I suggest you re-read what I originally responded to:

They can be, but it would be incredibly stupid to use something like that. A dictionary attack would crack that password in seconds.

What I do is have a single, strong password that I have stored only in my brain and all other passwords are hashed on-the-fly from that and the domain or name of whatever I need the password for. I get unique, strong password for everything, but only have to remember a single one.

Do you notice that nowhere in that quoted statement is there anything about the attacker already having the password hash?

Re: There we go again

[Anonymous Coward]

Many people use the same password on multiple sites, and many intrusions aren't immediately discovered.

Re: There we go again

[wagnerrp]

The point he was making is that with proper procedure, a hash could never be attacked offline. As soon as the hash database were compromised, all hashes contained therein would be invalidated. The attacker could brute force that database to their heart's content, and no valid passwords would ever result from it.

This of course assumes the administrators are paying close enough attention to notice in short order when the database has been compromised, and that all users define a secondary means of contact through which to send a reset password. It also ignores the issue that most users use the same username and password across multiple sites, such that a pair compromised on one site and invalidated as described would still be valid on another site.

Re: There we go again

[AC-x]

Duh. Being Captain Obvious again?

By your previous posts it seemed you needed things put in simple terms, especially since you claimed that 1) knowing the hash is the same as knowing the password (it's not) and 2) rate limiting could defeat offline password cracking (it can't). Do you stand by those claims?

Of course, this is why you lock the accounts until the user resets the password. Poof that attack vector is now gone.

That's no solution: 1) Relies on the attack being detected in the first place. 2) If the user has reused their password elsewhere this doesn't reset those too. It's also completely irrelevant to the question of being able to dictionary attack a password.

Re: There we go again

[Desler]

Thank you! Someone that actually took the time to figure out the context of my statements.

Re: There we go again

[morgauxo]

"They can be, but it would be incredibly stupid to use something like that. A dictionary attack would crack that password in seconds"

Really? How?

First off, I would expect that a password cracking script's dictionary would include variations of single words and maybe combinations of 2. There are 11 words in that sentence. Anyone with such a password is such an outlier I can't believe any reasonable script today would be written to even try that!

So, what if everyone used passwords like that? No doubt cracking scripts would change. But how is a dictionary attack going to work? They can't possibly put every parsable sentence of a language into a dictionary! The example sentence was 11 words. Even if we treated that as a limit, how many sentences can be made out of 11 or fewer words? Certainly there are far more possible 11-word sentences than there are 11 character passwords.

And then there is punctuation. See the two commas?

Re: There we go again

[AC-x]

Do you notice that nowhere in that quoted statement is there anything about the attacker performing a dictionary attack using online login attempts?

It's rare for someone to attempt an online dictionary attack because it's slow and obvious. My post that, in the more likely real-world scenario of hackers having the password hashes, passwords are still vulnerable to (offline) dictionary attacks is absolutely true. To think that rate limiting of online logins can defeat dictionary attacks is foolhardy...

Re: There we go again

[AC-x]

Nope, because I never claimed that. You misunderstood my point and started falsely assuming things

Yes you did:

"But if the attacker knows the password hash that is not a dictionary attack. In fact, there would be no need for any attack at all." - No, you still need to attack (brute force) the hash to extract the password.

"Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker. If they can only have 5 tries every 15-20 minutes the attacker is going to give up unless the user's password just happens to be near the very beginning of the dictionary." - As written by you direct reply to a post about having the hash of a password, and is completely irrelevant if you have a hash.

Of course it is predicated on knowing you've been attacked. I was pretty sure that would be quite obvious.

The point is having a strong (not dictionary attackable) is preferable as it protects against password cracking proactively. Resetting a user's password after a hack is simply not as good as having a strong password that can't be cracked.

You've basically have been twisting my words into something I never stated or implied and then have applied them to scenarios outside of what I originally responded to. At this point I'm simply just going to ignore you.

You trolling or what?

Re: There we go again

[Desler]

This of course assumes the administrators are paying close enough attention to notice in short order when the database has been compromised, and that all users define a secondary means of contact through which to send a reset password. It also ignores the issue that most users use the same username and password across multiple sites, such that a pair compromised on one site and invalidated as described would still be valid on another site.

A very valid concern and as I address in another post it is not a perfect solution. There is no way to prevent users from reusing passwords across sites nor will there ever be foolproof way to spot every intrusion. But then again, no security procedure is perfect and anyone stating otherwise is selling you snake oil.

And as I've had to state over and over again (and this isn't meant against you wagnerrp), my statement about rate limiting, etc. was in the context of a post that did not mention an attacker already having compromised the system and having a DB dump with all the password hashes. That is a completely distinct scenario than the one I referred to and obviously would require other mitigations.

Re: There we go again

[AC-x]

But the real point is that's got nothing to do with having a password scheme strong enough to defeat a dictionary attack, which is what the AC above posted about.

In theory password hashes can be uncrackable, in practise most people pick passwords that can be cracked using a dictionary attack.

Coming up with a password scheme that is easier for people to remember but more difficult to brute force would be a huge step forward in IT security, and more useful than relying on all websites to never leak password hashes.

Re: There we go again

[jxander]

The kicker (for me) is that many websites DON'T allow certain character sets.

I've had websites tell me that I'm not allowed to use special characters. One of which was a financial institution.

Re: There we go again

[tlhIngan]

Only if you're dumb enough to let authentication program be suspceptible to such an attack. Dictionary attacks can be trivially defeated by rating limiting tries and after, say, 5 tries not allowing any more attempts for some cooldown period. No attacker is going to bother if they can only have 5 tries every 15 to 20 minutes.

Few attacks actually try to login repeatedly.

If they do, there are botnets that help you try lots in a short period of time.

Most attacks involve dumping the password hash database.

And even brute forcing is getting easier. If you need a SPECIFIC password, it's not any easier, but if you have a bunch of hashes and you want a good chunk of accounts (without caring if you have every account), it's actually easy. In fact, Ars Technica covers a domain-specific brute forcer.that relies on terminology from the sites cracked to get a list of potential passwords EXTREMELY quickly. Follow this with trivial modifications to get more. If you have a list of a million passwords, you could easily derive half of them this way, and then move on to the next list.

Remember, let's differentiate between cracking one SPECIFIC account and password, with cracking AN account and password from a list. You might be cool and use a super complex password that involves every typeable character on the keyboard, and yes, people may not find your password easy to crack. But perhaps your neighbour just used "password". Well, of the two, it's easy to crack AN account, but not a SPECIFIC account.

Re: There we go again

[AC-x]

As I originally responded to AC-x, if the attacker already has the hash and can then brute force it, of course what I mentioned doesn't stop them, but that scenario is no different than knowing their phone's PIN and being able to side step any of the very same protections I mentioned that phone OSes use which is to use a lock-out after a certain number of failed attempts.

As I've had to point out many times knowing the hash is very different to knowing a pin code. Seriously here's an SHA1 hash, can you reverse it? b6faa93a9e6ca445875c6b5511e2153bb51ef43a

The point you've been missing from the original AC's post is that some password schemes are much easier to brute force (eg. with a dictionary attack) than others. That's completely separate to rate limiting online logins and password resets etc.

Re: There we go again

[penguinoid]

I've never understood why passwords can't be sentences, like "I'm going to take my dog, Spot, to the park today."

They can be, but it would be incredibly stupid to use something like that. A dictionary attack would crack that password in seconds.

Wrong. That would be an incredibly strong password -- just because it's easy to remember doesn't mean it has low entropy. I mean, if it were a combination of 11 semi-random characters you would think it was a strong password, but because it is 11 semi-random words you think it's weak? Yet there's way more words than there are letters.

Just have websites measure password entropy and get rid of the various stupid requirements and restrictions.

Re: There we go again

[Desler]

If they do, there are botnets that help you try lots in a short period of time.

After the first 5 failed logins you don't allow ANY logins for the cooldown period so having a botnet does't really help you. Also, it would be trivially to detect that someone is hopping from IP to IP to try to login to the same account as this would not be something a normal user would ever do. At that point you simply lock the account entirely, ban any of the IPs that continue to try to login to the account and then work from there.

Most attacks involve dumping the password hash database.

Which is a different scenario than what I was referring to. In that case you better hope you detected the attack or else you are basically fucked.

And even brute forcing is getting easier. If you need a SPECIFIC password, it's not any easier, but if you have a bunch of hashes and you want a good chunk of accounts (without caring if you have every account), it's actually easy. In fact, Ars Technica covers a domain-specific brute forcer [arstechnica.com].that relies on terminology from the sites cracked to get a list of potential passwords EXTREMELY quickly. Follow this with trivial modifications to get more. If you have a list of a million passwords, you could easily derive half of them this way, and then move on to the next list.

Brute forcing is getting easier. That is why you simply make your site an unattractive one to attack by making it so they can only do a very small amount of attempts before hitting a cooldown and then an eventual total account lock. Sure, this can be an annoyance to a user, but it's much better than their account being breached. But again, if the attacker already has a password hash list from already cracking your system, they have a much easier go at you especially if they can find out you didn't salt the hashes (or you used a weak PRNG for the salting, etc.) or do any other proper procedures.

Re: There we go again

[AC-x]

The problem with that scheme is if you let users pick their own passwords they tend to follow certain patterns that make them easier to brute force.

Re: There we go again

[Desler]

To add, I want to again stress that what I stated is not a catch-all for any and all potential attack vectors. It was simply made in the context of a person attempting to dictionary attack a user's password without them already having a password hash list or any other information from having previously breached your system. Anything beyond that scenario obviously requires further mitigations and procedures being in place.

Re: There we go again

[AC-x]

So, what if everyone used passwords like that? No doubt cracking scripts would change. But how is a dictionary attack going to work? They can't possibly put every parsable sentence of a language into a dictionary! The example sentence was 11 words. Even if we treated that as a limit, how many sentences can be made out of 11 or fewer words? Certainly there are far more possible 11-word sentences than there are 11 character passwords.

If that were the only password like it in a database that's true, but if we're suggesting a new password scheme that's adopted (like the XKCD several random words password) then a password made from a valid sentence like that would be easier to crack than a nonsense sentence.

Re: There we go again

[Entropius]

Even barring the "attacker gets /etc/passwd and you don't know about it" problem, the problem is password reuse. If you require people to have strong passwords then they'll likely reuse them on other websites; Facebook isn't going to lock user accounts because somewhere else got their hashes compromised.

Re: There we go again

[Mr. Flibble]

You started a whole chain of argument here after this comment and enter into a debate with AC-x.

I am going to have to side with AC-x, here, you don't have a fundamental understanding of what he is putting forth in this discussion. You seem to be defending your points without fully understanding them.

Dictionary attacks are not used on things that are rate limited - they are used on grabbed hashes.

Read "The Cookoo's Egg" by Cliff Stoll for a very old tale of this exact scenario. It still occurs today.

Re: There we go again

[tepples]

IP banning is less effective against a DDoS using a botnet of thousands of compromised home PCs. Someone who wants to keep a legit user from being able to use the service could just log in a few times with an incorrect password and then repeat a few minutes later. Each IP would DDoS a separate user.

Re: There we go again

[Desler]

Sure, that is a problem but it's not as if any single site can prevent that. As I've said over and over again, nothing of what I have stated is perfect since there is no such perfect security measure. As stated numerous times, my comments about certain things are always within a certain context.

To offer up an analogy to the way AC-x has been attacking me: My original post would be like me talking to someone who says that it's pretty easy to pick a lock that has an external keyhole (which is certainly true in many situations), and then I come back by saying that in such a case you should have a deadbolt that has no way to be unlocked externally. AC-x then comes into the conversation to tell me about how if the person has a sledgehammer that they can just brute force there way around the deadbolt problem. I then come back and say, sure, they could also simply break a window to bypass the deadbolt as well. And then he comes back telling me about how I'm stupid and don't know anything of how deadbolts and sledgehammers work.

Now, his statement is surely true that a sledgehammer breaking through a door will certainly be able to bypass a deadbolt. He is also correct that having previously infiltrated a system you can try to offline brute force a password so that you can get in without hitting any of the mitigations I brought. But that was not the context of the response that I made to the person which was simply that of someone trying to dictionary attack a site without having any prior knowledge about the user's password (or in the hypothetical situation the person simply has a lockpick set not a sledgehammer).

Re: There we go again

[Entropius]

The trouble is that measuring entropy is hard as it depends on context.

"Frutyyzlrdkgejk" looks like a string of characters with high entropy. So does "Cthulhufthagn". One is likely to be tried by an intelligent password cracker long before the other.

"Football purple dizzy rainbow" looks like four words chosen at random and thus has high entropy. So does "correct horse battery staple." One of these is a much weaker password than the other.

Re: There we go again

[macs4all]

've never understood why passwords can't be sentences, like "I'm going to take my dog, Spot, to the park today." It's much easier to remember for the layperson

You say that; but I once created a whole-diskette encryption system for the Apple ][ (you laugh; but...), and it allowed for passphrases up to 30 (or so) characters. Like the perfect idiot, I decided to encrypt the SOURCE DISK for my Encryption code with a phrase from a Firesign Theatre Album.

The passphrase was "Holmes, you snowball!" Simple to remember, right?

Well, either I mistyped something when I entered the passphrase in the Encryption phase, or I forgot some variant of comma, no comma, number of exclamation points, or something; because to this day, that source code is safely locked away on the master diskette, never to be seen (or installed), again...

Re: There we go again

[Desler]

I am going to have to side with AC-x, here, you don't have a fundamental understanding of what he is putting forth in this discussion. You seem to be defending your points without fully understanding them.

I fully understood what he put forth and repeatedly stated that it had no relation to the context of my original statement.

Dictionary attacks are not used on things that are rate limited - they are used on grabbed hashes.

Not true. A dictionary attack has no such prerequisite. Dictionary attacks are used all the time even when you have no grabbed hash. You're simply redefining the term.

Wikipedia:

In cryptanalysis and computer security, a dictionary attack is a technique for defeating a cipher or authentication mechanism by trying to determine its decryption key or passphrase by trying hundreds or sometimes millions of likely possibilities, such as words in a dictionary.

Technique
A dictionary attack uses a targeted technique of successively trying all the words in an exhaustive list called a dictionary (from a pre-arranged list of values).[1] In contrast with a brute force attack, where a large proportion key space is searched systematically, a dictionary attack tries only those possibilities which are most likely to succeed, typically derived from a list of words for example a dictionary (hence the phrase dictionary attack). Generally, dictionary attacks succeed because many people have a tendency to choose passwords which are short (7 characters or fewer), such as single words found in dictionaries or simple, easily predicted variations on words, such as appending a digit. However these are easy to defeat. Adding a single random character in the middle can make dictionary attacks untenable. Unlike Brute-force attacks, Dictionary attacks are not guaranteed to succeed.

Funny, not a single mention of a grabbed hash and I can find many such more definitions and explanations that also contain no such prerequisite.

Re: There we go again

[ShanghaiBill]

As soon as the hash database were compromised, all hashes contained therein would be invalidated.

Two problems:
1. How do you know that your database has been compromised? A hacker isn't going to send you a text message and let you know. Most security breaches are inside jobs, which are even harder to detect.
2. Many people use the same password for all their accounts. So even if one site invalidates it, a hacker can use the same login/password combination on other sites.

Re: There we go again

[Desler]

IP banning is less effective against a DDoS using a botnet of thousands of compromised home PCs.

Already mentioned in another post. At that point, you just lock the account entirely and just ignore any and all further login attempts into you can get in contact with the account holder and work out things from there. It's an inconvenience for them, but much better than a breach.

Someone who wants to keep a legit user from being able to use the service could just log in a few times with an incorrect password and then repeat a few minutes later. Each IP would DDoS a separate user.

Better they be kept out of the service for some period of time versus their account being breached. You can also get around this by some sort of whitelisting mechanism paired with a two-factor authentication.

It's amusing how everyone is telling me that my ideas are bad yet they are basic security measures that almost every decent website and service use. I can even name drop Jeff Atwood to back me up as well:

Limiting the number of login attempts per user is security 101. If you don't do this, you're practically setting out a welcome mat for anyone to launch a dictionary attack on your site, an attack that gets statistically more effective every day the more users you attract. In some systems, your account can get locked out if you try and fail to log in a certain number of times in a row. This can lead to denial of service attacks, however, and is generally discouraged. It's more typical for each failed login attempt to take longer and longer, like so:

http://blog.codinghorror.com/d...

And even Bruce Schneier agrees and quotes the very same article:

Bad Password Security at Twitter
Twitter fell to a dictionary attack because the site allowed unlimited failed login attempts:

Cracking the site was easy, because Twitter allowed an unlimited number of rapid-fire log-in attempts.

Coding Horror has more, but -- come on, people -- this is basic stuff.

http://www.schneier.com/blog/a...

So are you guys going to tell me how Jeff Atwood and Bruce Schneier are idiots and don't know anything despite the fact that what I said is basically parroting their own suggestions?

Re:There we go again

[gmhowell]

Why do they want to kill my password? What's wrong with "@13 unicorn #DARPA gangbang!"? It's secure isn't it?

Damnit, time to change the combination on my luggage again...

Re: There we go again

[Desler]

And here is an article on Dictionary Attacks by Jeff Atwood. Notice how nowhere in the article does he mention anything about already having password hashes? And here is the original article from Wired about the very dictionary attack used against Twitter which is the context of Jeff's article. Here is a nice relevant quote:

The intrusion began unfolding Sunday night, when GMZ randomly targeted the Twitter account belonging to a woman identified as "Crystal." He found Crystal only because her name had popped up repeatedly as a follower on a number of Twitter feeds. "I thought she was just a really popular member," he said.

Using a tool he authored himself, he launched a dictionary attack against the account, automatically trying English words. He let the program run overnight, and when he checked the results Monday morning at around 11:00 a.m. Eastern Time, he found he was in Crystal’s account.

Notice how that quote or even the rest of the article makes any mention of the attacker already having hashes yet it was still called a dictionary attack.

Re: There we go again

[Desler]

Should be "Notice how neither that quote or even the rest of the article makes any mention".

Re: There we go again

[Desler]

Did you read his whole post?

This of course assumes the administrators are paying close enough attention to notice in short order when the database has been compromised

I also said this as well. Of course if you have no clue that you were attacked you can't employ such a measure. Isn't that quite an obvious implication? Secondly, there is no way any single website can prevent password reuse, so as such both him and I both acknowledged that was another weakness. As he also said:

It also ignores the issue that most users use the same username and password across multiple sites, such that a pair compromised on one site and invalidated as described would still be valid on another site.

Re: There we go again

[Mr. Flibble]

Funny, not a single mention of a grabbed hash and I can find many such more definitions and explanations that also contain no such prerequisite.

Maybe you should read the book I mentioned.

You keep trying to defend a point beyond exhaustion. Lay off on the aspergers.

Re: There we go again

[Desler]

Maybe you should read the book I mentioned.

And that changes the fact that you redefined dictionary attack how?

You keep trying to defend a point beyond exhaustion.

Yes, because I was not wrong. Dictionary attacks are still dictionary attacks even if the attacker does not have password hashes. A dictionary attack simply means that the attacker has a list of dictionary words that can be used to try to guess the user's password. Nothing more.

Lay off on the aspergers.

Don't have it. Nice ad hom, though.

Re: There we go again

[Desler]

I would mod you up if I had points. I'm glad some people actually bothered to read and comprehend the context of my posts. Thank you!

At this point I will simply give up because I can't win when being bombarded by all these people twisting my words and taking me out of context.

Re: There we go again

[tepples]

At that point, you just lock the account entirely and just ignore any and all further login attempts into you can get in contact with the account holder and work out things from there.

I understand Jeff Atwood's and Bruce Schneier's point. But once a substantial percentage of accounts have been locked entirely in this manner, how is your business going to afford the support costs of contacting each affected account holder?

Re: There we go again

[bondsbw]

Unless they have a copy of the password hash

Add proper salting and an adequate number of iterations over the hashing function, and the attacker's computer will be necessarily slowed as well.

Re: There we go again

[schlachter]

This would be fairly simple to brute force attack a password like you suggest. Every day sentences are not a good idea. Completely random sets of words would be better, but still not as secure as a strong password in the traditional way.

Things like typing speed and cadence over a longish sentence that you have previously chosen could be a nice alternative.

Or an interactive experience where you type your sentence, and the system responds with a new sentence, and you type some more stuff, might be alright, kind of like a series of secrete phrases 007 style, which kill the conversation at any point there is an unexpected deviance.

Re: There we go again

[sexconker]

And before the grammar nazis come out, yes I accidentally typed you're instead of your. Let me go commit seppuku now.

The first rule of holes: When you're in a hole, stop digging.
Your initial post in this thread exposed the fact that you don't know what the fuck a hash is, and thus don't know what the fuck you're talking about.
You should have simply stopped posting, but here you are, digging deeper and deeper, committing more and more errors. You couldn't even quote a post properly.

Re: There we go again

[AC-x]

I really don't see how that's true, look at how the thread progressed -

AC1: "[We just need better passwords - eg. a complete sentence]"

AC2: "[That password could be broken by a dictionary attack]"

Desler: "Dictionary attacks can be trivially defeated by [rate] limiting"

Me: "Unless you have the password hash"

Desler: "(Insults) ... But if the attacker knows the password hash that is not a dictionary attack. In fact, there would be no need for any attack at all."

Me: "[Password hashes are one way only so still need to be attacked, weak passwords are susceptible to brute forcing the hash]"

Desler: "Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker."

Me: "[Rate limiting doesn't apply to brute force cracking of hashes]"

Desler: "(more insults) Of course, this is why you lock the accounts until the user resets the password. Poof that attack vector is now gone."

Seriously, between him throwing insults and going on about rate limiting preventing brute forcing a hash, where have I misread what Desler said?

Re: There we go again

[sexconker]

Hey Desler I really don't get you, you (appear to) know what a salt is yet you don't understand that an attacker would be performing the attack on the hash offline, with their own hardware. Rate limiting their own hardware would be, as you put it, the height of idiocy.

He's furiously reading (but not understanding) wikipedia as he types. It's pretty common on Slashdot, actually.

Re: There we go again

[AC-x]

Indeed, although whatever hashing scheme you have, having a password that's findable in a dictionary attack will always be much quicker than one that needs to be completely brute forced.

Re: There we go again

[sexconker]

The point he was making is that with proper procedure, a hash could never be attacked offline. As soon as the hash database were compromised, all hashes contained therein would be invalidated. The attacker could brute force that database to their heart's content, and no valid passwords would ever result from it.

This of course assumes the administrators are paying close enough attention to notice in short order when the database has been compromised, and that all users define a secondary means of contact through which to send a reset password. It also ignores the issue that most users use the same username and password across multiple sites, such that a pair compromised on one site and invalidated as described would still be valid on another site.

LOLWHAT
99% of the time, you won't notice your shit has been compromised until well after the fact. You typically learn of it when lots of users report that their shit has been stolen.
The best an administrator can do is expire the passwords and send a notice out to the registered email addresses of the users with a unique reset link. The attacker likely also knows the email addresses. Any user using the same password for your site and email is fucked if the attacker has cracked their password. The users using the same password for a random site and their email are typically the same users with shitty, easy-to-crack passwords.

The bottom line is that password hashes and salts are only as secure as the passwords themselves.

Re: There we go again

[AC-x]

I fully understood what he put forth and repeatedly stated that it had no relation to the context of my original statement.

Sorry Desler you can't just say I was only talking about dictionary attacks on rate limited login portals, so no-one is allowed to talk about anything else, if you're going to mention dictionary attacks then attacking hashes will always be part of that discussion whether you want it to be or not.

Re: There we go again

[sexconker]

And as I've had to state over and over again (and this isn't meant against you wagnerrp), my statement about rate limiting, etc. was in the context of a post that did not mention an attacker already having compromised the system and having a DB dump with all the password hashes. That is a completely distinct scenario than the one I referred to and obviously would require other mitigations.

B u l l s h i t .

I've never understood why passwords can't be sentences, like "I'm going to take my dog, Spot, to the park today."

They can be, but it would be incredibly stupid to use something like that. A dictionary attack would crack that password in seconds.

What I do is have a single, strong password that I have stored only in my brain and all other passwords are hashed on-the-fly from that and the domain or name of whatever I need the password for. I get unique, strong password for everything, but only have to remember a single one.

Only if you're dumb enough to let authentication program be suspceptible to such an attack. Dictionary attacks can be trivially defeated by rating limiting tries and after, say, 5 tries not allowing any more attempts for some cooldown period. No attacker is going to bother if they can only have 5 tries every 15 to 20 minutes.

The post you replied to only mentioned "dictionary attack". Dictionary attacks are OFFLINE ATTACKS 99.999999% of the time.

Re: There we go again

[sexconker]

To clarify, I should say any brute forcing attacks rather than just dictionary attack. Any authentication program that allows unlimited tries without any rate limiting is totally broken.

You're absolutely fucking retarded and you need to stop. The vast majority of "authentication programs" are nothing more than:
if (HASH(inputPW & getSalt(inputUser)) == getHASH(inputUser))
    successfulLogin(inputUser);
else
    unsuccessfulLogin(inputUser);

How the fuck do you think people attack passwords once they have the hash? Rate limiting doesn't stop an offline attacking from succeeding on the first try online after it cracks the password offline. Rate limiting doesn't stop an online attack because an online attack is going to take forever due to the fucking latency. And with no latency, an online brute force or dictionary attack simply turns into a DoS attack if you have rate limiting enabled.

Re: There we go again

[macs4all]

If the user has reused their password elsewhere this doesn't reset those too.

Yes; but the Internet is big.

Really big.

So, how does cracking a password on one site gain you any knowledge whatsoever as to where, in the vastness of the internet, that it was used again?

Re: There we go again

[s.petry]

Perhaps a bit pedantic, but a dictionary attack would not crack anything that is not in the dictionary. If "I'm going to take my dog, Spot, to the park today." results in a password of "Ig2tmd,S2tpt." then a dictionary attack would never be able to crack it. A "worm" would crack it, but given a length of 13 characters it would take a long ass time to crack. If you change your password every few months, as security experts recommend, you have an extremely low chance of being "cracked" into.

DARPA, NSA, CIA, FBI, DHS, ATF, FEMA, and every other government agency wants something other than passwords to be your password. Don't worry citizen, nothing every goes wrong with things like that. Remember that in theory the Government works for you, just ignore the practice.

By the way, I do the same thing with my password as you. Fragments are inserted for functionality, the "password" structure is similar. The problem however, is what GP stated. I can't use my normal methodology in many locations because "You can only use numbers and letters in your password", followed by "Your password exceeds length" errors.

If people and companies could get passed 1990s CRYPT authentication the world would be a bit safer for those of us that care. We'll never be able to fix the people using "password" as their password, and biometrics won't fix them either.

Re: There we go again

[Desler]

Your initial post in this thread exposed the fact that you don't know what the fuck a hash is, and thus don't know what the fuck you're talking about.

That's weird. My initial post nor the post I responded to said anything about hashes. My initial post was responding to someone talking about using a dictionary attack to get someone's password. I presume you falsely think my "initial post" was the one in response to AC-x which it wasn't. I also very much do know what a hash is. You and him seem to have a reading comprehension problem since you failed to understand my post. The point of my post was to say that, yes, having a password hash which you can use to try to recreate the original password does defeat what I stated, but that is tautological. If you can do an end run around the authentication protections it is no different than, as I said in an analogy, to having someone's PIN to their phone. I never once stated that having a hash was the same as having a plaintext password nor was their any such implication. Him stating that I believed the two were the same is basically a false presumption on his part by failing to understand my analogy.

You should have simply stopped posting, but here you are, digging deeper and deeper, committing more and more errors. You couldn't even quote a post properly.

I only messed up a quote once out of more than a dozen posts. Yeah, I totally don't know how to quote properly. Oh wait, I do.

Do you have an actual argument or just stupid ad homs like AC-x?

Re: There we go again

[Darinbob]

I am amazed sometimes when I just need to make a throwaway password for some innocuous site, and it refused my password for have extra characters. I've seen one that only accepted alphanumeric character plus '$' and nothing else, and I've seen one that rejected passwords longer than 8 characters. I don't think it was the underlying security requiring this but the junior intern they got to design the web site

Re:There we go again

[ArcadeMan]

There's no need to nuke the website from orbit. The server is running IIS, it will implode on itself sooner or later.

Re: There we go again

[AC-x]

So, how does cracking a password on one site gain you any knowledge whatsoever as to where, in the vastness of the internet, that it was used again?

The email address they used to register is the obvious one. They may also have connected social media accounts to whatever site got hacked.

Re: There we go again

[AC-x]

You should still only allow a certain number of failed login attempts for a given username. Sure it's rare to brute force via an online login, but it's worth doing to protect a user's account. Sure it sucks for that individual user to have the small possibility of being locked out their account temporarily, but it's not as bad as losing their account and also discourages any hacker from hammering your server and sending your entire site down in an actual DOS.

Re: There we go again

[penguinoid]

You obviously don't know what entropy is. Hint: if you can compress information, say by saying the 457th word in my dictionary, then it is low entropy information (the dictionary is sorted by how common words are in passwords, so that common words need a short index). This is also why passwords like 12345 or asdfg are low entropy. I suppose this is where you say I really should be using a non-password related measure of entropy, and then tell me it won't work.

Re: There we go again

[AC-x]

Your "solution" is poorly thought out and is why nobody does it that way

Banks will lock you out on the 2nd or 3rd failed attempt. A quick Google finds plenty of sites like Paddy Power and Yahoo lock accounts after a few bad password entries.

Most sites at least switch to a captcha after several failed logins too.

Re: There we go again

[macs4all]

So, how does cracking a password on one site gain you any knowledge whatsoever as to where, in the vastness of the internet, that it was used again?

The email address they used to register is the obvious one. They may also have connected social media accounts to whatever site got hacked.

You are making a lot of assumptions there; but, ok, I guess...

Re: There we go again

[AC-x]

You are making a lot of assumptions there; but, ok, I guess...

There are no assumptions here, it's well known that a high percentage of users reuse the same password for multiple sites, including their email. Therefore if you crack an average user's account on a site you've got a good chance of also having their email address password. Obviously having control of someone's email is ground zero as far as getting account credentials is concerned, but even if they use a different password for email there could be connected sites (such as the Sony example in the link) that many users use the same login for, so a breach in a "low importance" service could expose users on more important service from the same company.

Re: There we go again

[sl149q]

Yes, I only want access to your stupid site for one transaction or comment or whatever and you make me jump through stupid fscking hoops to register an account with a password that would protect my online banking...

Type in some random garbage twice, use it, and forget it. If I ever need to go back just hit the "forgot password" link and do the same again.

Re: There we go again

[Culture20]

Sort of like how a destroyer is easier to lift with one's bare hands than the Empire State Building?
The real bad part about a grammatically correct sentence is memory mutation.
"I'm going to take my dog, Spot, to the park."
"I'm going to take my dog to the park today."
"I'm taking my dog, Spot, to the park today."
"#&@*!!! What was that passphrase?"

Re: There we go again

[chihowa]

Sure, "Harry Potter" would be a weak password, but the AC above used, "I'm going to take my dog, Spot, to the park today." Even though it's grammatically correct (limiting the entropy), no dictionary attack will crack that in a reasonable amount of time. Rename the dog, throw in a typo, or screw with the punctuation and that's a quite strong passphrase.

Re: There we go again

[CaptainDork]

Well, it USED to be so, but not so much anymore, I think.

Bolted on to the dictionary hack is the "M!sp3ii3d" run.

Re: There we go again

[juancn]

Only if you're dumb enough to let authentication program be suspceptible to such an attack. Dictionary attacks can be trivially defeated by rating limiting tries and after, say, 5 tries not allowing any more attempts for some cooldown period. No attacker is going to bother if they can only have 5 tries every 15 to 20 minutes.

Please, if you ever have to implement one of this cool down periods, don't be an asshole and allow just 5 attempts (or 3 or something equally idiotic).

There's no good reason why not allow, let's say a 100 attempts, and even really short cool down period should be enough, for example 500ms. Time for some quick & dirty math, assuming 36 possible characters and an 8 character password, a 500ms cool down would add: 36^8*.5/60/60/24/365 ~= 48000 years to brute force all combinations.

Re: There we go again

[AK Marc]

If the attacker is performing the attack "offline" then you've already lost the security battle. That's the point. If you lose your password database, assume the passwords are all broken, no matter whether you have "must have 3.2 uppercase and 4.35 lowercase letters, 0.6 special characters and as many numbers as you like, so long as it doesn't start or end with a number" rules or let them use plain English sentences. A hashed " " is as meaningful as a hashed "a" so "cat dog run fast" is better than a very random 8-char password. http://xkcd.com/936/ Even if you know it's susceptible to a dictionary attack, it'll be better than most.

But the point is, once they have your hash, you've already screwed up your security. Especially if you don't then change all the passwords.

Re: There we go again

[AK Marc]

So are *any* attacks performed live, rate limited? What are they called? Rate limiting is a *response* to brute/dictionary attacks being performed on live login servers. Obviously someone did it, or they wouldn't have shut down that vector. Security is very reactive, and seldom proactive.

Re: There we go again

[AK Marc]

And if I spoof my source IP to your valid user's IPs? Your DOS prevention will be worse than the DOS itself. Lockout all your actual users because one guy is attacking you.

Re: There we go again

[Tanktalus]

Do you think that simply because you omitted that common attack vector that it's magically not going to happen?

Rate limiting, et al, has a singular primary purpose: to make things hard enough that an attacker doesn't get the password hash. Anything else is pure gravy.

Once the attacker has the password hash, the next defense is a strong password. And that's where we need to focus the entire debate about passwords vs passphrases vs biometrics vs telepathy. Assume the attacker has your password hash. This worst-case scenario is reality all too often. Yes, throttle password attempts and all that, but if your server has Sarah Palin or Barack Obama on it, assume that someone, somewhere, will deploy sufficient resources to getting that password hash through some zero-day vulnerability. (If your site is just discussing hooch for local rednecks in Bumfuk, Virginia, then the passwords are likely safe, regardless of how insecure the system is.)

Re: There we go again

[penguinoid]

I bet you also think entropy is near useless in an ASCII attack (trying combinations of characters) unless your password is sentence-length? There's more words than there are characters, and people don't even use all the characters there are.

Re: There we go again

[chuckugly]

Are you sure? A classic dictionary attack would hash all the words in the dictionary (or common password list) and then taking the known hash of the password, look up which common word computes to the same hash with the same (known) algorithm and salt.

I don't see how that would work here.

Maybe you are thinking of a brute force attack?

Re: There we go again

[chuckugly]

Maybe you are thinking of a brute force attack? I don't see how a rate limit on the server is going to change the computation of a hash for comparison on the attackers machine.

Re: There we go again

[chuckugly]

.... if the attacker knows the password hash that is not a dictionary attack.

The classic dictionary attack is to retrieve the list of password hashes and backwards compute to try and match common passwords to the known hashes, thus rendering a list of known passwords to use. The accounts are then compromised. Calling a modified brute force attack a dictionary attack is also common but a bastardization of the real thing.

Re: There we go again

[AK Marc]

Yup. Because SQL injection attacks work in passwords, especially when you have a 4,000 old COBOL system.

Re: There we go again

[AK Marc]

Sometimes it seems like the sites make their password rules match banks. Then, if you can't find anything else that works, use your bank password. The site then has your email, name and bank password. They can try that combo on all the major bank sites, and could get access.

I'm surprised more black-hats don't set up "free" services with that intention.

Re: There we go again

[sexconker]

Your initial post in this thread exposed the fact that you don't know what the fuck a hash is, and thus don't know what the fuck you're talking about.

That's weird. My initial post nor the post I responded to said anything about hashes. My initial post was responding to someone talking about using a dictionary attack to get someone's password. I presume you falsely think my "initial post" was the one in response to AC-x which it wasn't. I also very much do know what a hash is. You and him seem to have a reading comprehension problem since you failed to understand my post. The point of my post was to say that, yes, having a password hash which you can use to try to recreate the original password does defeat what I stated, but that is tautological. If you can do an end run around the authentication protections it is no different than, as I said in an analogy, to having someone's PIN to their phone. I never once stated that having a hash was the same as having a plaintext password nor was their any such implication. Him stating that I believed the two were the same is basically a false presumption on his part by failing to understand my analogy.

You should have simply stopped posting, but here you are, digging deeper and deeper, committing more and more errors. You couldn't even quote a post properly.

I only messed up a quote once out of more than a dozen posts. Yeah, I totally don't know how to quote properly. Oh wait, I do.

Do you have an actual argument or just stupid ad homs like AC-x?

The fact that you've made a dozen (and counting) posts trying to re-re-re explain and rectify your mistakes should clue you in to the fact that you got called out for spewing bullshit and no one is buying the repeated attempts to retcon your hilarious error.

Re: There we go again

[WuphonsReach]

Maybe. Let's assume that all of the words in the sentence are within the 4096 most common words. That's 12 bits of entropy per word. So a six word sentence would, at the upper end, have 6x12 bits (72).

However, you can probably count on "the" and a few of the other 32 most common words being at various positions. So for those words, there's only 5 bits of entropy. And if it is a grammatically correct sentence, then markov-chaining or other tricks like n-grams might reduce your search space from 12 bits per word down to 8-10 bits per word.

Real quickly we're down into the 50-60 bit range... which is not very promising. Still enough to prevent the $10 of CPU time attacks, but vulnerable to the $1000 ($10k?) of CPU time attacks. And CPU costs do get cheaper over time...

That being said... password input forms should allow lengths of up to 100 UTF-8 glyphs. Let the user decide how long they want to go.

Re: There we go again

[s.petry]

Not clear enough regarding the "fragment". "Frag(bnk)22x=y" for example would be a bank password, "Frag(eml)22x=y" for email, etc..., so the fragement I'm referring to is an identifier in the password for the service. No, I don't really use something that simple, but it should make the point.

The hashes for these are obviously going to be different, and a brute force attack would take quite a while to crack the password even if someone acquired a hash. Since a new equation comes around every 6 months or so, statistically by the time it could be broken I would have a new password. Obviously this excludes a government supercomputer from the mix of statistics. If a Government wanted to nab me, a password is the hard way to do so.

Re: There we go again

[AC-x]

If the attacker is performing the attack "offline" then you've already lost the security battle. That's the point. If you lose your password database, assume the passwords are all broken, no matter whether you have "must have 3.2 uppercase and 4.35 lowercase letters, 0.6 special characters and as many numbers as you like, so long as it doesn't start or end with a number" rules or let them use plain English sentences.

The point is a decent password scheme will make brute force attacks a lot more difficult. Relying only on "never getting hacked" isn't a good policy, so taking a complete approach to security as a whole (such as also coming up with a better password scheme) will always be better than only concentrating on one aspect. Coming up with a password scheme that is both more secure and easy to remember is one of the big unsolved IT security problems of course.

A hashed " " is as meaningful as a hashed "a" so "cat dog run fast" is better than a very random 8-char password.

Not quite, according to Randall 4 common words has an entropy of 44 bits (as long as they are chosen randomly). 8 random characters (uppercase, lowercase, numbers) has around 47.6 bits of entropy. If you have GPU that can chew through hundreds of millions of hashes a second (the record is 350 billion/sec for a 25 GPU cluster) you'd still ideally want more entropy than that though.

Re: There we go again

[lsatenstein]

Off topic slightly How about swapping the position of two fields

One of my pet peeves is that the masked password field does not precede the logon field for the name. A good way is prevent the accidental revealing of a password to enter the password field, skip to the logon field (no message), enter the logon name and then discover that the pwd or logon name was wrong.

Why??? Why would I want to do that? Well....

When you have a logon name, but forget to move the cursor to it, and you are in a hurry, you end up entering the password in the logon name field before you noticed the error.
Someone standing behind your back, (as it almost always is, because they are waiting for you to do something for them), has full view of the revealed password as it is in plain view.

Logic can be used to block the logon field until the pwd field has an entry.
Validation to take place at completion of both fields.

Currently
As it is now, the logon field is wide open, without being blocked. Even if you do not want to flip the fields, it should be mandatory for the password field to be completed and then allow the user to have the logon field accessable. Of course, it means that logons without passwords would require a dummy password. Is there harm in that?

Justification My desk used to be in a large cubicle, shared with non-system adminstrators.

Re: There we go again

[uninformedLuddite]

Your comment reminds me of a Sys Admin I knew years ago. This guy was a complete tosser and was always expounding how much he knew, he was the super secure expert and he would never be hacked (blah blah narcissistic blah). Anyway the punchline is that his password was 'aardvark'.

Re: There we go again

[uninformedLuddite]

Do you have an actual argument or just stupid ad homs like AC-x?

Your Momma?

Re: There we go again

[uninformedLuddite]

How the fuck do you think people attack passwords once they have the hash?

With very bloodshot eyes?

Re: There we go again

[AK Marc]

I used one of those and they realitime reject passwords that don't match the attacked server. "I'm sorry, your password isn't strong enough, please try another", until it logs into the battle.net account, and then it takes it and tells you everything is ok.

More nefarious would be to have bizarre unpublished rules that require you take 10 tries to make a password, then try all the "failures" with the email to log into all the popular sites.

All you need is the email password, and you can compromise everything else, anyway.

Re: There we go again

[dl_sledding]

To be fair, though, a sentence is MUCH better than your dog's name or your birthdate... So, don't totally discount it as insecure. It's much more secure than my examples, simply because of the number of characters and punctuation involved.

I do like your interactive experience idea... A nice, big database of answers to pre-asked questions, chosen randomly during each "experience", so they aren't duplicated in an order. Not questions based on facts that are retrievable, like your mothers maiden name, your first car, or your 5th grade teacher, but questions based on an opinion or something. Good idea.

Re: There we go again

[morgauxo]

Yes. It would be easier to crack a gramatically correct sentence than a nonsense one because grammer rules would narrow down the possiblities. Who today is using whole nonsense sentences as their passwords? I assume a nonsense sentence is a collection of words right? Currently most people are using nonsense words, a collection of characters. So, tell me there aren't more possible permutations of 6-9 word gramatically correct sentences than there are 6-9 charcter collections of nonsense words...

All good until someone simulates biometrics...

[Anonymous Coward]

You can change a password, you can't change your retina print. What do you do when your account is compromised? Get new eyes?

Re:All good until someone simulates biometrics...

[peragrin]

New eyes , new finger prints, and new DNA.

What happens if you get sick or injured? Can you imagine pink eye with retinal scanners? Finger print scanners are fooled by gummy bears.

Re:All good until someone simulates biometrics...

[rodrigoandrade]

Pink eyes, eh? Don't go to work stoned, then..

Re:All good until someone simulates biometrics...

[Thanshin]

Finger print scanners are fooled by gummy bears.

Where I work, the scanners are quite high. Way beyond the reach of even the tallest gummy bears.

Re:All good until someone simulates biometrics...

[Anonymous Coward]

They may be short, but don't be fooled - they can actually reach quite high if they have their juice with them.

Re:All good until someone simulates biometrics...

[mellon]

Exactly right. Biometric passwords are much easier to fake, because you can't change them. They also provide a nice means of identifying surveillance targets. It's almost as if these guys are getting direction from the NSA or something.

Re:All good until someone simulates biometrics...

[Anonymous Coward]

For those of you that don't get the joke: there was a cartoon about bouncing gummi bears in the 80s. It has an amazing theme song:
https://www.youtube.com/watch?...

Re:All good until someone simulates biometrics...

[bombman]

Well, then instead of Russian (hackers?) breaking in and stealing passwords, they will steal the
biometric data that is matched against in the database, and then they can spoof that....

It may be less useful as a 'cracklib' though.

Re:All good until someone simulates biometrics...

[m00sh]

You can change a password, you can't change your retina print. What do you do when your account is compromised? Get new eyes?

Instead of all this BS, just make an app that stores all the sub-passwords from a master password.

You can link your biometrics to the master password and even if you sub-passowrds are compromised, you can change them.

If you master password is compromised, then used a different finger or a different combination of biometric plus another password.

The biggest problem I have faced is the arbitrary password rules. Some sites require you have to choose from .\$[] character set whereas others cannot have it in the password. Some have length limits and some minimums. Some require at least two alphanumeric characters. Some allow phrases some don't.

Re:All good until someone simulates biometrics...

[Bob9113]

>> Finger print scanners are fooled by gummy bears.

> Where I work, the scanners are quite high.

Aww, come on, now, no need to point fingers. If you had to sit there and check people's fingerprints all day you might spark up a bowl and get tempted by gummi bears once in a while too.

Re:All good until someone simulates biometrics...

[Anonymous Coward]

Exactly, google and yahoo web services will no longer ask for your real name... they will already know it by cross referencing your biometric password to a government database of biometric ID's.

Re:All good until someone simulates biometrics...

[donaldm]

You can change a password, you can't change your retina print. What do you do when your account is compromised? Get new eyes?

Instead of all this BS, just make an app that stores all the sub-passwords from a master password.

There are plenty of apps that allow you to store your passwords in a database. Do a lookup on "password manager" and you should get over 250,000,000 hits. The problem is that you need to make sure that the passwords you use are not trivial and should be preferably over 8 alpha-numeric characters in length as well as having at least one special character (ie. !,@$# ... etc). A password generator is actually very good for this however the more complex a password the more you need to rely on a password database or at least the sites you are connecting to being able to save your password such as in your browser.

The biggest problem I have faced is the arbitrary password rules. Some sites require you have to choose from .\$[] character set whereas others cannot have it in the password. Some have length limits and some minimums. Some require at least two alphanumeric characters. Some allow phrases some don't.

That is not really a problem if you generate appropriate passwords and have a password manager.

Of course at some stage you really must remember at least one or two passwords. One to log you into your PC, Workstation, Mainframe etc and the other to access your password database if you have one. Oh yes you also have to have a contingency plan in case you are compromised such as knowing who to contact and it does not hurt knowing how to restore your data as well, assuming you do backups.

Re:All good until someone simulates biometrics...

[BenJeremy]

I had a cancerous tumor on my retina.

After treatment, which included radiation (Chip sewn on the lower back part of my eyeball for a week) and lasers, along with the ongoing process of the optic nerve dying from the radiation exposure, I suspect my retina is quite different, and still changing, from 4 years ago when the tumor was treated.

Retinal patterns DO change some times. It's rare, but it happens.

Re:All good until someone simulates biometrics...

[Anonymous Coward]

Have a backup method of authentication.

Around 2009, I once interviewed at a place that was proud of their security. They had fingerprint and retina scanners, and actually stated to me that they had a 100% secure server room against physical intrusion. In fact, the hiring guy talked about his security in absolutes, where he kept saying that nobody could ever get in, physically or remotely, even if they were a well-heeled state agency.

The problem is that they had backup mechanical keylocks that were about the grade of what is on a crappy door. Not even Best SFIC locks (which are the de facto standard in US buildings and are very common... but very difficult to pick due to the curvy-wurvy keyway and two shear lines.) I told them that a meth-head with a bump key could bounce virtually all their server room doors open, completely undetectable, and incredibly fast. A proper balaclava on the pate, and the lone CCTV watching the entrance would be useless (it already was pretty useless since its resolution was so low).

Needless to say, I didn't get the job because I questioned their basic security concepts (there were a lot of security issues, so many that I decided I wouldn't want to work there because it was only a matter of time before their place got taken over by a remote attacker group). The hiring guy hated me so much (since apparently it was his design for the doors), even though I was the only candidate, he actually deleted and made a new job req so he didn't have to hire on that one. Needless to say, when I looked the company up, they are long gone as of today.

As for biometrics, it is only sensible to have another recovery method. My iPhone has a fingerprint scanner... but it has a nice long passphrase. However, the point of my long diatribe -- make sure the backup security is as good as the biometrics. For the doors, I'd use Medeco for SFIC, or go LFIC just for the server room and use Abloy PROTEC2 cylinders (which take even the speedpickers 10+ hours to open.) Of course, a proper CCTV system in place is good too.

Re:All good until someone simulates biometrics...

[mlts]

You hit the nail on the head.

Biometrics are useful, but what about just going with a tried and true PIV/CAC token?

I have always used authentication tokens. (Preferably, multiple tokens for redundancy.) For example, I have several Aladdin eTokens. They are set with a fairly short (16 character) user passphrase, and an obnoxiously long (but memorable) admin passphrase. Both passphrases will permanently lock if more than a certain number of bad attempts are done.

These days, I wish there were a way to make an application that runs on a SIM card, similar to the ISIS e-Wallet system [1]. That way, decryption of keys could be done on the SIM (with the app having its own PIN/password), and it would have the same security as my old eTokens, except without the hassle of trying to find the PKCS#11 drivers.

This would also allow for client certificates. They are unwieldy because they have to be copied to where one is browsing... but they take care of the authentication problem with ease. An intruder who hacks a Web server will get a list of certificates in use... which might show who may be using the server, but for any other use, would be worthless.

If DARPA wants better password authentication, there can be two things done. One, we have a quite open mechanism in place -- TKIP, which is used by the Google Authenticator, Amazon, and many other places. The second would be DARPA/DoD to agree on some type of PIV/CAC spec, perhaps having a way to have cards be read by USB ports without a dedicated reader, or somehow get more vendors (Apple specifically) to embed a smartcard reader in their computers. Then, sell the smartcards.

Done right, this would make life fairly easy, since a user just puts their card in a reader, types their PIN (perhaps it gets typed in on a different keyboard, or a light comes on the normal keyboard showing that the BIOS is reading it, nothing else.) Then from there, authentication almost anywhere is automatic, or a dialog pops up confirming/denying use of the key.

[1]: No relation to ISIS/ISIL, except a bad name choice in retrospect.

Re:All good until someone simulates biometrics...

[geekoid]

Do not verify password with remaining eye.

Joking aside, I suspect DARPA is aware of those issues and taking them into account.

" Finger print scanners are fooled by gummy bears."
Some.

Re:All good until someone simulates biometrics...

[nine-times]

And this is really why we don't need biometrics, but should be using password-protected public key signing instead. Not only can you change your password, but if you can set up a CA (or trust someone else to do it), then you can revoke your key if it somehow gets compromised.

Re:All good until someone simulates biometrics...

[cornjones]

I thought the answer to this was to use the biometric indirectly. I would like a key fob (or app) that I would authenticate to biometrically (or other) that would then be my magic key to the what ever I am entitled to. I would sign up my fob to any service I needed to auth to, say work, subway, etc. If the fob is ever compromised, I can disable it and issue a new one. Possibly even move auto move my old services to my new fob.

Ideally, we would have different levels of auth needed. To enter my work, I would just wave the fob (or the door would realize it as I near). To access money, I would give it my thumbprint. To transfer my house title, i would have a few more factors required.

Re:All good until someone simulates biometrics...

[Bill, Shooter of Bul]

Yes, I remeber that. The cartoon where Bears drank magic potions in order to get high. Great programming that was.

Re:All good until someone simulates biometrics...

[schlachter]

gummy bears are very sneaky. don't let them anywhere near your biometric sensors. they will hijack your identity.

Re:All good until someone simulates biometrics...

[schlachter]

It should be biometrics plus some passwords/pins. Any of these systems should be multifaceted.

Re:All good until someone simulates biometrics...

[Eravnrekaree]

Its pretty obvious that this idea is a scam being foisted on an easily duped public and hear the word biometric and instantly have this image of something that will keep them safe, which of course, is completely delusional. We know that such biometric data would be easily stolen and used by criminals, and since you cannot change it, like you can an encryption key or password, you are screwed for life. Numerical keys work well for authentication and it makes sense to randomly generate these sort of things for your own use, which gives people control over these things. You have two kinds of people who think that biometrics is a good idea, you have the low information masses who don't know what the hell they are talking about, and you have the evil people who are up to no good and know that this has nothing to do with peoples well being, and are pushing this because they actually want to deprive people of privacy, and they know biometrics would help with an invasion of privacy, they know full well that biometrics are simply a horrible means of online authentication but thats not what they want. Their trick is to make the idiots out there think that it would be good for them, but the people are pushing for this knowing its not good for people, they push it because they basically hate people and want more power for themselves.

Something like OpenID is the answer, gives people complete control and is an open platform.

Re:All good until someone simulates biometrics...

[grantspassalan]

All security, long before computers came along has always been based on either something you know, such as a password, or something you have, such as a key. That is not likely to change. Biometric security is based on something you have. In most instances is impossible to change if such security is somehow compromised. If the stakes are high enough, the rubber hose decryption method or its equivalents will work for either one.

Re:All good until someone simulates biometrics...

[mellon]

That's great, except that it's still the case that the interpretation of the biometrics happens at the source, not at the validation point, so it winds up just being bits, which can be trivially faked and are probably very predictable.

Re:All good until someone simulates biometrics...

[vettemph]

...And have fun remaining anonymous when your "password" gives away your identity.

Re:All good until someone simulates biometrics...

[mrxak]

With physical keys, a lot of people forget about securing their keys. They leave them out where they can be photographed, for example, or quickly imprinted, or even just compared to another key with all the bite codes on it so the numbers can be noted.

Same goes for locks. A lot of people don't secure their locks, either, which leaves an attacker plenty of opportunity to bypass. Even an area with security which will detect an attempt to pick a lock or force it open, is still vulnerable. You see a guy go up to a door, stick a key in the lock like he belongs there, then suddenly he "forgets" something and walks away without opening the door. You might not think twice about it in a busy office building, but that guy just got pin imprints and will be back every day to do the same thing again, or send in somebody else, until one day an attacker walks up with a manufactured key that opens the lock and goes right in.

"Something you have" like physical keys aren't that great if you don't secure them. You need to make sure that the only people who have that something are authorized to have it, and you need to restrict hardware access to the lock. It's a tricky proposition in the best of cases. Biometrics are even worse than most cases, because at least a lock on an office door can be changed if a key is lost. You can't change your biometrics. Furthermore, we're talking about digital systems here, when biometrics are inherently analog. Your analog finger, eye, or whatever is being taken in as a precise yet inaccurate digital signal, some probability function is determining if you're "close enough", and then a computer chip says you're okay. It's like having a lock where if you jiggle different keys in it, the tumbler will still turn. To put it in computer terms, it's like taking a float in as input, truncating the decimal, and using it as an integer in your finely-tuned algorithm. There's all kinds of floats out there that will get you the integer you need to make your algorithm work the way you want it to. It's no longer "something you have", it's "something that's kinda like what you have".

"Something you know" like a combination or a password, has always been more secure. It uses math instead of the physical world and its inherent weaknesses. There's too many combinations to reasonably guess it in the amount of time you have, and you're forced to exploit some vulnerability in the locking mechanism to get in, like using a blow torch to melt the locking bolt, or exploit some vulnerability in the user of the lock, like he was stupid and used his birthdate as the combination, or wrote it down. Passwords, and combinations, are digital, instead of analog, which means there's exactly one password or combination that will work, instead of an infinite number of "close enoughs".

You still need security with your lock and key, whether your key is something you know or something you have, but at least with digital, changeable keys, you have the power of discrete math on your side, and if you do lose lock or key security, you can go ahead and change your key.

And if I've piqued anyone's interest in security of physical locks and physical keys, I highly recommend the books by pen-tester Deviant Ollam, specifically Keys to the Kingdom which covers a number of attacks most people never consider when they're securing their offices, server rooms, etc. Practical Lock Picking is good too, if you want to learn how locks are defeated by, surprise, picking them (bumping, shimming, and bypassing too).

Re:All good until someone simulates biometrics...

[ewibble]

The problem with this scheme is that if your computer is compromised, then an attacker can access all your passwords once you enter the decryption key. I don't think biometrics can actually decrypt stuff though since each scan is slightly different.

I think the best way is to have a hardware key (e.g. usb stick) that does a challenge response, with public/private keys, that never actually gives out the key to anyone, not even the computer you are on. In order to activate it you need to do something physical on that stick, e.g. press a button, or scan a finger print if you want for added security.

You can easily change your password, get a new key. (you could just make the device have a write only private key but you would have to be careful that a virus can't write a known key to the device)
You can give out your public key to multiple servers and know that they are not doing something stupid/bad with it. How do you know that people are not storing your password in clear text on the database?
You can have multiple keys, for different security levels, or simply because you don't want to be tracked.
Some could still steal the key but that is a physical act, and you would most likely eventually notice.

Re:All good until someone simulates biometrics...

[AK Marc]

Biometrics are rarely even good. They are a 3-7 byte key based on a hash of something. Any more, and the repeatability starts to fail. So if you "hack" the system to be able to key in the keys directly, rather than going through the scanning hardware, you have a very good chance of guessing a "password".

Re:All good until someone simulates biometrics...

[AK Marc]

Biometrics, plus a card, plus a PIN would be great. Only have to remember to keep your token on you, and a short numerical string. That's still better/easier than hard passwords for everything.

Re:All good until someone simulates biometrics...

[schlachter]

Yeah, I think this is a common approach; plus multiple layers of security authorization; building; room; machine access; data

Ultimately...

[Anonymous Coward]

Ultimately whatever password replacement you come up with gets turned into TCPIP packets over the intertubes. Whether you are measuring my height, fingerprint, penis size or whatever metric you come up with, it gets turned into 0's and 1's that I can grab and duplicate. It is still information on a remote server than can be hacked and used by third parties.

And worse... once hacked, I can't do much to change my biometrics... so I'm totally screwed once the host server is hacked and a million biometric accounts are compromised.

Re:Ultimately...

[Anonymous Coward]

Ah, but you're assuming they won't invent a "don't save this" bit, which would prevent all systems handling such information from ever saving it...

Just look at the success of the evil bit and do-not-copy bit... :-)

Re:Ultimately...

[DigiShaman]

Mushroom stamping the scanner. Now that's new concept I haven't heard of before.

Keep it classy.

Re:Ultimately...

[pixelpusher220]

small comfort, but people whose biometrics are hacked would be the perfect cyber criminals no? I mean, you can't tie those bio-metrics to just 'them' anymore right?

excuse me, I need to go take a red pill...

Re:Ultimately...

[digitig]

Whether you are measuring my height, fingerprint, penis size or whatever metric you come up with

Penis size is pretty useless as a biometric. It changes depending on the site being accessed.

Re:Ultimately...

[LordLimecat]

Or you use some common sense, and use transport encryption.

Re:Ultimately...

[daid303]

Whether you are measuring my height, fingerprint, penis size or whatever metric you come up with

Penis size is pretty useless as a biometric. It changes depending on the site being accessed.

So, that's perfect, password per site, and hard to fake.

Re:Ultimately...

[disposable60]

But easy to lose as you become jaded.

Re:Ultimately...

[David_W]

Penis size is pretty useless as a biometric. It changes depending on the site being accessed.

Doubly so on this one, where everyone claims theirs is a foot long.

Re:Ultimately...

[digitig]

Many women are able to borrow a friend's whenever they want to.

Re:Ultimately...

[hoggoth]

You don't measure your penis size, you use a challenge-response system that measures your penis size IN RELATION to a specific photograph!

Re:Ultimately...

[hoggoth]

Insert penis into scanner.
Error, insufficient data, biometric password must be at least 3 inches.

presumably so...

[Anonymous Coward]

...when the NSA wants to tap into various accounts, they can track exactly who they belong to and who accesses them because it will be linked to your personally identifiable biometrics

Re:presumably so...

[Somebody Is Using My]

Also, the various government agencies are increasingly working on gathering and archiving the biometric data of everyone they can. Right now they can collect fingerprints or DNA if you are arrested (and often this information is not purged if you are not convicted); I wouldn't be too surprised if they soon start gathering retina patterns as well. If devices start requiring biometric data over passwords, then the government (and any of their partners, or their employees or anyone who has hacked the database) will have access to anything secured by that data too.

The government can probably get my password too, but at least I can change the password every now and then to make things harder for them. Swapping out my eyeballs doesn't seem as appealing.

Re:presumably so...

[grantspassalan]

There is nothing you could have that the government can’t get, if they really wanted. They don’t need the password to your bank account because they can order the bank to freeze your account or even confiscate your money. If they come to your house, they can take anything they want. If you have a deep dark secret only stored in your brain they are after, they can throw you in prison and/or torture you.

I can't change my fingerprint

[Ubi_NL]

I can change my password anytime if I think somebody copied it. I cannot change my fingerprint or retina. There is no way I'm giving random webshops or google my biometric data.

Re:I can't change my fingerprint

[Anonymous Coward]

I cannot change my fingerprint or retina.

Sounds like a DRM issue. You should complain to somebody!

Re:I can't change my fingerprint

[Another, completely]

It's more likely that your biometric would just unlock a stick that you carry around with you. The stick would then use an internally-generated key to authenticate you to the remote site.

Re:I can't change my fingerprint

[gregorio]

Note that I am not a security researcher and have no idea if what I just said is pure BS or not. However I would hope that people who ARE security researchers have already thought about these aspects.

No, it is not possible to "hash a retina scan", because just like fingerprint scans, the matching process for retina scans is based on feature comparisons. One can say that a retinal feature table is "a kind of a hash", but I disagree: it is quite easy to generate an artificial retina "clone" image from a list of features, just like it is easy to create a fake fingerprint from a list of fingerprint minutiae.

But database hackings are not the big issue here. If fingerprint or retina readers ever go maistream, you'll be simply sharing your password everywhere, from the gym to your job's access system.

Re:I can't change my fingerprint

[bombman]

Can I have a glass of formaldehyde and eyeballs next to my computer i can use if i want to change my password?

Re:I can't change my fingerprint

[mdmkolbe]

Hashing may prevent Yahoo from breaking into your Google account, but it doesn't help if someone acquires the pre-hash data (e.g. by lifting your fingerprint). The problem noted by the GP still stands.

Granted, random websites are less likely to be able to lift your fingerprint, but coworkers, roommates, and cashiers could do that pretty easily. When Mythbusters tested fingerprint scanners, even though Grant was on alert that they would try to steal his fingerprint, Kari got them by asking him to copy a stack of CDs.

Re:I can't change my fingerprint

[sociocapitalist]

I can change my password anytime if I think somebody copied it. I cannot change my fingerprint or retina. There is no way I'm giving random webshops or google my biometric data.

You'll probably end up giving it to the US government if you go through customs. If not now then whenever Patriot Act III passes.

Re:I can't change my fingerprint

[AK Marc]

That's why it's nice having a US passport. I don't have to get recorded if I visit/transit.

Re:I can't change my fingerprint

[sociocapitalist]

That's why it's nice having a US passport. I don't have to get recorded if I visit/transit.

For now.

Also, having a US passport won't stop other countries (ie the UK) from taking your biometrics when you cross their borders and then sharing it with the US government.

Re:I can't change my fingerprint

[AK Marc]

Hm, haven't traveled through the UK. But I don't see anything to indicate that they take anything biometric upon entering. I'm due to go there next month, so I'll see what happens then.

Re:I can't change my fingerprint

[sociocapitalist]

Hm, haven't traveled through the UK. But I don't see anything to indicate that they take anything biometric upon entering. I'm due to go there next month, so I'll see what happens then.

Okay but do you see my point? It's only a matter of time before some border agency somewhere collects your biometrics. Given that western spy agencies seem to be coordinating efforts (to get around constitutional protections for example), I think it's only a matter of time before the US has your data along with everyone else's.

Re:I can't change my fingerprint

[AK Marc]

I don't see your point. They publicize the collection before they start, and those areas can be avoided. I'm not trying to avoid the collection of my information tinfoil-hat style, I've already given it to the government willingly twice. I'm just pointing out that you are wrong. Nobody is currently, or proposing to do what you say, and those with a US passport are exempt from the lines of collection in the US.

You are FUDing things which haven't happened. That makes it seem like you are OK with everything else, as if you weren't, you'd have something "real" to complain about.

Re:I can't change my fingerprint

[sociocapitalist]

I don't see your point. They publicize the collection before they start, and those areas can be avoided. I'm not trying to avoid the collection of my information tinfoil-hat style, I've already given it to the government willingly twice. I'm just pointing out that you are wrong. Nobody is currently, or proposing to do what you say, and those with a US passport are exempt from the lines of collection in the US.

You are FUDing things which haven't happened. That makes it seem like you are OK with everything else, as if you weren't, you'd have something "real" to complain about.

I see - I must have confused your post with another. I thought you were trying to avoid having your metrics taken by anyone, including the Government, as they could subsequently be (mis)used / lost / whatever and could not be changed / reset.

If you've given them willingly then yes, we're on a different thread altogether.

First off, I'm not complaining about anything. I'm saying things as I see them. What I see is that governments collect biometric information at their borders and that, separately, countries tend to share private information with other countries including the countries of the citizens involved. Combining the two it does not seem unlikely that a country that takes someone's biometric information might share it with that person's own country.

Whatever -

As long as certain rules are kept

[Thanshin]

I'm ready to switch passwords for anything else as long as:
1 - It can't be extracted from me by an easier method than torture or blackmail.
2 - It stops working forever if I'm dead.

Otherwise, some blood will have to wash away the naivete. Again.

Re:As long as certain rules are kept

[LWATCDR]

"2 - It stops working forever if I'm dead."
That is what I am worried about. I would like my wife to have access to my online accounts if for no other reason than to say good bye for me.

Re:As long as certain rules are kept

[Sobrique]

Most biometrics do stop working when you die. Retinal prints change if there's no blood flow - the 'eyeball-on-a-pencil' just doesn't work. Other methods ... well, generally you can detect a pulse, and the change in pattern from the blood pressure is more secure anyway. (Even before you decide you don't want to let zombies^Wresidual human resources in.)

Re:As long as certain rules are kept

[FridayBob]

I'm ready to switch passwords for anything else as long as:
1 - It can't be extracted from me by an easier method than torture or blackmail.
2 - It stops working forever if I'm dead.

Agreed. Other authentication factors can be taken from you without much difficulty, but password access requires actual conscious cooperation.

On the other hand, I know where they're coming from. For the last five years I've been working on getting as many network services as possible to work with Kerberos authentication. So far, I've got OpenLDAP, OpenAFS, Netatalk (AFP), NFS, OpenSSH, Exim (SMTP), Dovecot (IMAP) and Apache (HTTP) to work with it, which has eliminated a lot of password use, as well as improved security. It would be fun to add MFA to the equation, but I'd still prefer to somehow remain consciously involved in the authentication process. Finally, people may hate having to remember new passwords all the time, although they get used to it, but the fact that they are so easy to change is also an advantage.

Re:As long as certain rules are kept

[jsepeta]

well if you're looking for a biometric that stops working when you're dead, then a penis size based reader would be the perfect choice.

Re:As long as certain rules are kept

[judoguy]

Good point. I'm at an age where my friends are dying every year or so. As someone who has had to "close up shop" for some of them, it's a royal bitch to do when their online life can't be accessed. Stopping the mail, shutting down the online business, etc.

"Oh, they should have prepared for that in advance, as soon as they knew they were going to die". Yeah, well, perhaps in some fantasy world. No, the survivors clean up in real life.

Re:As long as certain rules are kept

[hoggoth]

Never heard of 'rigor mortis'?

Re:As long as certain rules are kept

[AK Marc]

Yeah, that's when the muscles tighten up. There are no muscles in that organ.

Re:As long as certain rules are kept

[hoggoth]

http://en.wikipedia.org/wiki/D...

Re:As long as certain rules are kept

[AK Marc]

Only happens as part of specific death methods. And unrelated to rigor.

Re:Passwords died in the 80s

[szmccauley]

In the 80s we didn't even bother with passwords, okay maybe by the late 80s. And every machine on the network had an IP that was directly on teh internets. As for this article, it's yet another example of how stupid people, even the intelligent, are when it comes to passwords. Who the fsck writes down a dizzying array of passwords? I know about 5 passwords off by heart at any given time, and use a password manager and an encrypted database to hold all of my passwords. Of course, without 2-factor auth those lists of passwords are seriously dangerous and that, dear humans, is where the danger lies. If anyone manages to crack my passowrd manager or my encrypted database, I'm fscked. Okay, let's hear what the folks have to say about this age old problem.

Re:Biometrics are great until...

[martin-boundary]

Please choose biometrics that aren't part of my extremities.

Who do you think you are, a civilian? A citizen accepts personal responsibility for the safety of the body politic, defending it with his life, a civilian does not. What's a few extremities in the war against computer bugs?

Passwords don't need to be killed

[nine-times]

Passwords don't need to be killed. If you're thinking about replacing it with biometrics, I think that's thinking about the problem the wrong way too. The fact is, we already have all the technology we need to solve this problem much better than we do today. It's simple: instead of passwords, you should have a password protected private key, with a single password, and then use public keys for authentication. That way, you only need to know one password, and you've also eliminated a lot of the danger of snooping on connections because the private key isn't being sent.

Of course, it would require that everyone pretty much agree on one set of standards for how it's supposed to be implemented, and than developers have to build their products with those standards. Then you probably also want some trustworthy and inexpensive/free Certificate Authorities. Ideally you'd want to be able, though not required, to use the same private key for everything-- email encryption, ssh logins, maybe even credit card purchases-- so you'd need mechanisms for managing your keys, keeping them safe but also making them available when needed. Throw in some dual-factor authentication where you want a high level of security, and you've basically solved the issue.

Re: Passwords don't need to be killed

[Anonymous Coward]

I personally think this is the best idea on here. Especially with two step.

Re:Passwords don't need to be killed

[ZorroXXX]

Actually, a solution very similar to what you describe are currently beeing developed as SQRL - Secure Quick Reliable Login. The main highlights and uniqeness of this is:

• There is no trusted third party. There is the only a) the user and b) the website (and also notice that each website will receive different identities, so no cross site spying).
• The creator, Steve Gibson, is doing this just because it is a good security solution and have no other interests. He has a long track record of being an security expert, starting the podcast Security Now! in 2005, currently up to 467 episodes.

Re:Passwords don't need to be killed

[Anonymous Coward]

While I mostly agree with you, I think the main issue that's prevented public key auth from being popular is that the "making them available when needed" part is hard. Specifically, being able to use your accounts on another computer. Smartphones might be able to solve this problem though; both by reducing the need to use computers that you don't own and by being a portable key store that could somehow be used as part of the login process.

Re:Passwords don't need to be killed

[tom229]

I was going to post this but you beat me to it. I already use this method, somewhat, for anything that supports 2-factor auth. Weak and/or easy to remember password accompanied by a code generated from my private key.

Anyone looking to change the paradigm needs to remember there's only 3 ways to secure things: something you know, something you are, and something you have. With that in mind what you've suggested is the most user friendly and secure way to go about it.

The only other suggestion I would have is a paradigm shift to passphrases instead of short passwords. But I can hardly take credit for that idea.

Re:Passwords don't need to be killed

[SpaghettiPattern]

First decent reaction I see here on /.

Open hardware key where a private key is held and which cannot be extracted (yes, that is possible.) Access to hardware through small keyboard, requiring a PIN/password. Open protocol to challenge private key. Everything is already available. Openness is the key and I think DARPA could apply strong influence in making this possible.

Re:Passwords don't need to be killed

[diamondmagic]

Minor problem: What if the master key is compromised? What if you want to change the identity you want to present to a website - just one website? You're screwed, and out of luck (respectively).

The proposal also assumes that the authority component of the URI (the hostname, usually) is the party you want to identify to - it doesn't.

It's not good enough for Web standards to work for 95% or 99% of people - they have to work for everyone, hence all of the back-and-forth of the standards development process.

I would point out WebID doesn't have these shortcomings.

Re:Passwords don't need to be killed

[nine-times]

Of course, if you can plug that hardware key into your phone somehow, then you can add biometrics, SMS confirmations, or other factors for authentication if you want. Plus, you get your keyboard right there. Plus you can have it communicate with computers via bluetooth without worrying about an extra battery to keep track of. Plus... all kinds of things.

I think I've come around to the idea that smartphones are the right place to put this authentication. It's a device pretty much everyone carries around with them anyway. If you want it to be an unextractable hardware key, then you'd need some kind of swappable chip-- maybe modify the design of SIM cards? There would be a lot of ways to do this, but I think it'd be silly to ignore the fact that most people are carrying around little handheld computers with screens and keyboards and wireless communication already.

Re: Passwords don't need to be killed

[SpaghettiPattern]

The device almost by definition must be autonomous. You wouldn't want your phone to setup a session which attackers could misuse. I'd be fine with using a key like my bank uses whereby the application sends me a challenge which the device encodes and which the application recognises as such.

DARPA wants for fail at this also?

[gweihir]

As many, may other have before, because this problem is not really solvable without AU that can recognize a person? Well, it is a waste of taxpayer money, and fail they will. Biometrics is basically unusable unless you have a security guard monitor the taking of the measurement.

Won't work

[DaMattster]

You can kill the password in favor of strong security tokens but if the underlying code is poorly written and full of security holes, then it won't be any more secure than what we have now. If you can steal a few retinal images through an exploit, you could, in theory, make a model with the retinal pattern.

Leave the choice to the user

[NotInHere]

Now thats something innovative DARPA could do: I don't want biometrics, but perhaps someone else might like it, as they don't care much for computers, and would have used a 12345qwert like password.

Come on, most of these authentication methods are inferior, I just don't have the abilities I have with passwords: evil people have to beat me with a stick until they know my password instead of just having to cut off my finger, I can change it whenever I want, a password doesn't identify me (I can stay anon), I can give it to someone else, and when I am eating (drinking, got my finger cut off because someone wanted to break into another computer of mine) something I can enter the password with my other hand, without changing the way my hand tremors.

Standards Conflict

[timrod]

There's no way I can see this happening, if only because no one would be willing to settle on a single standard for biometric verification. For instance, I can imagine that some places will want a simple fingerprint.. but others will demand that the fingerprint scanner used by the user to submit their prints detect warmth so that they can be sure that there's no artificial prints, dead bodies, or severed extremities being used to bypass the scan.

Other places will want retinal scans (One eye? Both eyes? Proof of life verification?), voiceprints, voiceprints backed by facial recognition, or any number of other things. In the end, it would lead to the end-user being forced to buy lots of expensive hardware, some of which they may never wind up using. The other thing they don't consider - what about mobile devices that don't have multiple USB ports, or can't support the drivers for biometric scanners?

Passwords can work, but human-readable ones do not. What we need are more secure passwords that aren't human-readable, not Minority Report.

PKI SSL

[Sobrique]

We're used to using SSL from client to server. But it works both ways around. You can use client side SSL certificates to authenticate. Client side SSL certificates that you can lock down with a decent passphrase, SSLVerifyClient

Not as hard to implement as some of the pipe dreams out there. Of course, it does require a degree of tech savvy on the part of users - and more importantly, enforcing it's use, to avoid laziness bypassing.

Then your challenge becomes certificate transport - you'll need a way to carry around your cert, or somehow get hold of it when you need it, which is easier said than done. The real advantage of passwords is their portability. Biometrics have a similar advantage, but as already noted - are a bit harder to revoke/change.

Re:PKI SSL

[fuzzyfuzzyfungus]

It's pretty tricky to avoid the 'carry something around' requirement; but people seem to be good enough at that when they need to be.

I suppose the major mess would be all the phones and tablets that either don't have card readers or USB, or have USB but will never receive driver support outside of third party hacks. Smartcards and their USB attached analogs can handle the job but having accounts that you can't access from almost any mobile device will probably play poorly.

So...revoke the certificate

[Overzeetop]

Any biometric password should be based on a certificate, not a direct digital representation of the biometric.

Re:So...revoke the certificate

[Anonymous Coward]

Yep, certificates are the answer. Heck you could generate your own self signed certificate, as long as the server stores the public key or the fingerprint, its as good as any other login/password combination for proving you are whomever created that combination in the first place. Now if you needed absolute identity (which for the majority of websites you don't want), you'd need a central authority to verify it. Large banks could provide this service possibly.

Re:So...revoke the certificate

[Graydyn Young]

This is correct. Take a look at what these guys are doing with biometrics:

getnymi.com

They aren't sending your biometric data all over the internet. They verify your identity on device and then send a token around.

Re:So...revoke the certificate

[Overzeetop]

As a professional engineer, I have to certify the designs I send out were created by me. In the past, a rubber stamp and an ink signature were used (still are in many places), but I sign everything digitally. I've created and posted a public key hosted on my web server which has been sufficient for 99.9% of clients to date - all but 2. One client required a know authority to hold the certificate, but wasn't willing to pay for it, so we "compromised" and I hand signed the sheets. The other client simply wouldn't accept digital signatures.

FIDO / U2F - open Yubikey-like standard protocol

[Lennie]

How about a standard protocol around devices like Yubikey hardware tokens for integration in the browser (or use with other applications):

https://air.mozilla.org/fido-u...

Google, Microsoft are already involved, Mozilla is looking into it.

666

[musmax]

And he causes all, the small and the great, and the rich and the poor, and the free men and the slaves, to be given a mark on their right hand or on their forehead, and he provides that no one will be able to buy or to sell, except the one who has the mark, either the name of the beast or the number of his name. Rev 13:17

Re:666

[fuzzyfuzzyfungus]

You crazy end-times nutjobs... Everyone knows that Verichip(tm) brand subdermal RFID solutions are supposed to be implanted in the arm, not the hand or forehead!

Re:666

[PPH]

Damn you! That's the combination to my briefcase.

Re:666

[PPH]

Yeah. But in this case, they have a good point. Whoever controls your access token controls your life (soul).

Even if you don't believe in God, the Bible was used to teach practical knowledge to the people back in its day. There is some common sense wisdom in there if you can get around the concept of an invisible guy in the sky.

Re:666

[Eosi]

Interesting View. I think the "common sense" teachings have gone by the wayside of late. That or people are much more hypocritical than in the past. Just my two cents.

Noone has to remember passwords any more

[biodata]

Don't people just click on the 'Forgot Password' button every time their browser forgets their password?

Re:Noone has to remember passwords any more

[biodata]

According to wiktionary, UK users of English prefer no one to noone by a factor of 12:1, so quite a large number of people are happy with noone. I agree with you that 'No none' is two words with a space between them, and that noone would say nonone :)

Re:Noone has to remember passwords any more

[fnj]

Maybe because "noone" is NOT A FUCKING WORD and tags the user as illiterate.

Re:Biometrics are great until...

[king neckbeard]

Be careful what you wish for, or they'll use internal organs (which are by definition not extremities), and you don't want anybody cutting those out.

Re:Biometrics are great until...

[ketomax]

Are you okay with your barber charging you for the time spent in fighting your spam.

Biometrics? Over Internet?

[bradgoodman]

I concur with the previous post saying you "can't change" biometric stuff if your password is "compromised" - but my further point is that biometrics are "secure" in an "embedded" world when you have a physical scanner attached to a physical device. When you're on the "open internet" - and such biometric data has to be collected and shuttled accross "the 'net" - you now have the same sort of issue as with "traditional" passwords - i.e. someone snarfing and/or "replying" that data.

So whereas biometrics might replace a traditional "password" - we need more systems which aren't vulnerable to the type of 1.8-billion-password-stealing-Russian-problems we see all over the place. I have been a big fan of much of the two-factor stuff, and some of the hashing schemes out there. It will be interesting to see what kind of other solutions could exist - though I don't think anything "static" like biometrics gets us anywhere.

Something you know...

[Doub]

If instead of switching from one factor to another they promoted multi-factor authentication, they'd relax constraints on each factor (ie. passwords easier to remember, biometrics cheap to implement).

Eyeball Frying Fun

[userw014]

Using biometrics as an authentication factor (with or without passwords or token generators) brings me to:

[1] Can the biometric be consistent across different vendors or models of readers - or will people be locked-in to individual vendors (or worse, models) of readers?

[2] Is the interface between the biometric reader and the computer secure?

[3] How stable are biometrics over time - both long term and short term?

[4] What happens when the same biometric is used in different security contexts - from banking to dating sites?

I doubt that these are new questions, but other than the stability of biometrics over time, I don't recall seeing them asked before.

Re:Eyeball Frying Fun

[dbIII]

As for 3, maybe it's an early warning of high blood pressure when your retina scan doesn't work any more, or prostate trouble when fingerprints go.
They can take my biometrics from my cold, dead hands. Passwords/passphrases are a different story.

The problem is false negative

[Geoffrey.landis]

What happens if you get sick or injured? Can you imagine pink eye with retinal scanners?

Yes, this is the serious problem-- just as serious as the problem of people fooling the password-alternative is the problem of the false negatives: getting locked out.

Notice that most of these weren't fingerprint scanners or retinal scanners-- they were stuff like gait monitors, or even more bizarre stuff, like listening to your heartbeat. So, if you twist your ankle--or even buy a new pair of shoes-- you're out of luck. Taking pseudoephedrine for a cold? Ooops, your heartrate is different. You're locked out.

--instead of using these instead of password, however, what about if you use alternate ID as a second check. It doesn't lock you out, but it does trigger a watchdog alert that pays attention to what you're doing.

You can change a password, you can't change your retina print. What do you do when your account is compromised? Get new eyes?

Yes, we've all seen dozens of those science fiction stories where they steal people's eyes, or cut off their fingers, or take swabs of their DNA.

Re:The problem is false negative

[geekoid]

"Yes, we've all seen dozens of those science fiction stories where they steal people's eyes, or cut off their fingers, or take swabs of their DNA."
cute, but not what the poster is talking about.

Your info, weather its a password, or the bio-metric info will get turned into a string and stored in a database.
Once that database in compromised, your bio-metric info on EVERY system you log into needs to be change to a different bio metric. They don't actually need to physical eye.

Re:The problem is false negative

[mpe]

Notice that most of these weren't fingerprint scanners or retinal scanners-- they were stuff like gait monitors, or even more bizarre stuff, like listening to your heartbeat. So, if you twist your ankle--or even buy a new pair of shoes-- you're out of luck.

Other clothing changes could affect gait. As could anything else you are carrying both in pockets or in your hands.

Taking pseudoephedrine for a cold? Ooops, your heartrate is different. You're locked out.

Plenty of other things can affect your heart rate, no drugs required.

Re:The problem is false negative

[Zeromous]

>Yes, we've all seen dozens of those science fiction stories where they steal people's eyes, or cut off their fingers, or take swabs of their DNA.

Well obviously it's time to two-factor that shit. We'll need a random series of characters meeting certain criteria, and we're good to go!

Re:The problem is false negative

[WuphonsReach]

If it gets stored as a hash of the values, and is salted properly with a random 32bit salt (unique per user), then even if a thief steals the database of hashes, they don't gain much. They can't use that hash to attack another system. There are ways to protect against replay attacks like this.

Biometrics (something you are) will never work on their own as a sole source of authentication, you're still going to have to have passwords (something you know) possibly combined with something you carry (something you have).

They should watch "Archer"...

[QilessQi]

Pam: Oh, OK, then good luck with all the biometric scanners. Unless you wanna cut off my fingers and scoop out my retinas.

Kidnappers look at each other.

Pam: Oh, don't be dicks!

What other tech gives a choice?

[RhettLivingston]

Passwords don't simply show your identity. Making the choice to enter them also shows your permission. Sure they can be snooped, but they can't be easily extracted against your will. All biometric based keys are available with a warrant. The password is the only one that I know of that I have any chance of hiding. By carefully employing different passwords for every site with the aid of KeePass or a similar tool and changing them all periodically (would be nice if KeePass automated this) and guarding KeePass with the strongest encryption, a very strong password, and another key, I've got a better chance of controlling access to my data (which I consider little different from my mind) than with any other approach I've heard of.

Re:What other tech gives a choice?

[mlts]

I've wondered about someone making a device, basically a classic, pre-smartphone, PDA that doesn't have any wireless connectivity. It would use a USB port and mount as a drive (with some device files for functionality, so the drive can be locked until the proper password entered by catting it to a file on there, similar to how some tuning is done with /proc.)

From there, an open source utility like KeePass could be used.

The device would use LUKS and encrypt everything but the kernel and the initial image to get it booting, then use a PIN from there on out with a timeout after too many attempts.

If one had to have cellular access, 3G chips are cheap, and passwords are relatively small. This would provide for backups (each device would have its own private key, so that when one wanted to access the cloud-stored backup with a new device, and old one would have to unlock and re-encrypt the backup, adding the new device's key.) It would also provide for remote erase capabilities [1].

[1]: Even just a TRIM on a SSD based device would prevent recovery unless someone could decap the NAND chips. A SSD that used encryption and had a secure erase feature that regenerated a new key... recovery would be impossible.

Bad idea

[mark-t]

Because accidents happen. No matter how improbable... no matter what kind of artificial barriers we might try and design to prevent them, over time even the unthinkable can and often will happen.

And when it does, some kind of mitigatory system needs to be in place, or else once the system has been compromised, nobody will ever want to use it again. In the case of biometrics, if a database of people's biometric "passwords" has been compromised, potentially allowing somebody to access whatever that database might be linked to, that mitigatory system is going to end up being the password until a different biometric system can be put in place.

Biometrics can make sense as an alternative to passwords in some contexts... such as on an internal and private network, where certain people who work there need regular access to particular information, while they do not want just anyone using the computers, and biometrics can measured by a computer much more quickly than a password can be entered, so it serves as a convenient shortcut. They don't, however, make sense as a general replacement for passwords. Honestly, I can't help but feel that the people who keep suggesting this are terminally lazy and don't want to have to remember passwords in the first place.

Re:Bad idea

[mark-t]

Obviously some effort should be taken to ensure that problems happen as infrequently as possible, but beyond a certain point there will be diminishing returns, because *EVERY* solution will have its share of potential problems when the completely unexpected happens, and the costs associated with such a situation are going to be there regardless of what you do. The important thing, therefore, is to have a system where the situation can be mitigated with the least cost.

The cost of changing a password is virtually nothing. The cost of changing biometrics can easily be infeasible.

Hoping for better solution

[Ogive17]

At work I have so many passwords with different requirements and different reset schedules that I had to turn to the low tech approach of writing every one down on a post it note and hiding it under my calculator on my desk. I do take my laptop home every evening.

Interesting enough, email is the only program we no longer have to sign in to each time, and it also does not time out after inactivity like every other program. That is the place where most sensitive business information would be located. All they would need to do is crack my windows password (while also knowing my login name).

I wish I could log in to windows and do one authentication to unlock every other program I use routinely.

of course they do

[jsepeta]

If DARPA doesn't like passwords, they shouldn't use them. But that shouldn't have any bearing on us puny civilians.

Re:of course they do

[fnj]

I think you can relax a little. Despite the hysteric headline, DARPA is no police agency, not even a standards agency. It's a research agency. Only good can come from them turning some of their high power brains toward the problem of authentication.

Re:of course they do

[messymerry]

Good for who? Them or us??? One of the keystones of freedom is the right to privacy. Why do you think the State so jealously guards it's privacy? The promise of transparency is a complete fraud and if you don't think DARPA will not send it's precious little authentication scheme straight to DHS, NSA, and all the rest of the TLAs, you are kidding yourself...

Re:Biometrics are great until...

[ekgringo]

The exact words of the text. But do you know what they really mean?

What about remote control?

[CaptainDork]

Biometrics is a great idea to ensure that people are in direct proximity of the device, but what about all the remote control I do?

No, sorry ...

[gstoddart]

The last thing we need is for our biometric information to be in the hands of every web site which requires a login.

It will kill anonymity, because you will be universally identified.

Sorry, DARPA, but we trust neither you nor private corporations with this kind of stuff.

A standardized interface for changing passwords

[Marrow]

Every single site has a different way of giving you a way to change your password. This makes it impossible to write programs to write programs to change your password....like a password manager for instance. Imagine if you could just type in your new password into your password manager program, and it changes all the passwords it manages with one click. They could all be randomly generated and different for every site. Hints, recovery, email addresses, could all be updated with one click. With a history as to the previous versions in case something went south.

Instead of struggling with writing all the captcha's, and strength meters, and interfaces, and all the CRAP that the every site on the planet does differently. Just standardize the interface and maintenance of passwords. And then standardize the strength of the generator programs. And voila, permanent security that is controlled where it should be: in your hands.

Passwords are anonymous

[koan]

I would feel better about the call to stop using them if it wasn't a government organization suggesting it.

SQRL

[bill_mcgonigle]

DARPA: send beer

nntp://news.grc.com/grc.sqrl/

Seven solutions, all bad.

[TranceThrust]

TFA actually speaks on seven ways passwords may be avoided, with biometrics being but one of them. All seven build on extracting unique identifiers from physique or behaviour. All seven are wrong because of one simple reason: if someone mimics whatever chosen identifier good enough (either by hacks or by actually mimicing me), how can I change my `password'? I can't. Trashcan.

Re:Passwords died in the 80s

[donaldm]

In the 80s we didn't even bother with passwords, okay maybe by the late 80s.

Err no! you are thinking of early PC's and their single tasking equivalents. Passwords to access multitasking computing systems have been around from at least the 1960's. The Unix OS was designed and enhanced with user names and appropriate passwords going back to at least the early 1970's.

Actually even today a good password is quite hard to break even with so called "man in the middle" attacks providing you are using something like ssh and possible one time passwords (I used this type of access back in the mid 1990's) to access machines.

In many ways as long as you have a good remembered password to access your PC you should only have to worry about your PC being compromised by Viruses, Trojans and social engineering attacks. As long as you are aware and know how to recover from an attack (most people don't) then you are pretty safe from mall-wear. Even if you are compromised then you should have some idea on who to contact such as Banks , Web site etc to report and hopefully resolve the issue.

Biometric is great until...

[daq man]

The DARPA verification method would have to use multiple biometric markers since you could always think of a situation where a medical condition renders one or more of them useless. The person with eye problems who can't use retina scan, the person with damaged fingertips who can't use fingerprint, the person with throat or respiratory disease who can't use voice recognition, etc.

It would be much simpler to have a universal two factor token. Something that you enter a PIN into which generates an encrypted token that is then used for login. It would also solve the social security number identity theft problem since you have a unique way of verifying identity.

Methods

[blue9steel]

There are only three ways to authenticate someone no matter what the context:

1) Something you know
2) Something you have
3) Something you are

Any security system is made up of some combination of the above.

Vote fraud, Medicaid fraud, etc

[tomhath]

Biometric identification is needed to reduce fraud. We all know how easy it is for one person to vote as many times as they want. There is no way to even estimate how much Medicaid recipient fraud costs. Biometrics certainly won't eliminate fraud in these and other places but it's a step in the right direction.

Unfortunately we're very unlikely to see any progress on this anytime soon. Even suggesting that a person should present identification when voting is met with howls of protest.

Job Function Accounts

[number17]

I have several accounts that are not tied to me but to my employment. Several people access these accounts using the one password. Do biometric systems allow for registering multiple people to one account?

Administration after the Death of the Password.

[lionchild]

So, if we kill the password, the foundation on which we have security built now, what does administration look like after that? If we use biometrics, do we turn that over to security, so they can verify your identity? If your fingerprint/retina pattern isn't working, does that mean it's almost always faulty hardware?

It's got to be well thought out to replace something that's just about as intrinsic as the on/off button.

Biometrics are not quite unique

[T.E.D.]

Wouldn't just about any biometric allow identical twins full access to each other's stuff?

The real problem is password rules

[LongearedBat]

Passwords would be fine, if we were allowed to use easily remembered pass phases. Instead we're still often forced to use short passwords (8-12 characters) that consist of upper case + lower case + digit + non-alphanumeric characters. Even though it's pretty well established that pass phrases are, overall, a better way.

Two-factor authentication solves it.

[gaiageek]

The problem is already solved, it just needs to be more widely implemented. Secondary authentication by phone (i.e. receiving an SMS) ensures that no one can get into my Gmail account if they happen to have my password. If my phone gets stolen, I'm going to know to take action quite soon, and they still have to get past the lock screen (though this does raise a good argument for making sure calls/SMS are not be answerable/readable without unlocking the device). Regardless, it would solve 99.99% of the problem.

Another idea I could see catching on is some kind of token ring, like a mix of an NFC ring and those RSA SecureIDs that spit out a random 6-digit code every minute to authenticate, but instead of the user having to type in the code, they just tap their phone/palmrest/screen with the ring. Assuming the rings are available in a few varieties for less than $10, I think most people would opt to use one if it meant avoiding annoying secondary security questions and having to keep a list of impossible to remember passwords (which they still have to change because sites get compromised). It avoids biometric requirements and has the possibility for anonymity (buy a ring at the supermarket, link it to any email account).

Half of this is good news

[houghi]

The good part is that they are concerned about passwords. The bad news is that they do not come up with a good alternative.

There are two issues with passwords. The first is that we are looking for a technical problem with what is essentialy a social problem. Security in itself is already a social problem. How many people will give uup their password to the IT guy or their boss without any question? To their SO, kids or parents?

The second isssue is that we have way too many passwords to remember and there is no single solution. (1) IT people are only looking to how THEIR system is secured and look at it from an, again, technical and not a social point of view. They do not count in the weakest point : humans.

And as long as you do not caqlcualte those in, it won't be solved.
So instead of saying 'We want to replace it with ..." they should have said "We want to replace it". That way you are open for a REAL solution.

(1) If you have a solution, please let me know. It must be one that I can use at home (Linux), at work (Windows, but I am not allowed to install anything and have no Internet access and am not allowed to use any cellphone or other device), on my phone, on PCs that are not mine, on my ATM machine.

Whats wrong with

[JustNiz]

a finger ring (or better yet an implant) with a unique RFID chip in it.
If the chip is not in close proximity to the computer keyboard, the compuiter immediately lockscreens.

An API to read the unique code of the user's chip would be avaiable to online apps too, so websites can use the same system to authenticate.

For extra security, the ring/implant could also continuously detect the wearer's presence and life, possibly with biometrics as simple as confirming the users pulse. If the signal is disrupted the implant can assume it is no longer secure until its reauthenticated.

Re:Smart Cards with PINs

[gmhowell]

Don't you mean we've been using PIN numbers on these 'ATM machines' you referred to?

DARPA wants what?

[ruir]

Say what, I made mandatory logins in my linux servers, and use pretty much double factor authentication everywhere...

Why do they ignore OpenID?

[Eravnrekaree]

Watch out, this is an trick to use the concerns over the weak passwords people use to push for monitoring and control mandates. Basically, its none of their business to force this on businesses. What kind of authentication a service offers is a private matter between users of the service and the service.

I do think, OpenID does exactly what we need here. its a single sign on system that can work in a decentralized manner between sites, and it does not require biometrics which is just a way to take away privacy. I think what has been needed is a system that makes creating and managing OpenID easy for common users. Then people can use a strong, strong password rather than a lot of weak ones.

Re:Why do they ignore OpenID?

[iggymanz]

Except those "private matters" have utterly failed, people use very weak passwords and the same password - this compromises finance and corporate systems. It's a threat to everyone

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

The Solution Has Been Around for a Long Time

[sudon't]

The solution has been around for a long time. If people would use password managers, then they could use better (and unique) passwords. I've never had an account compromised, and I believe that is in large part because, thanks to Apple's Keychain, I'm using strong, unique passwords for every account I sign up for. Every Apple computer has come with this integrated password manager since at least 2002, (that's how far back my oldest passwords go), but idiots don't use it. I have no idea what the situation is like for Windows users, but I'm guessing you'd have to pay for one, and it might not be as well integrated, as far as working with apps. Every OS should come with a password manager, enabled by default, and with a strong password generator.

Re:The Solution Has Been Around for a Long Time

[dl_sledding]

I have to completely agree with this. I've been using LastPass for the last 6 months, and it has totally changed the way I use passwords. Now, every password I have is a long, random generated string of characters, but I only need to remember one, very long and easy to remember password to access all of them. And since it's device and OS agnostic, it works everywhere. It's saved my ass a couple of times already.

It doesn't matter (to me) what manager you use, just use one. It completely changes the way you treat passwords.

...replacing them with biometric and other cues

[miltonw]

... aaaaand there goes anonymity.

I assume that would be one of the primary goals of the government.

Passwords are seeming like DRM

[scamper_22]

I think of passwords like DRM. Sure there's a lot of technical solutions and issues, but its fundamentally a a people and market problem.

As others have mentioned, anything can be hacked, copied, stored... if it is turned into bits and bytes. The best you can do is make it inconvenient enough for *most* people to do it.

Most people's homes are hardly secure, but you don't have people talking about the need to get rid of locks. Rather, it is dealt with as a matter of criminal law in terms of break-in and entering.

In the end, you really have to take things as a people problem.
For example, let us assume your authentication system can be broken into it.

What damage can be done?
Is it reversible?
Can people go to an office and fix the problem?
What are the penalties for those caught? ...

These are the real problems. Consider banking. If someone hacks my bank account, more effort can/should be made to make sure this can be addressed and reversed. Whether that is putting a holding period on transfers, notifying account holders of transactions (especially odd ones), relying more on local methods of authentication, increasing penalties for those caught. heck, one of the benefits of knowing your local bank is that they actually know who you are.

Heck, this could be part of the solution as well. Banks or other locally trusted authorities (like governments) could be providers of RSA-tokens or something like that. It could even be the government as well.

That in combination with a pre site password as today would be an improvement and still be practical. We already trusts banks with our phone numbers... this way we won't have to send it to each website. Or we can standardize on a RSA-token app for each website or something like that. I hate that they want your phone number.

Fortunately, I have not been hacked, but I have no idea what say Google's response would be if I had to contact them because my account was hacked. Hopefully they have processes in place at least to ask me about some recent emails or something like that. Or if they have kept track of my IP addresses used. But those things can be checked by the person hacking my account.

Or maybe local authorities can increase investigators to help resolve such issues. Police officers are out there dealing with crime and traffic and parking... perhaps we need to expand to online issues.

Re:Biometrics are great until...

[suutar]

see, that's why using biometrics for passwords is stupid. Sure it's personal, and probably unique, but it's not really secret.

Of course, there is a piece of the login process that has these attributes as well. It's the username.

We should use biometrics as a fast way to pick a user, and then require proof that the person knows the appropriate secret.

You know where this is going.

[AlanObject]

Are you guys ready for your laptop to demand a semen sample from you? How about a public access terminal?

Easy to change your password

[sproketboy]

Hard to change your thumb.

Retina Scanners?

[Steele Clifton Park]

Will biometrics be the new standard? Been there, done that?