Amazing that even within the last decade a site as large as LinkedIn could be storing unsalted passwords. How does anyone fail at this in the modern era?
You may have some kind of logging / tracking / analytics somewhere that logs request bodies. You don't even have to engage in marketing shenanigans for that to be a problem, an abuse prevention system (which is definitely a necessity at their scale) is enough.
Storing unsalted passwords in the "passwords database" is uncommon. Storing request logs from e.g. the Android app's API gateway, and forgetting to mark the `password` field in the forgot password flow as sensitive? Not so uncommon.
Yes, it's easy to fuck up. But a responsible company implements mitigations. And LinkedIn can absolutely afford to do much more.
If the method works, and it shows that the logging feature Fred got so much credit for is storing passwords, what are the political implications of that? Can our intrepid middle manager steal some of Fred's glory? Or is Fred an ally and it should be carefully handled? Or do they sit on it and wait until an opportune moment to destroy Fred?
This is the kind of reasoning process I think goes on, because I've seen very few large organisations make actually-good technical decisions.
Are their psychopaths and Machiavellian schemers in management? Certainly. Are they the majority? Almost certainly not, unless you're working for absolutely the wrong company.
As the Brits would say, "cock-up before conspiracy."
And unfortunately, a lot of people aren't emotionally intelligent enough to recognize that many managers use emotional reactions to redirect the room away from them. Because if you're the angry one, people won't ask questions like "didn't someone mention the possibility of this to you 6 months ago?"
I don't really agree with that, but let's say I do. Middle management is a unique position where their sensitivity is a bigger liability to everyone else. They have some power, but not a lot. They ironically have higher visibility in the company than upper management. And the job requires 0 technical understanding of what they manage.
So that puts them in an awkward position that is often abused. If they feel someone is going to get in trouble, they will make sure that's not them, which is a terribly common instinct. When a developer tells the company there is a problem to address that could threaten the product, that's a good thing that should be welcomed. Instead, many middle managers see that developer as the problem.
> Someone who can't factor that into their actions and communications is frankly lacking basic social skills.
No argument there.
If your logging is on an obscure enough endpoint (password reset flow in the Android app's API gateway), you may forget to add that endpoint to the bot, just like you may forget to mark it as sensitive in your logging system.
At this scale, the developers working on these esoteric endpoints might not even be aware that such a bot exists.
It does have some challenges in introducing a read-before-write to fetch the session key at the start of the session, but given the relatively low call volume of such flows that might be a small price to pay to simplify security audits and de-risk changes to any service in the call chain.
Unfortunately my understanding is that it’s trivial to implement unsoundly but it’s also not something for which there are an abundance of good implementations across languages.
It’s been awhile since I’ve looked though so maybe there is a newer, less radioactive approach. But yes, never actually sending the authenticator itself (and doing so in a way that the proof is valid only once) would stop this sort of thing cold.
So yeah, LinkedIn have never been exactly a bastion of IT Security.
And if you decline, it asks you again. Two times using different wording.
I was not only talking about that though, but also that they can build shadow profiles and recommend people to you that way.
On a related note, I no longer have an active linkedin account.
It did allow me to cheekily run a SQL GROUP BY once to see what the most common passwords were, though. Top password was actually "trustno1" IIRC, followed by all the usual suspects, e.g. abcdefg, 12345678 etc. (there were no meaningful password rules)
Most probably some ancient legacy mainframe or whatnot other integration that nobody really has the time and budget to clean up and migrate to something more modern.
The larger the company, the larger the risk for ossification of anything deemed "business critical" because even a minuscule outage of one hour now is six if not seven figures worth of "lost" time.
It’s really just been a similar problem as with AI code, that without strong and competent management that can set intelligent expectations and requirements and test for them, you will surely get what appears to all the business and leadership types like an equivalent product, without any sense that it’s slop underneath the surface.
They just went into retirement?