

You're wrong about LinkedIn, it's not the users, it's you - cpt1138
https://www.ufp.com/identity/blog/linkedin.html

======
smoyer
I agree with the article's premise, but the user does need to be educated
about the risks at the same time. We can enforce some degree of password
strength, but we can't keep the user from reusing the same password. If we
could guarantee that their password would never be exposed, that would be fine
_but_ I'm never going to make that guarantee.

I can be diligent and yet one mistake can still expose the user's (hopefully
salted and hashed) password. If there is a financial impetus for someone to
find my mistake, they will spend the time looking.

As a side note, I'd love to hear how the hackers came to be in possession of
6.5MM LinkedIn passwords ... what mistake was made that allowed them to
collect unsalted hashes in the first place?

~~~
dpark
> _we can't keep the user from reusing the same password_

Neither can the user. Users cannot remember a unique password for every site
they visit. That's just not realistic.

The simple fact is that unique-password-per-site does not scale. Password
managers don't work well, either, because they can't be integrated into the
common mobile browsers, and they frankly just require too much user
intervention. (Sure, I'll install this plugin on every machine I use, plus the
gimpy custom browser for my phone and tablet, and I'll use the app to
cut/paste into other apps that need auth...)

We really need to big players to get together and build a system that works,
and for them to all implement it properly and push 3rd parties to use it.
BrowserID seems promising, but I haven't heard of any other big players
signing on to implement and support it.

~~~
smoyer
Jeff Atwood has made the same claim and it's his rationale for using OpenID on
the StackExchange sites. I don't disagree, but most users won't figure out how
to use OpenID. FB login is widely known but it's not at all side-effect free.

~~~
Splines
FB seems like the lowest-bar when it comes to usability. Most people have a
facebook account, and are familiar with the "app needs your permissions" flow.

I'm not familiar with how you write a web-app to use FB authentication - how
much does using FB auth obviate the need for you to worry about user
credentials?

~~~
polemic
I just wish everyone didn't take the opportunity to also tap into the 'post to
you activity stream, spam your friends' goody bag at the same time.

Use FB by all means, but don't fail the auth if the user declines the extras.

------
gdp
Makes a fairly interesting point that seems obvious once you've read it, but
which we actually don't have embedded as an assumption - that the level of
user trust placed in us as developers is not matched by the level of care and
responsibility which we actually feel when that trust is placed in us.
Definitely some food for thought, and I think we need to take the entire issue
much more seriously rather than just slapping anything together and forgetting
about it.

~~~
huggyface
What is the interesting point? That users should place a foolhardy, ridiculous
level of trust in developers and processes that they don't know and have no
insight into?

~~~
deelowe
I don't know what it takes to build a lot of things, but I trust that the
engineers will do a good job. I see no difference with software.

I've always found it odd that SWEs can harbor this type of opinion. That is,
"it's the user's fault for trusting me/us." when every other engineering
discipline would consider such a stance insane. All other disciplines would
place responsibility directly on the engineering team. Whether a plane falls
out of sky, a car explodes when rear ended, a bridge collapses, a chemical
causes cancer, or an oven electrocutes the user, in all cases we'd point the
finger at the engineers (or company that performed said engineering) and
demand an explanation. I see no difference here.

Full disclosure: This is coming from someone who was originally studying to be
a ChemE before switching to comp-sci.

~~~
bwanab
It might be interesting to point out that in all the examples you give there
exist strong regulatory requirements. Are you (we, collectively) saying that
regulations and government oversight should be on the table for web sites that
provide services requiring a certain level of security?

~~~
deelowe
The regulatory compliance varies from state to state. For example, ChemE
doesn't require a PE in most (all?) states. Typically, regulatory compliance
is only required when the work involves some sort of interstate commerce.

With all the leaks and concerns over privacy lately, I think we'll see some
sort expansion of the laws covering PII sooner than later. So wether or not I
agree with it, I think this will happen.

------
mhellmic
I would like to disagree on that:

"It's not really about MD5, SHA1 or BCrypt, (...) It wouldn't matter if the
passwords were all in plaintext if they never got out."

It is also about the hashes, because a good security infrastructure should
anticipate the possibility of a leak and still protect the users.

For that, you need to use the right encryption so that users don't have to
change their passwords in the next days, but have 5+ years for that.

And yes, I see that you are promoting dedicated authentication services (which
would do it right), it just looks strange to me there.

~~~
cpt1138
You're absolutely right, what I meant is that its not _just_ about using the
right algorithms and making sure they are implemented and used correctly. It's
also a whole host of other things including avoiding SQL injection, CSRF, XSS,
data leakage in logs, proper access and provisioning, following and reacting
to the constant stream of security alerts (case in point: the MySQL Ubuntu
issue that cropped up yesterday).

------
16s
The point about insiders is often overlooked but just as plausible as an
outright hack. A rogue sys-admin or coder who is trusted and has access to
file-systems and DBs can leak or sell data and might even get away with it
without ever being caught.

~~~
alainbryden
I imagine there's all sorts of motivation for this too. A dishonest security
admin or consultant for LinkedIn might have had no traction in convincing
managers that they should pay him to upgrade the security system. I can see
rogue programmers contriving leaks like this just to give themselves more
work.

------
hello_asdf
The trick that I've found works is to use a password that I can remember on
sites like Facebook. It's the only site I'm likely to log into on my phone.
GMail should be a random password though, but it can be stored on your phone
so you don't need to remember it. Everything else that doesn't require mobile
access use a random password managed through a program like LastPass. If
you're thinking about logging in to sites like your email from a public
computer or something, well you shouldn't do that anyway.

------
Paul_S
Solution: delegate authentication to experts - use OpenID.

