26 Sep

Mark Story – Using bcrypt for passwords in CakePHP

CakePHP uses salted sha1 hashes for passwords by default, and has for a while. There has been some talk on the mailing list lately of switching the default hashing to something more secure, such as bcrypt. I think this is a great idea, and will find its way into CakePHP in a future release. Providing a reasonanle upgrade experience is the biggest problem to solve, if the default hashing strategy was to change. One option is to silently upgrading passwords. I’m not a fan of this approach as it has more room to go wrong, and possibly corrupt data. Another option, allowing developers to stick with sha1 if they have passwords hashed with it is a safer and probably better overall option.

While bcrypt is not part of CakePHP just yet, I wanted to see how difficult it would be to start using bcrypt today. Turns out it was pretty simple. Getting bcrypt working only required a subclass of FormAuthenticate and a two line change to the User class.

via Mark Story – Using bcrypt for passwords in CakePHP. Awesome, I tried doing this in CakePHP 1.3 a few weeks ago but couldn’t get it to work right all the time.

23 Jun

Should I Change My Password?

ShouldIChangeMyPassword.com has been created to help the average person check if their password(s) may have been compromised and need to be changed.

This site uses a number of databases that have been released by hackers to the public. No passwords are stored in the ShouldIChangeMyPassword.com database.

via Should I Change My Password?. I’m safe at least at the moment, how about you?

16 Feb

Ars Technica – Anonymous speaks: the inside story of the HBGary hack

So what do we have in total? A Web application with SQL injection flaws and insecure passwords. Passwords that were badly chosen. Passwords that were reused. Servers that allowed password-based authentication. Systems that weren’t patched. And an astonishing willingness to hand out credentials over e-mail, even when the person being asked for them should have realized something was up.

The thing is, none of this is unusual. Quite the opposite. The Anonymous hack was not exceptional: the hackers used standard, widely known techniques to break into systems, find as much information as possible, and use that information to compromise further systems. They didn’t have to, for example, use any non-public vulnerabilities or perform any carefully targeted social engineering. And because of their desire to cause significant public disruption, they did not have to go to any great lengths to hide their activity.

Nonetheless, their attack was highly effective, and it was well-executed. The desire was to cause trouble for HBGary, and that they did. Especially in the social engineering attack against Jussi, they used the right information in the right way to seem credible.

Most frustrating for HBGary must be the knowledge that they know what they did wrong, and they were perfectly aware of best practices; they just didn’t actually use them. Everybody knows you don’t use easy-to-crack passwords, but some employees did. Everybody knows you don’t re-use passwords, but some of them did. Everybody knows that you should patch servers to keep them free of known security flaws, but they didn’t.

via Ars Technica – Anonymous speaks: the inside story of the HBGary hack. Apparently it’s not too hard to hack a world renowned security company.

11 Jan

Electronic Frontier Foundation – EFF Calls for Immediate Action to Defend Tunisian Activists Against Government Cyberattacks

Demonstrations and protests over unemployment and poor living conditions have been ongoing in Tunisia since the beginning of December, but last week the Tunisian government turned up the heat on bloggers, activists, and dissidents by launching a JavaScript injection attack that siphoned off the usernames and passwords of Tunsians logging in to Google, Yahoo, and Facebook. The Tunisian government has used these stolen credentials to log in to Tunisians’ email and Facebook accounts, presumably downloading their messages, emails, and social graphs for further analysis, and then deleting the accounts entirely.

via Electronic Frontier Foundation – EFF Calls for Immediate Action to Defend Tunisian Activists Against Government Cyberattacks. Umm, wow, glad I don’t live in Tunsia.

13 Dec

Forbes – The Real Lessons Of Gawker’s Security Mess

Despite this, they do not really seem to be acknowledging the scale of what happened. They still try to put some blame back on users, suggesting that if they had a weak password they might be compromised. Well, that really does not make much of a difference when you expose the entire database table and have way too much faith in the 34 year old encryption algorithm reported to be used to safeguard the data. In truth, they had over a month to find this problem but diagnosed the early warning signs in November improperly, were very obviously breached (and told they were breach by others) on Saturday, and it still took until Monday afternoon to say anything to their user base. And in the meantime their representatives were releasing statements via Twitter up until Saturday evening that were either partially or totally incorrect.

via Forbes – The Real Lessons Of Gawker’s Security Mess. Basically whatever bad/stupid thing Gawker could have done they did including ignoring the problem. Perhaps their lowest moment comes when accounts of their users are posted on an internet forum and their response is well, who cares it’s “just the peasants”.

In perhaps a good example of don’t write it if you wouldn’t want someone to read it, this screenshot from the attackers showed up on thenextweb.com, detailing a conversation from July 22nd between internal Gawker employees noting that usernames and passwords for Gawker users had shown up on 4 chan. In the chat, Gawker’s Hamilton Nolan, after hearing that it is just Gawker users who have been compromised, remarks “oh, well. unimportant”. Gawker’s Richard Lawson wants to know if the breach is limited to “just the peasants?”

Hopefully this is another in the long list of reminders to use secure, safe passwords, perhaps more importantly use a tool like 1Password to generate random passwords for every site you log into.

11 Dec

PEEBS.ORG – An Open Letter to Mint.com: Stop storing my bank credentials!

I love Mint.com. They have spectacular visual design, a great product, an entertaining and informative blog, and a great iPhone app. I know tons of people who love Mint.com, and yet, when surveying my digital life with a critical eye, I know of no greater security risk than Mint.com. It’s still astounding to me that Mint could grow from a small startup to being acquired by Intuit in the space of a few years and essentially retain unlimited liability by storing user’s logins and passwords to their entire financial lives. Yikes. If I were turned to the dark side, I would immediately attempt to hit Mint for their millions of users credentials which provide me completely unfettered access to their accounts, most of which are not FDIC insured. This means that when someone hacks Mint, they’ll be able to pull out all of my money, transfer it, etc., and I’ll be responsible because from the financial institution’s perspective they aren’t liable for me entrusting my credentials to a third party.

via PEEBS.ORG – An Open Letter to Mint.com: Stop storing my bank credentials!. I know all this, that Mint is an obvious security hole in keeping my personal digital life secure but I keep using them. What does that say about a company which I recgonize as a security hole in my life but I keep using them? The author is right though, people desire the abilities and tools Mint provides but the banking institutions really need to provide a third party authentication solution like OAuth which grants Mint and other sites read only access to the data.