There is an important update from the Bitly Account Users from the Bitly Team. The Bitly Team is having some strong reasons to believe that Bitly account credentials may have been compromised; however, they have no indication at this time that the user's account has been accessed without permission.
Whenever a service provider is having some suspicion of account compromising incident, it is better to take precautions. In the same manner, to play safe in the cyberspace The Bitly Team had proactively disconnected any connections one might had done with Facebook and Twitter to publish the posts by using the URL Shortening Links using bit.ly or bitly.com . Once can safely reconnect these accounts in the next login.
"Those accounts are connected but the Bitly Team had disconnected the rights to publish to these accounts. To start republishing / to ensure the security of your Bitly account, the user must do the following steps:
- Go to Your Settings Profile tab and reset your password.
- Go to Your Settings Connected Accounts tab to disconnect and reconnect any Twitter or Facebook accounts. If you have any connected applications, disconnect and reconnect through the third-party application.
- Go to Your Settings Advanced tab to reset your API key. If you are a developer using your API key, copy the new API key and change it in all applications. These can include social publishers, share buttons and mobile apps.
The Bitly Team had already taken proactive measures and steps to secure all paths that led to the compromise and had ensured the security of all account credentials going forward. Rarely companies provides the insight that how the compromise happened. But the way The Bitly Team is taking it ahead is an interesting step to watch out. And to learn for that how to perform the incident response.
In one of the blog, the Bitly Team shares the insights as:
"On May 8, the Bitly security team learned of the potential compromise of Bitly user credentials from the security team of another technology company. We immediately began operating under the assumption that we had a breach and started the search for all possible compromise vectors. Over the course of the next few hours, the Security Team determined with a high degree of confidence that there had been no external connections to our production user database or any unauthorized access of our production network or servers. They observed that we had an unusually high amount of traffic originating from our offsite database backup storage that was not initiated by Bitly. At this point, it was clear that the best path forward was to assume the user database was compromised and immediately initiate our response plan, which included steps to protect our user's connected Facebook and Twitter accounts.
We audited the security history for our hosted source code repository that contains the credentials for access to the offsite database backup storage and discovered an unauthorized access on an employee's account. We immediately enabled two-factor authentication for all Bitly accounts on the source code repository and began the process of securing the system against any additional vulnerabilities."
The way Bitly Team initiated their security assessments and later launched the proactive measures in itself hints that they are having a robust documented approach for carrying out incident handling and incident response plans in case of cyber security breach. The way Bitly Security Team had worked and provided the insight is applaudable.
Looking on to the some of the security measures implemented since the breach incident information received by the Bitly Team are:
- Invalidated all Twitter and Facebook credentials.
- Rotated all credentials for their offsite storage systems.
- Enabled detailed logging on their offsite storage systems.
- Rotated all SSL certificates.
- Reset credentials used for code deployment.
- GPG encryption of all sensitive credentials.
- Enforced two-factor authentication on all 3rd party services company-wide.
- Accelerated development of our work to support two-factor authentication for Bitly.com
- Accelerated developmet for email confirmation of password changes.
- Added additional audit details to user security pages. This can be seen from the Security tab. This provides all the detailed logging e.g., the IP address of the last login, revoking shared account, adding shared account etc. alongwith the approximation in hours of the actions taken (say, 5 hours ago, 8 hours ago, ...).
- Updated iPhone App to support updated OAuth tokens.
The interesting part is that they had stored the passwords as salted and hashed. Generally, the larger organizations do claim that they had stored the passwords as salted and hashed but later on when the hackers expose the hacked/ stolen information on the Internet, it is found that the credentials were instead stored as a plain text. The very case that comes in mind is the Microsoft India Store Account Hack case. Here also, the Microsoft India informed to all the Microsoft India store users that the passwords were encrypted, hence, their is no loss of data. But when the hacker opened the details in a public forum along with the screenshots of the database it was observed that the user's credentials (e.g., passwords, credit card numbers etc.) were stored in as a plain text. Hence, this part is yet to be seen that whether the company Bitly had really stored the passwords as salted and hashed or not.
According to the Bitly Team's Blog, if someone had registered, logged in or changed the password after January 8th 2014, the password was converted with BCrypt and HMAC (Hash-based Message Authentication Code) using an unique salt. However, if someone had not logged in since 8th January, 2014 then their account was hashed with MD5 - a big security risk!!
According to TechTarget article titled "MD5 Security: Time to migrate to SHA-1 hash algorithm?" dated May 2010:
"...hash algorithms create a short, fixed-length hash value to represent data of any size, it means that there are far more possible input values than there are unique hash values. This means there have to be multiple input values that will produce the same hash value. This is known as a collision and for a hash function to be deemed cryptographically secure and collision resistant, it has to be hard to find two inputs that hash to the same output. In March 2005, two researchers created two X.509 digital certificates with different public keys but with the same MD5 hash; since then various methods have been published that can find an MD5 collision in under a minute. This is why MD5 is considered cryptographically broken and is being replaced by the SHA-2 family of hash functions."
[Ref.: http://searchsecurity.techtarget.com/answer/MD5-security-Time-to-migrate-to-SHA-1-hash-algorithm]
Hence, MD5 security is certainly not suitable for security-based applications and services. Hence, if someone is having bitly.com account then the user is encouraged to login immediately and change their passwords so that the risk factor because of MD5 hashing is eliminated.
Read more about BCrypt from here (Wikipedia), and HMAC from here (Wikipedia) and here (RFC 2104 from IETF).
