×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mitigating Password Re-Use From the Other End

Soulskill posted about a year ago | from the 12345-goaway-letmein dept.

Security 211

An anonymous reader writes "Jen Andre, software engineer and co-founder of Threat Stack, writes about the problem of password breaches in the wake of the LivingSocial hack. She notes that the problem here is longstanding — it's easy for LivingSocial to force password resets, but impossible to get users to create different passwords for each site they visit. We've tried education, and it's failed. Andre suggests a different approach: building out better auditing infrastructure. 'We, as an industry, need a standard for auditing that allows us to reliably track and record authentication events. Since authentication events are relatively similar across any application, I think this could be accomplished easily with a simple JSON-based common protocol and webhooks. ... [It] could even be a hosted service that learns based on my login behaviors and only alerts me when it thinks a login entry is suspicious— kind of how Gmail will alert if I am logging in from a strange location. Because these audit entries are stored on a third-party box, if a certain web application is compromised, it won't have access to alter its audit log history since it lives somewhere else.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

211 comments

Forcing strong passwords in the first place. (4, Interesting)

bejiitas_wrath (825021) | about a year ago | (#43572727)

This seems like a good way to enforce strong password policies. if they are strong enough; they should help prevent password re-use. The only problem with this is the problem of people writing these down. We need a better online authentication system for 2013.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43572733)

So they can't use the same strong password on every site..?

Re:Forcing strong passwords in the first place. (5, Insightful)

