Bit.ly compromised – More Details
blog.bitly.com
blog.bitly.com
Are they saying the passwords were hashed with MD5 before January? Because that'd be a bit scary.
Also I still see people now and then arguing that salted md5 is perfectly secure and that using a slower hash or any hash at all either doesn't add value or actually harms value. So they may not know better, or they may know better and simply not care.
Do you have evidence to support this?
I wouldn't say that security is considered a waste of time.
It is, however is a trade-off[1] between money, time, and other resources, things that, generally speaking, start-ups tend to be short on.
I worked for a startup that provided multifactor authentication using biometrics (amongst others), and almost all of our business came after publicized (and not publicized) breaches, from both large and small firms.
Maybe my comment was a bit too biased and hyperbolic, but I've certainly encountered that attitude.
Actually, a browser add-on to load commentary/annotations for known tutorials on the fly might be nice. All sorts of practical problems that would have to be overcome, though (like changing content and getting people to use the add-on in the first place).
Poke around w3schools. That should give you more than enough initial grist for your mill.
I'm hoping that all they've done is use bcrypt(salt, HMAC-SHA256(salt, pw)) to get around the bcrypt 72 character limit. However, using scrypt would have been better.
Intuitively it seems like you'd still need to guess the bcrypt portion, making it no worse than just bcrypt.
I'm kind of happy about that now.
My guess is that logins probably help bitly track usage patterns, improve the product, and keep an eye out for ways to increase their value by measuring engagement with their userbase. Maybe it was just "everyone's adding a social layer" peer pressure. Not sure.
There are security costs to "use passwords everywhere, for everything," but they are more diffuse. We've ended up with a system where security best practices would recommend using hundreds of distinct passwords that are each too complex to memorize (so you can dump them in a locker or support one login services, each creating a single point of failure, or you can use a similar password or mental password algorithm for each site, it's all tradeoffs).
I don't think there's an obviously better solution, I think it's just a tragedy of the commons we were probably inevitably going to trip over sooner or later.
Also, you'd have to see a massive amount of value in not signing up to Bitly to offset the hours you'd spend creating a vastly inferior hack job on your own.
All I'm claiming is that bitly could have offered stats without a login system. IFTTT was just a proof of that concept, a gratuitous example, not some idealized form of stat tracking that everyone should run out and implement.
You're probably right that the solution I thought of in around ten seconds sucks. I've spent more time on worse ideas. My real point is that login systems, despite their ubiquity, have their own share of downsides. Some of these downsides should be painfully evident today given the article.
It's quite common for a company to want to use their own identity portal for employee authentication with a particular piece of software and a few companies implement this via giving users shortened links which resolve to the identity portal location. They will hardcode the request to bit.ly & then give the users the token to enter when the software starts. It will then send the full bit.ly request and get a destination location back for the portal.
In every case I've seen this, I've written it as a high risk finding since neither the software vendor nor the company using the solution has ever done an audit of the security controls at bit.ly or the other link shortening services. If a link shortening company like bit.ly is compromised & a bad guy is able to modify link destinations then it's pretty much over in terms of security for a software solution implementing this model. There also tends to be some issues in terms of implementing public key or certificate pinning when using a third-party but I'll save that for another day.
For companies, marketers, etc, bitly, and other url shortners provide data and analytics ontop of the links, allowing more insight into link shares & clicks.
When you're interested in tracking the data from a link, or series of links, having a persistent account is necessary.
When bit.ly goes down, what happens to all their links?
Unfortunately, sometimes brevity is a necessity.
edit: original comment mentioned twitter, then I remembered twitter automatically reduces a URL's chars to 20 or so.
(that only answers the HN part, I'm guessing that is much of the reasoning, I don't know it for a fact)
Essentially this will serve as a wake-up call to the Bitly guys and hopefully they'll take some steps to deploy this stuff via CM or similar in the future.
It seems like a bit of a strange way to manage sensitive information, but not really any worse then a lot of other things I've seen.
[1] https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series [2] https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
I'm always hesitant to have source code with hard coded passwords, I know at some point you have to have them "somewhere" but anything you can do to reduce attack vectors for them is helpful.
What do people think should be best practices for storing sensitive configuration data? I know some people will have just a config repo with very limited access but that still seems dangerous at scale when that ends up being a lot of people etc.
If someone could make git store all on-disk data in encrypted form with an ssh-agent-like solution for on-the-fly (de|en)cryption, that would seem ideal.
You could probably roll your own. A decent middleground would be to keep the data in the central repo encrypted, but keep it decrypted on the engineers' workstations. Though a better approach is just to not check in sensitive values at all.
"Don't check in sensitive values" is not an option. Credentials must be kept track of and maintained somewhere. Storing them in an ad-hoc manner without version control doesn't just invite trouble, it demands it.
We have password managers for desktops and mobile devices. We need an equivalent for servers that accounts for the fact that the credentials must be highly available, multiple people must be able to use them (whether or not they get to directly view them), some of them will be technicians with limited training following someone else's procedures, and regardless of knowledge and skill, there will be half-asleep people taking emergency actions at 3AM when shit has hit the fan.
For more day-to-day stuff, environment variables on the server are an option. If you want to be able to provision a new server 100% automatically and keep the credentials out of source control, you have a few options. You can add a quick interactive phase to the deploy script, wherein the engineer must enter the key manually. Or the engineer could enter a value which is then passed to a KDF.
I'm honestly curious. I've never seen startups that aren't security startups hiring a security team. Is this a real team or just their developers doing an extra job?
Reality, of course, is that most companies don't give much thought to security at all until it bites them in the ass, and security competency is rare enough that even a designated "security guy" could be worse than useless.