Dear Linkedin, [and proposed mitigation approach]

Rich Kulawiec rsk at gsp.org
Fri Jun 8 22:27:52 UTC 2012


On Fri, Jun 08, 2012 at 12:48:38PM -0700, Michael Thomas wrote:
> Linkedin has a blog post that ends with this sage advice:
> 
>  * Make sure you update your password on LinkedIn (and any site that you visit on the Web) at least once every few months.

Um, no.

If the site in question has security issues sufficiently egregious that
someone can obtain the hashed password table (particularly if it's one
that's unsalted...and I'm looking at you, LinkedIn) then we can presume
that any reasonably competent attackers can and will acquire it more than
once.  (That is, they won't post it publicly and ask for help...because
they don't need any help.  I strongly suspect that this is history,
not a prediction.)

Changed hashes between successive retrievals indicate account access
which in turn indicate live accounts which in turn indicate accounts of
higher value which in turn should mean that password cracking resources
(such as botnets and clouds) are best focused on those.

(Of course if the site is blithely allowing brute-force attacks ad
infinitum, then this gets even worse.)

And the process of "changing passwords" is fraught with its own issues,
particularly when done via portable devices...like, say, smartphones with
keystroke loggers installed.  CarrierIQ, anyone?  And what about (other)
malware resident on user systems?  Is it better (a) for a user to never
log into example.com, thus never presenting their username/password pair
for harvesting by malware or (b) to be compelled to log into example.com
every few months...thus given resident malware a fresh shot at capturing
this information?  (Information which, by the way, is probably in use
at other sites.)

Then there are the human factors: encouraging someone to frequently update
their password is contrary to encouraging them to select, memorize and use
a strong password.  Yet the latter is exactly what we want users to do.


One way to mitigate -- but not solve -- this problem is for sites to
stop retaining so much data: you can't surrender a secret you don't have.
Sites need to use a system of account expiration to purge their rolls of
disused accounts which no longer serve any purpose -- except to crackers
who may find that X's password from some site that X last visited in
2007 may be quite useful elsewhere in 2012.  This is a relatively simple
process to implement, and it's something that some mailing lists have done
for years.  "Your subscription is expiring unless you do the following
dance" doesn't work perfectly, but it's at least comprehensible to the
overwhelming majority of end users because it fits conceptual models
that they've seen elsewhere.

Of course this would mean that example.com would have to stop bragging
about its 4 million users and admit that 3.7 million of them haven't
been there more than once, thus its actual real live user base is
300K and won't the advertisers be VERY interested in that number?
So the question becomes: does example.com really, truly, want to try to
mitigate the risk to its users by aging out old and disused account data,
or does it want to try to keep its stock price propped up and make its
3Q numbers based on a user count that's largely fictional?

Yes, well, I'm being cynical but I'm also serious: there are
undoubtedly kazillions of completely disused accounts splattered across
a hundred thousand web sites.  Every single one of those that's deleted
incrementally reduces aggregate risk, and if they're not actually being
used, then there's no *technical* reason why they should remain.

As I said above, this isn't a solution: it's just mitigation.  But it
appears from this thread and many, many others over the years that we're
some way off from a solution, so can't we at least agree to do what we
can to shrink the size of the problem while we're arguXXXXdebating how
to solve it?

---rsk







More information about the NANOG mailing list