war4peace (1628283) | about a year ago | (#43572765)

LastPass used to scream at me when I was doing that, so I disabled that functionality.

Re:Forcing strong passwords in the first place. (5, Insightful)

BrokenHalo (565198) | about a year ago | (#43573571)

I would do likewise. The whole point of a password is that it should satisfy the criterion of "something you know".

If you have so many passwords that you have to either write them down or store them in a password management system, then that criterion fails, because it's no longer something you know at all.

Whereas if you use good passwords to start with, and keep layers of trust between different systems (i.e. don't use the same password for your bank as you do for Twatter), then you will not be 100% secure, but at least you have a hope of keeping some control to yourself.

Re:Forcing strong passwords in the first place. (4, Interesting)

Curupira (1899458) | about a year ago | (#43573625)

Please someone mod the parent up. An overcomplicated password that need password management software ceased to be a password ("something you know") and were turned into a token ("something you have"). If your Lastpass DB is corrupted, goodbye passwords.

Re:Forcing strong passwords in the first place. (2)

vux984 (928602) | about a year ago | (#43573649)

The most important "layer of trust" to use your phrase is to ensure that your EMAIL has a strong password, and that it is not the same as anything else. Your email password is the weak link, thanks to the forgot-password-reset (or god forbid password recovery) functionality of most other online properties.

And this raises a problem. Email is frequently used... so long pass phrases are inconvenient.

And worse, we have it saved in our phones, and on our laptops, so we don't have to re-enter it every 5 minutes. So if we lose our device, we're hosed. I don't want to put in a long passphrase everytime i unlock my PC, I want to enter in a long passphrase to unlock my phone even less. So while I have a good password on my email, if my phone is stolen I'm potentially hosed.

The more I think about it, password reset functionality by email is -inherently- a bad idea. We should almost really have a 2ndary "secure" email that we don't use except for managing password changes etc. The problem with that of course is that no systems support having a separate email just for password recovery, so if you set one up you'd miss all the other mail from the site that you would presumably want to receive.

Re:Forcing strong passwords in the first place. (4, Interesting)

AK Marc (707885) | about a year ago | (#43572791)

No, they can't. There are a number of sites with incompatible password standards. If sites standardized on incompatible standards, then there wouldn't be an issue. I've seen some with 8 char requirement (no more, no less), and others that require more than 8. Some must start with an alpha, others that must contain a capital, lower, special, and number, so make requirements that are incompatible. Some must start with an alpha, others must start with a number.

Or, the other solution is assign the password, and don't let the user change his own. When it expires, a new one is generated. No reuse can happen when the user can't set any of their own passwords.

Or, forget caring. If they lose control of a password, then it's their fault.

Re:Forcing strong passwords in the first place. (3, Insightful)

Yaotzin (827566) | about a year ago | (#43572853)

Or, the other solution is assign the password, and don't let the user change his own. When it expires, a new one is generated. No reuse can happen when the user can't set any of their own passwords.

It would be hellish if every website started doing that. I'd have to recover my password every time I try to log in somewhere, or keep a big document of passwords (which is worse). At the moment I have 6 different passwords (8-10 char) in total, but they're mostly variations of the same base. Anything more complex than that and I would lose track.

Re:Forcing strong passwords in the first place. (1)

AK Marc (707885) | about a year ago | (#43573003)

You don't need to keep them if you have some manner of keychain program. You save them once, and don't ever enter them again (until they expire, which should be more rare if re-use was eliminated).

Re:Forcing strong passwords in the first place. (1)

fph il quozientatore (971015) | about a year ago | (#43573193)

And, let me add, Firefox and Chrome can act as "keychain programs".

Re:Forcing strong passwords in the first place. (2)

Antique Geekmeister (740220) | about a year ago | (#43573397)

And you'll send them the passwords email, which is consistently monitored for passwords and stored with poor security? And your "keychain" program is tied to one client, and a graphical environment, and that one web browser, with no way to extract the password for putting in your other web browsers?

This is just organizing a fresh set of security holes. It's not a solution. And it wouldn't have solved _this_ event which involves plain text passwords stored on the server side for millions of users.

Re: Forcing strong passwords in the first place. (1)

Anonymous Coward | about a year ago | (#43573511)

Keepass+dropbox = Secure keychaining on all devices ( Even iPhone ) and all Browsers, and only i have access to the information. The FBI can't get it from google or apple

Re:Forcing strong passwords in the first place. (4, Insightful)

peragrin (659227) | about a year ago | (#43573227)

1) I use five different operating systems. (Osx , ios, linux, windows, android ) name one keychain program that can be used across them all and keep that program easily sync'd?

2) You push the point of failure onto the keychain program. if you want to get someone all you have to do is crack their keychain and they are screwed.

3)what happens when your keychain program gets corrupted? a simple hard disk failure now prevents you from ever logging in again.

Re:Forcing strong passwords in the first place. (1)

MysteriousPreacher (702266) | about a year ago | (#43573303)

A good backup regimen would mitigate corruption of keychains.

Although it's true that cracking the keychain would open the door, that would at least require a cracker to get access to the keychain. If stored locally this wouldn't be a trivial thing. In terms of return on investment it would be expensive to do for anything but attempts on individual users. Most attacks are done in bulk on specific services.

I use very strong passwords on accounts where I register payment details, and a *very* strong password on my keychain. It's not invulnerable but it would be very difficult to break.

Re: Forcing strong passwords in the first place. (5, Informative)

Anonymous Coward | about a year ago | (#43573465)

1) LastPass

Re:Forcing strong passwords in the first place. (2, Insightful)

Anonymous Coward | about a year ago | (#43573669)

It would be hellish if every website started doing that. I'd have to recover my password every time I try to log in somewhere, or keep a big document of passwords (which is worse).

I have one website that I do exactly that with. They have such stupidly complex password for absolutely no reason (to get software updates for a product that requires a license server to run) that I refuse to participate. Their password requirements are even more complex than the Intel developer passwords - something I didn't think was even possible. So when I need to go login, I just reset my password and bypass their password system altogether. Just for fun, I even sent them email and told them that is what I do - but got no response.

Hell, why am I even hiding their name? It is Synopsys.

At the moment I have 6 different passwords (8-10 char) in total, but they're mostly variations of the same base. Anything more complex than that and I would lose track.

I have a few variations on a few bases. I have an ultra-low security password (for forums like slashdot and others), a mid-security base and a high security base. Then I have a few unique passwords that I use for one and only one purpose (one of them being my PGP key).

        Marc

Re:Forcing strong passwords in the first place. (1)

maxwell demon (590494) | about a year ago | (#43572861)

The problem is that you have to remember those passwords.

There are a few places where unique passwords are mandatory (everything related to money, your email account(s), and anything where you keep private data). But for anything else, a break is annoying, but not downright dangerous. OK, so if someone broke my password on Wikipedia, he might be able to get into my account on several other Wikis (assuming they correctly guessed which username I used there; I'm usually not using the same user name on different web sites, nor do I generally reveal my identity on those sites - for example, the only place where I use the nickname "maxwell demon" is Slashdot. Good luck guessing my Wikipedia login name; but then, my passwords on Slashdot and Wikipedia are different anyway).

Re:Forcing strong passwords in the first place. (3, Informative)

AK Marc (707885) | about a year ago | (#43573013)

The problem is that you have to remember those passwords.

That's what post-its are for.

Seriously though, I save passwords in a browser or other keychain management program.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573151)

People want to be able to access their accounts from whatever device they use at the time.
And they don't want to have to use a clumsy program with yet another password and cut-and-paste of passwords from there to their login screens.
This mess has to be cleared once and for all.

Re:Forcing strong passwords in the first place. (3, Insightful)

hedwards (940851) | about a year ago | (#43573633)

It's impossible to clear this mess up without using the same password and log in for everything. Right now I have over 400 log ins in my database. I'm not sure how many of those are ones that I need to log into again, but that's a large enough number that even changing them on a regular basis is unlikely.

Trying to unify that under the same log in that the sites get, is not something that's technically desirable. I'm not really sure how one can solve this problem form the server side, because you'd need 3rd party to access all of the passwords without the users' permission in order to know.

Re:Forcing strong passwords in the first place. (1)

Hognoxious (631665) | about a year ago | (#43573461)

No, they can't. There are a number of sites with incompatible password standards.

I've seen some that mandate at least one of each case, and/or a digit, and/or a punctuation mark.

I haven't seen any that forbid those. Different does not necessarily imply incompatible.

Re:Forcing strong passwords in the first place. (2)

hedwards (940851) | about a year ago | (#43573635)

You'd be surprised, I run into a fair number of sites where you have to use alphanumeric characters and nothing else. I've also run into a fair number of sites where the validation algorithm doesn't work so it will accept passwords that you can't use and just silently truncate or adjust them to whatever it takes without telling you what the new password is.

Then there's the sites that require at least 12 characters and the ones that limit it at 8. Really, it's a mess and the people paying for these systems don't care about security beyond appearances.

Re:Forcing strong passwords in the first place. (1)

smitty_one_each (243267) | about a year ago | (#43573253)

You have a strong root password, and a simple, site-specific suffix.

Re:Forcing strong passwords in the first place. (1)

houghi (78078) | about a year ago | (#43573537)

This is great if it works for you. e.g. bhj648_+shlasdot.org as password for this site and bX3hj648_+google.com for google.
You can extend it to your work place.
This will work great for you. Now let us add some reality to it.

When I look at where I work, most people need only two passwords. I have told them again and again that it is easier if they have the same password for both.

This worked for a while, but then things changed. One password needed to be at least 10 and the other only 8 characters. You would just add two characters and be done with it.
What I do is to take the month and year, add a 4 letter word and for the 10 letter password add ++. So now I have a password this month like 0413Foad and 0413Foad++. I change the password on the 1st of the month. Never had a failed password due to forgetting it.

Yet even this simple method will not work for the majority of people. They do not see password as a way to security. They see it as a way to hinder them to do their job.

So passwords and security are a social issue. When you only look at the technical part of it, you will fail.

First IT people should start with not needing to change my password every month. That will make me select a safer one, because I can remember it. The fact that people write down their passwords is not the fault of those people. It is the fault of the ones making the security for not taking the human into account.

And here I am just talking about 2 passwords at work. Add complexity for the rest of all your logins, passwords and pincodes.

Re:Forcing strong passwords in the first place. (2)

neokushan (932374) | about a year ago | (#43572767)

How does using a strong password prevent password re-use?

Re:Forcing strong passwords in the first place. (5, Insightful)

adolf (21054) | about a year ago | (#43572781)

How does using a strong password prevent password re-use?

It doesn't. I believe it may even encourage re-use.

Re:Forcing strong passwords in the first place. (4, Insightful)

Dunbal (464142) | about a year ago | (#43572783)

How about instead coding a site properly so it won't get hacked in the first place? Put the effort and resources there.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573025)

good luck.

Re:Forcing strong passwords in the first place. (5, Interesting)

T-Bone-T (1048702) | about a year ago | (#43573185)

+5? The only way to keep a website from getting hacked is by not connecting it to the internet in the first place. Effort should certainly be put into making it difficult to hack but also making it difficult to gain anything valuable when you are hacked.

Re:Forcing strong passwords in the first place. (1)

funkboy (71672) | about a year ago | (#43573311)

Effort should certainly be put into making it difficult to hack but also making it difficult to gain anything valuable when you are hacked.

Exactly. That's one of Schneier's central arguments [wikipedia.org] as to why sites getting "hacked" is so prevalent today. Once some initial security perimeter (e.g. a firewall) is breached, system design & security is sloppy enough that it's a free-for-all for the intruders. If systems were designed as a fortress built to secure data this would be a lot less of an issue, as unsuccessful crackers are broke crackers that need to start looking for income elsewhere.

Re:Forcing strong passwords in the first place. (1)

gutnor (872759) | about a year ago | (#43573581)

Right, but the alternative are either user education or local solution on the user machine (keychain tool). The first one will not happen, that much should be clear by now. The second one is a matter of opinion - you need to believe the users can be collectively better at fighting malware creators than website developers at fighting dedicated cracker. It seems that recently both the botnets and general website cracking have been going well, so the jury is still out.

Egoistically, I would rather have the website invest in good security. No matter how good is my password management skills are, when a website is cracked it affects me anyway. Giving up and letting the user sort it out on their end is already business as usual for me (and most /. users).

Re:Forcing strong passwords in the first place. (1)

smash (1351) | about a year ago | (#43573189)

You're just pushing TRUST out to the remote site. Are you really sure that EVERY single website you use is likely to adhere to any sort of sane security standards, and have competent security-aware web developers?

Random usernames. Random passwords. This whole "your email address is your username" thing is retarded.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573225)

A good 50bit entropy password, salted and stretched using bcrypt or scrypt is virtually uncrackable no matter how much GPUs you throw at it. 50 bit entropy is 8 random characters or 5 random words. It's not that hard, and it's much safer and better from a privacy point of view than what the OP is suggesting.

Better browser support will go a long way: if the browser can scrypt() the password on the user's machine I don't need to receive the plain text, the load on my auth server is reduced so I can demand strong stretching (2 seconds before you can login). The browser should become the authentication medium, not an easy to hijack webform.

Re:Forcing strong passwords in the first place. (2)

ldcroberts (747178) | about a year ago | (#43572801)

easy, just take the users attempted password and user name and try and log in to any of 100 other sites with it, if you can then reject it.

Re:Forcing strong passwords in the first place. (1)

feedayeen (1322473) | about a year ago | (#43572817)

My passwords all come in the following variations

yyyyyy
xxxxxxxxxx
Xxxxxxxxxx
Xxxxxxxxxx1
Xxxxxxxxxx_1

tell me again how strong password policies prevent re-use.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43572943)

If anything they encourage it - people stuggle to learn the complex passwords allowed so resort to either only learning one complex password and using it everywhere or post-it notes.

This is a much more secure method, but most sites won't allow passwords that long (even though it should be generating a hash so the length shouldn't actually matter to them at all): http://xkcd.com/936/

Re:Forcing strong passwords in the first place. (5, Funny)

leaen (987954) | about a year ago | (#43573101)

My passwords all come in the following variations

yyyyyy
xxxxxxxxxx
Xxxxxxxxxx
Xxxxxxxxxx1
Xxxxxxxxxx_1

You missed one of variations. I tried them all but I cannot login

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573307)

You missed one of variations. I tried them all but I cannot login

Have you tried ******** , works for me.

Re:Forcing strong passwords in the first place. (1)

Anonymous Coward | about a year ago | (#43573293)

Looks like you've been sequencing DNA In West Virginia again.

Re:Forcing strong passwords in the first place. (1)

sbluen (1307489) | about a year ago | (#43572921)

I think it can be acceptable for gaming websites and other low-value websites to allow weaker passwords though, because the inconvenience of a lot of extra typing isn't worth the utility and so that people automatically have multiple passwords if that password is insecure.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43572965)

The site operators may still have a problem with that, though, since breached accounts can be abused for spamming and the like.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573159)

The site operator's problem is not my problem.
When the site operator elects to have rotten code and is being breaked in to, or is stupid enough to use e-mail addresses as usernames, let them solve the problems for themselves.

Re:Forcing strong passwords in the first place. (1)

hedwards (940851) | about a year ago | (#43573645)

What inconvenience? It's precisely the same amount of work for me to use a 2 character password as it is to use a 100 character password. Once you get more than about 4 log ins, it becomes inconvenient to memorize them anyways, and with a keychain the length of the string and the component characters are moot.

Re:Forcing strong passwords in the first place. (2)

Arancaytar (966377) | about a year ago | (#43573113)

Password policies are voodoo. They may make it more difficult for stupid users from using weak passwords, but they do not reliably prevent it, and they actively inhibit the use of strong passwords [xkcd.com] .

Re:Forcing strong passwords in the first place. (2)

sosume (680416) | about a year ago | (#43573163)

Exactly. I hate it when some site first forces me to register, and then even has the balls to require a complicated password, assuring in the process that I won't become a returning visitor.
My usual password strategy is that I use a one very simple password for all systems that cannot harm me in any way. Such as news sites, free games, etc. Who cares if anyone can post under my name. For paid-for stuff and sites I leave personal details etc, I use a strong password, with alternating user names. Then when I need access, I check my mail archive to retrieve the username and voila. But for the real deal, paypal, google, banking and my pc login, it's a whole different ballgame. Strong individual passwords, and I change them each time after use on an insecure network, or when switching projects. But there are only four of those. It's just a waste of brain cells to have to remember 100s of user names and passwords, and change them frequently too. And I do not trust external applications or plugins to remember them for me.

Re:Forcing strong passwords in the first place. (1)

hedwards (940851) | about a year ago | (#43573663)

Sigh, somebody else trots out that stupid XKCD cartoon without understanding it.

The example that he used substituting for troubadour with a 2 character chaser is not something that has ever been recommended password policy anywhere I've seen recommendations made. It was specifically warned that you not take a dictionary word and transliterate it into leet speak because it wasn't a strong password.

Bottom line is that the suggested option is easier to reconstruct than a random password and that once you get more than a small number of passwords, you're probably not going to be memorizing them anyways, as you're supposed to be changing them from time to time.

Re:Forcing strong passwords in the first place. (2)

flimflammer (956759) | about a year ago | (#43573239)

I am so sick of websites that try to force "strong" password creation by creating their own rules. I have several strong passwords that I use that aren't considered "strong" by many websites (it is a nonsensical sentence with misspelled words). When you force me to add capitals and numbers and likely symbols, it's just going to cause me to change "thequickbrownfoxjumpsoverthelazydog" to "Thequickbrownfoxjumpsoverthelazydog1$" and then when attempting to log into the site I'll have to enter several variations until I remember what specific version of "strong" this particular site is trying to shove down my throat before I can log in.

My password is secure enough without you complicating things further by requiring certain characteristics.

On another note, it amazes me how often websites will enforce "strong" passwords, but have a length limit. You want a capital, a number, a symbol, but it can only be between 8 to 12 characters long? What?

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573329)

A length limit on a password is a smell that they're storing it in plaintext somewhere. If they're doing things properly, storing a salted hash of a password, why do they care what the maximum plaintext length is? Avoid such sites.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573513)

You have to limit password length to limit the probability of hash collision. But then about 64 chars max would be likely enough, no need to limit it THAT much.

Re:Forcing strong passwords in the first place. (1)

Hognoxious (631665) | about a year ago | (#43573563)

The length of the hash will depend to some extent on the length of the original. If it didn't you'd need infinite compression, or you'd have to accept hash collisions.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573489)

There is no point of using a strong password if the site imposes a limit on brute force attacks in the first place. The site is offloading security to its users.
So what if the password is weak as in 10^4 vs 10^9 combination if the site only let you have 3 failures per day before the account get locked up for the day and notify the account owner? Also the site should encrypt + salt their account info so that a leak cannot be lead to someone using a hash attack.

Re:Forcing strong passwords in the first place. (1)

Hognoxious (631665) | about a year ago | (#43573517)

Apologies if this is a silly question, but doesn't requiring specific characters reduce the set of possible passwords, making it easier to crack?

If I know there has to be a numeric (and max length is 8) I don't have to try ABCDEFG[A-Z], for example.

Re:Forcing strong passwords in the first place. (1)

smitty_one_each (243267) | about a year ago | (#43573247)

Well, we could subsidize all the Dunder Mifflins out there, and then outlaw paper. . .
But then people could carve the passwords into the furniture. . .
Outlaw furniture?
But Congress never holds itself accountable, so there'd be a bunch of people standing/laying on the Mall, calling Congress a pile of dicks.
Something should be done to make people more controllable.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573351)

Actually, people using longer passwords, and different ones for different sites/systems - and then writing them down would be an improvement. If you write down your passwords and keep them in your wallet, then the number of people who could potentially "hack" them is limited to those with close personal contact that could snatch your wallet.

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573391)

"Strong password policies" mostly translates to the bad form described by xkcd at http://xkcd.com/936/, of unusable, hard to remember passwords that *enforces* the use of a few passwords re-used and typed everywhere, easily stolen, hard to change.

"Don't keep or send passwords in clear text" is an old lesson that keeps being violated. Subversion with HTTP and HTTPS? Stores passwords locally in clear text. Most rotten password schemes? Stores passwords in clear text. Most git users with SSH keys? Stores passphrase free keys locally because the owners can't be bothered to use keys, and have the strange attitude that "if you don't trust the machine you're working on you should'n't be using it" which does *NOTHING* for other people in less secure environments who use the same software. Shared root passwords on all the servers, written in the wiki? Happens everywhere I've been for the last decade.

It's not the system, it's a collection of bad attitudes and poor practices that were solved more than a decade ago with good tools like Kerberos, but were blocked from general adoption by idiocies like US export encryption regulations and have promulgated by every idiot with a new software system re-inventing the wheel and *leaving out half the spokes*. And it's encouraged by modern "object oriented" programming where the problem is consistently left to someone else, and to cope with and the local aspects of it in each part of the programming stack are simply ignored as "not relevant to this part of the system".

Kerberos did about as good a job as you can do with it from a technology sense. The password management is robust, it's encrypted at each layer of the stack, but it got abused with that secretive "your password isn't good enough, we won't tell you which part wasn't good enough and we *won't tell you what the rules you have to follow are*". So we've wound up with the Mix3dKaz3" leetspeak passwords xkcd described.

Re:Forcing strong passwords in the first place. (1)

PopeRatzo (965947) | about a year ago | (#43573419)

The only problem with this is the problem of people writing these down.

Isn't there anything better than passwords, that would be unique, anonymous and disposable (destroyable)?

Re:Forcing strong passwords in the first place. (0)

Anonymous Coward | about a year ago | (#43573421)

if they are strong enough; they should help prevent password re-use.

Bulll FUCKING shit.

3rd party box (2)

Frankie70 (803801) | about a year ago | (#43572735)

Because these audit entries are stored on a third-party box, if a certain web application is compromised, it won't have access to alter its audit log history since it lives somewhere else.'

Since the audit entries are being created by the box running the application, it obviously has write access to the 3rd party box. So whoever has access to the application box has access to write (and hence alter) the 3rd party box.

Re:3rd party box (1)

maxwell demon (590494) | about a year ago | (#43572873)

The other box would of course only support adding records, not removing them. So unless you are hacking the other box, the only thing you could do is to increase the suspicion by creating bogus extra login reports.

Re:3rd party box (0)

Anonymous Coward | about a year ago | (#43572901)

You can design the 3rd party box to only allow appends to the log. So you can end up with fake/garbage logs but you can't get rid of the earlier logs.

Anyway it all seems a bit like a solution looking for a problem. And the solution might end up worse than the problem when actually implemented.

Re:3rd party box (0)

Anonymous Coward | about a year ago | (#43572971)

Since the audit entries are being created by the box running the application, it obviously has write access to the 3rd party box. So whoever has access to the application box has access to write (and hence alter) the 3rd party box.

No serious implementation of distributed logging would allow the client to modify entries on the server -- only the appending of new entries would be permitted... ...much like syslogd(8) has been doing for donkey's years.

Come to think of it, why re-invent the wheel -- why not just use a remote syslogd for the recording process (wrapping the comms in some sort of encryption first, naturally)?

Passwords are unfixable (2, Interesting)

Anonymous Coward | about a year ago | (#43572741)

You can tack on more mitigation, but in the end it's the concept that's flawed, not the implementation.

how about store your passwords properly? (5, Insightful)

Trepidity (597) | about a year ago | (#43572759)

it's easy for LivingSocial to force password resets, but impossible to get users to create different passwords for each site they visit

It also ought to be easy for LivingSocial to store passwords hashed with a secure hash designed for passwords, like scrypt [wikipedia.org] (or the related bcrypt). That way even if the password db is compromised, the plaintext passwords aren't, and the attacker cannot use the result to get into other services, even if users shared passwords across services.

It's easy to blame users, but there has been no excuse for storing plaintext passwords for years now. Password reuse is a much smaller problem if websites are designed properly. So rather than "as an industry" attempting to change user behavior, how about "as an industry" implement your damn sites properly, and audit that.

Re:how about store your passwords properly? (3, Informative)

Trepidity (597) | about a year ago | (#43572773)

Replying to self: It looks like LivingSocial actually has switched to bcrypt now. But not early enough!

Re:how about store your passwords properly? (2)

niftydude (1745144) | about a year ago | (#43572893)

It also ought to be easy for LivingSocial to store passwords hashed with a secure hash designed for passwords, like scrypt [wikipedia.org] (or the related bcrypt).

It's easy to blame users, but there has been no excuse for storing plaintext passwords for years now.

Yes! I can't believe there are websites out there that still don't hash passwords.

A few months ago I signed up to the website of a large health insurance provider, and they sent me an email confirmation of my account creation that included my website password in plaintext. Unbelievable.

Who writes this stuff? And who hires these people?

Re:how about store your passwords properly? (1)

dingen (958134) | about a year ago | (#43573047)

Putting your password in an e-mail during the registration process doesn't mean they store it in plain text in their database. If they can come up with your password at a later point (like when requesting a "lost password"), THEN you know they are storing their passwords in plain text.

Re:how about store your passwords properly? (1)

Anonymous Coward | about a year ago | (#43573077)

If the password is in plain text in an email it is available to anyone in the network path between the service provider and my email provider. It is also available to anyone looking over my shoulder when I read my email. Sending a password in an email is just plain stupid, with an exception for one-use passwords that force a reset when used.

Keep clear text passwords on the client (2)

Ottibus (753944) | about a year ago | (#43573135)

Putting your password in an e-mail during the registration process doesn't mean they store it in plain text in their database.

But it does mean that they send the password in clear text rather than hashing it on the client.

Clear text passwords should never be sent over the Internet, even over secure channels.

Re:how about store your passwords properly? (0)

Anonymous Coward | about a year ago | (#43573553)

While bcrypt may be the gold standard in password storage, LivingSocial's per-user salt + hash is fairly good. The only thing missing is an "application salt" that is not stored in a database, can be a whole lot longer (>=4KB), and would be difficult to get with a simple database breach.

You just made it easier for cracking. (3, Informative)

mjuarez (12463) | about a year ago | (#43572779)

So, what happens when that central framework/infrastructure is cracked? Now, all cracking attempts will redirect to that single point, and when (not if) it's breached, they'll now have access to ALL websites that are signed up to use that. How is that better?

Re:You just made it easier for cracking. (2)

gl4ss (559668) | about a year ago | (#43572795)

So, what happens when that central framework/infrastructure is cracked? Now, all cracking attempts will redirect to that single point, and when (not if) it's breached, they'll now have access to ALL websites that are signed up to use that. How is that better?

that you have to just use one complex password at one place and have to change it just at one place.

however the author is a dumb fuck who apparently hasn't heard of any of the SSO services...

Or, alternatively... (3, Insightful)

neokushan (932374) | about a year ago | (#43572785)

If you're security conscious enough to put this fancy bit of JSON on your site, then most likely you're smart enough to not store your user's passwords in plaintext. In fact, I'd like to think you're clever enough to salt the hash of the passwords that you're storing as well.

Why am I pointing this out? Because password re-use is an issue when a password gets compromised. Passwords get compromised when they're not encrypted or hashed. So to "fix" the problem like this is all well and dandy, but it only works if every site does it and if every site hashed the bloody passwords in the first place, they wouldn't get compromised as often.

one key to rule... (2, Interesting)

Anonymous Coward | about a year ago | (#43572823)

Or we could just use GPG authentication, where a user simply uploads his public key to the site. User's happy, because s/he can use the same passphrase everywhere and the site is also secure because even a hack won't divulge any passwords. Separate (key-less) password could still be optional.

Too many damn passwords (3, Interesting)

seeker_1us (1203072) | about a year ago | (#43572837)

If you have too many different username/passwords you will not be able to keep them straight. This is what OpenID was supposed to solve. One can flip the argument around very easily: if there were fewer sites maintaining their own password databases, then there would be fewer breaches.

And that does NOT mean using OpenID for everything including financial accounts.

Oauth 2.0 (0)

Anonymous Coward | about a year ago | (#43572855)

This third party box with json interface already exists!
When u login using facebook, twitter, linkedin, google its exactly that!
Protocol also exists: oauth/oath 2.0!

Still a issue that Devs won't acknowledge (4, Interesting)

Quick Reply (688867) | about a year ago | (#43572859)

The thought process of a developer is that it is usually a user problem, and therefore it is the user that needs fixing, not the user.

The cold reality is that using passwords at all is the problem.

Passwords are an antiquated solution to a simple problem from the very start of multi-user computing. It is simple but exponentially ineffective as it scales.

The human mind is not set up to remember multiple, complex passwords. There are very few humans who are gifted with this ability to remember literally hundreds of different passwords without writing it down, I would put someone who can in the realm of an academic genius who can remember entire textbooks or recite Pi for hours before they eventually have to take a break for physical reasons.

Normal people write it down or keep it to a narrow set of passwords depending on which level of complexity the system will allow. Both bad security practice.

And passwords that expire every 45 days with annoying complexity requirments? You're going to drive users nuts trying to think of new ones each time that eventually they will come up with the simplist password the system will allow and increment by 1 each time they have to change eg: Password1, Password2, Password3, etc.

There are hacks out there, eg: KeePass and LastPass, but this is a workaround to the underlying problem. The websites that Force you to use Facebook are even worse (as they force you to handover all your personal details while you are at it, which just as easily can be used for identity fraud. Many Banks, Telcos etc. only authenticate with your DOB). OpenID is better but the implementation makes it common to sign in from the website your are trying to access, making it susceptible to being spoofed.

Realistically, we need to kill the password. Two factor authentication all the way. It needs ONE trust relationship between the user and the authenticator. This could be a user ID and a token. The authenticator can have then multiple trust relationships with participating websites.

The authenticator should only provide two data points: (1) The user ID of that website (different ID to other websites so that the user can be tracked with the same ID across websites) and (2) That the user has authenticated themselves. Thats it. Most websites don't need to know your name, DOB, Vanity username, email address or anything else about you. If they need this, ask - but only if actually required - and give the user a clear option to decline or provide only partial data.

The only thing that most websites or other computer systems need is a way to tell which user profile to load up, and that the user requesting it is really the same user. A password does not prove that,

Re:Still a issue that Devs won't acknowledge (1)

VortexCortex (1117377) | about a year ago | (#43572899)

I disagree. Zero factor authentication works beautifully for everything online.

For the physical world, there's cold hard cash -- The Great Authenticator.

Re: Still a issue that Devs won't acknowledge (2)

Quick Reply (688867) | about a year ago | (#43572941)

Then how come you are posting as VertexCortex and not Anonymous coward, still needs to be a mechanism to make sure you are VertexCortex. Ideally you should be able go hit "Login" on your browser, and your browser automatically logs you in for you while using two factor in the background (once you have already two-factored with your browser when you sat down) so Slashdot knows 1. You are VertexCortex (to load your preferences and posting abilities as your name) and 2. You have proven yourself (It doesn't need to know how, it just needs to kniw that you have)

nightmare (2)

stenvar (2789879) | about a year ago | (#43572995)

'We, as an industry, need a standard for auditing that allows us to reliably track and record authentication events.

That sounds like a security and privacy nightmare.

but impossible to get users to create different passwords for each site they visit. We've tried education, and it's failed.

Perhaps users just don't give a f*ck whether their account on some third rate e-commerce marketing site gets compromised?

If I were to create an account on LivingSocial, it would get my "disposable" password, the password for accounts I just don't care about at all. Only gradually do accounts and services migrate into the category where I bother remembering a specific and hard password for them.

Re:nightmare (3, Interesting)

vtcodger (957785) | about a year ago | (#43573269)

If I were to create an account on LivingSocial, it would get my "disposable" password, the password for accounts I just don't care about at all. Only gradually do accounts and services migrate into the category where I bother remembering a specific and hard password for them.

That's rational.

Frankly, most password security "thinking" seems to me demented. There is no way I or most anyone else could possibly keep track of hundreds of different strong passwords with arbitrary characters, random case, etc without writing them down. And maybe not then.

And there is no practical way that I could secure that password list.

Neither is it likely that information providers can secure password information -- strong, weak or non-existent -- on their end. That's why massive password breaches are a daily event.

Bluntly, the industry's attempts at security can't and don't provide much security and are more a massive usability problem than anything else. How is "user education" supposed to overcome faulty engineering?

Look folks, the method you want to use to secure stuff simply doesn't work very well. Never has. Never will. Forget about "educating" users, and start thinking seriously about how to secure stuff, and whether most of what you are trying to "secure" actually needs securing. Maybe in decade or three you'll come up with something that works.

In the meantime. Get real.

Don't brush your problem off on the user (4, Insightful)

Opportunist (166417) | about a year ago | (#43573085)

I see it very often in audits, company security is facing the same problem: How to secure the network? The easy way out: The user has to do it. He has to come up with a password that fulfills the most inane requirements AND must remember it AND must not note it down.

That's the easy way out. All the burden is shifted to the user.

I consider it extremely patronizing if they then go, after a breach, that they tried to "educate" the user but failed. Well, DUH. Guess what. It's not the user's job to keep your database secure. It is his job to make sure his credentials don't get handed over to a third party, yes. But it is YOUR job to make it possible to him. And it is NOT possible for the average human being to remember passwords in the style of k$aUZ_nR2o.

Don't try to shift a problem that YOU have to solve onto your users!

Re:Don't brush your problem off on the user (1)

140Mandak262Jamuna (970587) | about a year ago | (#43573435)

The user has n interest to make sure that if one site he/she logs into gets hacked, the damage does not spill over into other websites. The websites have a completely different cost/benefit scenario. Security is seen s cost. Do the minimum required to identify the users, remember their settings/preferences, give users some vague sense of security. That is all the web sites are going to do. Unless the user demands better security they wont provide it. You think there will be enough users demanding more secure sites in this day and age? Most users dont even seem to know that there is something called security and privacy. No there is no incentive for the sites to provide any more security. Costs money, reduces user "experience".

So if you care about security, first take steps to make sure you can prevent spill over from one hacked site to other user accounts you have on other sites. Then evangelize about the need for better security, At some point even the twitter using teen might actually "get" it.

Solution is simple (1)

smash (1351) | about a year ago | (#43573179)

Don't make users log in with their email address. Give them a randomly generated username and password combination.

This whole practice of forcing you to use an EASILY identifiable piece of information (your email) as one of the autentication factors is just retarded.

Forget passwords, worry about "Secret Questions" (5, Insightful)

Ottibus (753944) | about a year ago | (#43573201)

All this concern over passwords is ignoring the much greater problem of so-called "Secret Questions". This is a mechanisms that positively encourages people to use the same security information on every site they visit and to give answers that can easily be guessed by other people.

How many sites hash the answers to these questions so that they can't be re-used by a hacked who breaches the site (or a corrupt employee)?

How many users take care to give a different wrong answer to these "Secret Questions" every time?

The complexity and variablility of the password reset process can make this mechanism less susceptible to automated attack, but if you want to attack a specific account of a known person this is a much better route that trying to crack the password.

Re:Forget passwords, worry about "Secret Questions (0)

Anonymous Coward | about a year ago | (#43573259)

I use a 2nd password as the "answer" to any secret question. Answering it correctly is a security risk since it can be guessed.

I just use facebook (0)

alen (225700) | about a year ago | (#43573223)

Lots of sites support using Facebook for authentication
So that's what I use instead of making up a fiftieth username password combo

Educate the users, Avoiding reuse is easy (2)

140Mandak262Jamuna (970587) | about a year ago | (#43573241)

1. It is in the best interests of the users to use different passwords for different sites. Simplest thing to do is to use a 8 char string as the base password and append, prepend or insert a three char string based on the web site name into it. Each site has its own password, but it would not be easy to use a compromised password at other sites. It is in the best interests of the users to do it. For sites security is just cost, they do the minimum. Rotate the base password once a year or so.

2. We should ask the more important accounts like brokerage, mutual fund, bank accounts to use a two factor authentication system. But I don't want to juggle too many RSA key fobs. I like google sending a six digit code to the designated cell phone. Google also lets you set up 10 one time pad numbers ahead of time to handle the case when the cell phone cant get texts. As a first step if they would just send me text or an email for each login event and each transaction that would reduce fraud.

3. What really bugs me is, in this day and age of social network where people are posting details of their breakfast lunch and dinner for the whole world to see, even banks use "maiden name of mother" "name of your pet" or "where you went for honeymoon" to reset passwords. That is insane. So I used to give non intuitive answers like "nissan sentra" as the mothers maiden name. But it is so difficult to remember what stupid answer I gave to which site. That is my biggest beef with these security questions.

4. No I did not switch my username and password edit boxes when I signed up for slashdot. Friends recognize the dorm addresses, rest of alumna recognize the dorm names.

Re:Educate the users, Avoiding reuse is easy (1)

Jaktar (975138) | about a year ago | (#43573321)

What you suggest is already available via add-in password hashers on the users end. Passwords are automatically generated and salted with the URL. You can "bump" a password to change the salt. The main problems I've come across are:

1) The algorithm differs by browser, even those that say they are compatible.

2) Some password entry points don't have a hasher function built in, requiring me to either write down the password or switch to the browser to get it.

All of my password hashing efforts are moot if the server end loses their password database, though I'll only have that one password compromised.

Even with these hurdles, it's worth using the hasher.

Re:Educate the users, Avoiding reuse is easy (2)

140Mandak262Jamuna (970587) | about a year ago | (#43573477)

My problem with such hasher is that, I did not write it. I am not trusting all my passwords to some binary blob. How do I know the add-on/extension/app is not phoning home all my passwords to some chinese hackers? That is why I use my own brain to do the hashing and salting. I am not so paranoid about passwords to minor accounts like slashot or app dev. Even medium level accounts like amazon or gmail is ok. But each my bank/brokerage account gets a personalized password that is not written down, not generated by an app, extension or add-on, not saved by the browser. Unless I can avoid it, I log into these accounts from exactly two computers. One from work (out of the four I use at work) and one from home (out of the seven internet devices at home network).

Re:Educate the users, Avoiding reuse is easy (0)

Anonymous Coward | about a year ago | (#43573457)

2. We should ask the more important accounts like brokerage, mutual fund, bank accounts to use a two factor authentication system. But I don't want to juggle too many RSA key fobs.

You don't have to. People may be used to thinking of RSA hardware tokens as something that is provided to them by the company they are doing business with, but you can BYOT (bring your own token) for your account. While corporate VPNs are likely to have policies against that just as they commonly have policies against bringing your own computer, most private uses are happy to let you save them $35 by enrolling a token you already have.

Get a free RSA token from ETrade and use it at PayPal, or get a token from your bank and also use it at your brokerage. You will have to call tech support at your bank/brokerage/etc to enroll rather than use the preprovided web forms when you BYOT, but it works.

For example, here's some folks talking about how to BYOT to Fidelity brokerage accounts http://www.bogleheads.org/forum/viewtopic.php?f=2&t=108267 [bogleheads.org] . That's a broker who isn't even known for supporting two-factor authentication for customers!

Passwords get reused because the web sites that (0)

mark_reh (2015546) | about a year ago | (#43573359)

need a password allow the user to select their own, usually insecure password. If each web site generated a secure password/phrase for you this problem would go away. The problem is that people would complain about having to store/remember complex passwords. What is needed is ubiquitous and automatic password management software/hardware that works on any computer, phone, or tablet.

Programs/services like LastPass can make storing/using passwords easy, though their mobile phone app isn't very good compared to the browser app. 2nd credential devices like Yubikey and Google Authenticator are OK too, but there's still too much messing around to do to use them, though I suppose there is some minimal amount of messing around that will always be necessary to prove that you are who you claim to be.

Edit the spam solution form (1)

Antique Geekmeister (740220) | about a year ago | (#43573443)

The old spam solution form at http://craphound.com/spamsolutions.txt [craphound.com] covers most of the solutions being proposed here.

        http://craphound.com/spamsolutions.txt [craphound.com]

Common spam problems such as "Ease of searching tiny alphanumeric address space" and "Jurisdictional problems" translate easily to the common password problems of "sending passwords via email is inherently insecure" and "requiring unique passwords for each trivial new website creates enormous keychains that are not safely portable to new computers or software clients"..

Do it in Firefox (1)

sunderland56 (621843) | about a year ago | (#43573491)

Firefox already has password tools - it can optionally store the password from different sites. It should be simple to extend this to warn the user if any two passwords are the same.

Firefox uses *local* storage for this, on the user's computer, so it will be more secure than any remotely-hosted solution.

Low and High Security (2)

AndyCanfield (700565) | about a year ago | (#43573543)

I have a low-security password that I use for Slashdot and most web sites. I have a very high-security password that I use with my bank (it depends on a number that has not been written down anywhere for fifty years). The idea of needing a unique password for every web site is rediculous. What do I care if yahoo.com is hacked and somebody logs in to Slashdot as me? Impersonation is not a serious problem.

(Result: I can not guarantee that I wrote this message. So what.)

Simple Solution (0)

Anonymous Coward | about a year ago | (#43573577)

Why does every dammed web site needs it's on password in the first place?

No human is able to remember them and (together with weird complexity rules and change intervals).

I have not seen a working cross platform (all major OS(Windows + Mac + Linux in different versions), all desktop browsers, smartphone, tablets) roaming keychain solution I trust.

So Open ID Connect (easier ti implement than the clumsy OpenID spec) could be one solution. It reduces the number of passwords to remember, the number of registrations (and confirmation emails). Maybe the only missing piece here is a mechanism to link more than 1 account together (so that the impact of a disabled account (for whatever reason) could be solved easily.

Single Sign On (0)

Anonymous Coward | about a year ago | (#43573607)

If you have a central service doing this, you might as well just have it be a single sign-on service, in which case password reuse isn't a problem because you only have one anyway.

Wrong approach in use. Secrets should be local (4, Interesting)

Morgaine (4316) | about a year ago | (#43573657)

The sites that are calling for better password choice need to step back a bit and consider whether their design concept of storing user passwords centrally is a good one. It's not, so they should get rid of it instead of applying band aids to a bad scheme.

It doesn't matter what encryption scheme is used, if authentication secrets are stored centrally on a website then they are at risk. Good sites make it hard to crack, and poor sites make it easy, but they are all at risk, from internal employee corruption if nothing else. Those secrets will leak because when stored at a single point then they are all accessible to the attacker at a single point. Leakage is just a matter of time.

A vastly more secure approach that's been well known for decades is for the user to store their secret locally as a private key, one half of a {private,public} key pair. The server only gets to know the public key (PK), and it's pointless for an attacker to crack that because the PK is public information that can be distributed freely through keyservers. (The PGP/GnuPG keyserver network has been doing this for decades.)

When a user creates an account on some website, she provides the identifier of her chosen PK (she may have lots of them). When logging in to the account subsequently, the server looks up her PK identifier in the info for this account, fetches her PK from the keyservers, then it sends her a random string encrypted with her PK. She decrypts it with her private key (which is only held locally by the user, nowhere else) and sends the decrypted string back. The server accepts the login if the returned string matches the random string that it picked, which is not stored and varies on every login, and rejects the fraudulent login attempt if the match failed.

That's strong distributed security, and it's resistant to MITM attacks and does not store any authentication secrets on the central service so those secrets cannot leak when the service is compromised.

It's not rocket science. Why this old but secure scheme isn't used by websites is quite a mystery.

Lastpass (1)

sdo1 (213835) | about a year ago | (#43573671)

I don't know why more people don't use solutions like Lastpass. I have one very long and difficult to guess password (but easy for me to remember), and every site I visit has a unique psudo-random gibberish password. If a site does something really stupid like store passwords of their users in plaintext, a breach will only allow access to that site since that password is used nowhere else. This method is impervious to dictionary attacks, hash-table lookups, etc. It's a tiny bit of an inconvenience, but it's very secure and I don't have to worry about breaches like this at all.

-S

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...