Currently viewing the tag: "security"

Why you never store passwords.

By On · Add Comment

So earlier someone wrote this

The whole “never store plaintext passwords” really means “never store more than you need.”

The sad truth is, that it doesn’t mean that.

1st, no system is absolutely secure. Any developer who tells you otherwise is either 1) an idiot, or 2) a damn big idiot.

2nd, for alot of people, emails are their life. With access to their email, one can do ALOT of things. For example, take over their lives. Storing their passwords that have a chance of being the same as their email ones is putting them at risk of losing control of their lives.

3rd, you should salt, then hash the passwords with something that is cryptographically secure, such that it is difficult to re-generate the password.

4th, we as developers (and tech founders) have to remember that

it is our responsibility as web developers to ensure that nobody, not even us, could get a clear-text version of the user’s password. (link)

With this in mind, we do not ever store passwords, no matter what the purpose of storing it is. And users will do well to remember not to give out passwords easily, not even to facebook to find your friends. And that, was the basis of my previous post on SGE.

If there are people who still cannot understand the seriousness of this issue, then I give up explaining. Feel free to throw your passwords around to all the web services. And good luck, when the service that you gave your passwords to finally gets hacked.

And for all those who

call themselves ‘Technical Founders’ because they mistakenly think that being able to write HTML and basic PHP is “I can write OMGWTFBBQ l33+ code, I know everything that is IT”

Good luck :)

Response to Dropmyemail’s response

By On · 6 Comments

Wrote another article for SGE on why using Dropmyemail may not be the best idea around and here’s my response to their response.

In truth, there is nothing different from what Dropmyemail does and when Amazon stores credit card information along with the CSC.

…

Certainly one can do more damage with a credit card than someone’s email credentials. In addition, Dropmyemail’s privacy policy is standard like all e-commerce websites that require personal information to complete transactions or services. Also, their privacy and security policy will also state that they are not held liable for any loss of information – do read the excerpt from Zalora:

Yea, except that you are storing passwords that people might be using elsewhere too. That sure is higher up the ladder than storing what I bought. And I think that warrants alot more when you are expecting people to hand over their passwords to you.

Dropmyemail partners with Amazon Web Services to back emails on their servers. Amazon S3 Server Side Encryption employs strong multi-factor encryption. Amazon S3 encrypts each object with a unique key. As an additional safeguard, it encrypts the key itself with a master key that it regularly rotates. Amazon S3 Server Side Encryption uses one of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256), to encrypt all data.

So basically the application doesn’t handle any of the security. The storage provided by AWS is what’s handling the security. So, the hacker just needs to get a way to massage the app into doing what it wants and it can do anything it wants. Including reading all your emails. And passwords. Remember. From this response, they are basically telling you they outsourced the security to AWS’s S3. And when the data is in the app, it is completely decrypted.

First, autoforwarding emails to another email provider does not prevent hacking

Yea, neither does backing up your email with Dropmyemail.

Second, autoforwarding emails also do not prevent email outages where many email inboxes were not only unavailable, some were even emptied

Haiz, seems like I need to explain this again. I have my email on gmail. I forward my email to outlook.com. When GMail goes down, I still have my emails over at Outlook.com.

Third, Dropmyemail even protects emails from accidental deletes and backsups the drafts/sent folders as well.

Fourth, If our users suffer any setback to their emails, with one click we can restore their email inboxes.

This basically means that your emails will nvr be deleted. And that means to say Dropmyemail has a whole list of your past emails that you might think you have deleted.

In extreme situations, even trustworthy and established multi-national corporations like Microsoft/Google are susceptible to mistakes.

Yea, but at the same time, they have security teams beefing up the security of the systems. Let’s look at the team behind Dropmyemail. I supposed to assume that those 3 tech guys can do a better job than Google’s or Microsoft’s security team?

Plus, one last reason to use GMail or Outlook to backup your email (use that one that is not storing your personal email). See this? Outlook.com is providing you unlimited space and GMail is giving you 10GB. As for Dropmyemail? A measly 2 GB.

P.S. Check out these features of Outlook.com. It’s quite interesting.

[Update]
A reader and friend reminded me, it’s not just about the password. It’s about all the services you linked to your email account too. With access to your email, they can now help you reset passwords, gain control of your life ;) Something to think about? I sure think so.

[Update2]
For those people who think that storing passwords is fine. Well, here’s a post you should read. The Dirty Truth About Web Passwords

Blackberry DevCon Asia

By On · Add Comment

DevCon Asia was one of the best developer events I’ve been to. Serious. Aside from the free Playbook, which I’ll do a review on some other day, DevCon was really well organised, and as one of the guys behind GeekcampSG 2011, I have to say I was blown away by the event, especially the party (that said, i think the geekcamp guys did a great. i’m guessing DevCon Asia had a budget hundreds of times more than ours, hence they could pull off a real party. regardless, they’ve set a new bar for developer parties, and conferences in the region had better learn from them.)

Went for 6 talks in total, and out of these 6, 2 were really impressive.

The first one was “Developing Well Behaved Apps: Requirements, Considerations and Ideas”, where they talked about the common programming pitfalls that would lead to excessive battery consumption. And it turned out that if you really go and do thing the proper SE way, it will consume ALOT of electricity. Just because we do not handle some things does not mean that they do not exist. Things like polling, timers and listeners take up alot of electricity. Object creation is fast, to the developer. It comes at a hidden cost though, when it’s garbage collected, and that takes up electricity too. Memory accesses take up electricity as well. So we have to seriously consider how we code our apps, as the world becomes more and more mobile, and more devices run on batteries.

The second one was “Secure Your App with Secure Coding Practices”. While I have always been a fan of secure coding, that talk really opened my eyes to coding securely. I think all coders should learn a thing or 2 about security.

Ok, that’s it for now, hopefully I’ll have enough energy to blog again soon.