Kevin Ohashi Warning: Change Your Password Storage Policy or Be Publicly Named & Shamed | DomainInvesting.com

Kevin Ohashi Warning: Change Your Password Storage Policy or Be Publicly Named & Shamed

24

I read an article on Kevin Ohashi’s blog, and if you represent or work for a domain company, you better take notice. According to Ohashi, at least one major domain company is not storing customer passwords securely, and if this isn’t fixed by April 25, he will publicly name the company.

You can read the full details of the security threat on Kevin’s website, but the gist of it is that companies should keep client passwords encrypted, and he has noticed that one company does not appear to be doing so. This can put client accounts in peril, and if clients use the same password at different registrars, it can spell major problems.

I do my best to use different login information (user name and password) for each domain registrar I use. I know that no system is perfect, but account security is of utmost importance. Stolen domain names are expensive to recover, and that doesn’t include losses such as PPC/advertising revenue and missed sales opportunities.

I really hope Kevin doesn’t have to name the company that might have password issues, but if he does, let’s hope the company addresses those issues ASAP. It’s also a good opportunity for other companies to address their own password encryption system.

Thanks to Kevin for looking out.


About The Author: Elliot Silver is an Internet entrepreneur and publisher of DomainInvesting.com. Elliot is also the founder and President of Top Notch Domains, LLC, a company that has sold seven figures worth of domain names in the last five years. Please read the DomainInvesting.com Terms of Use page for additional information about the publisher, website comment policy, disclosures, and conflicts of interest.


Reach out to Elliot: Twitter | | Facebook | Email

Comments (24)

    DP

    The company should be named anyway. Even fixed after the event, this shows a complete disregard for customer security and/or extreme naivety on the part of their development team. It is a critical and unforgivable fundamental design flaw and 20 years of software development experience tells me it isn’t isolated within their systems. This is why they should be named.

    April 21st, 2011 at 10:53 am

    Sol

    Yeesh – companies that can’t even figure out simple hashing/salting to store passwords are fools.

    April 21st, 2011 at 11:10 am

    Michael

    I’ve been emailed my password in plaintext from Domaining.com several times without me even prompting it. If they are able to do that, it means the password isn’t hashed in the database. I wonder if there are others or if this is the one he’s talking about.

    April 21st, 2011 at 12:44 pm

    Jason Stewart

    Snapnames.com, an oversee.net company. Forgot your password? No problem, we will just email your username AND password to you in plaintext.

    April 21st, 2011 at 1:04 pm

    mrx

    cough.. Tucows, cough…

    April 21st, 2011 at 1:45 pm

    Hiutyarea

    Ko is a two bit hacker and thief. A legend only in his own mind, just like you.

    April 21st, 2011 at 2:00 pm

      Elliot Silver

      @ Anonymous Coward

      I’m not even a legend in my own mind.

      April 21st, 2011 at 2:01 pm

    Sol

    More than one? Yuck.

    April 21st, 2011 at 2:14 pm

    Acro

    Ethical “hackers” never threaten to name and shame over security matters. Kevin should know better than this, contacting the affected company by all means possible is the proper way to handle a security lapse. I did it with GoDaddy & Snapnames years ago; usually a “thank you” is the only reward and that’s the way it should be.

    April 21st, 2011 at 3:26 pm

    Jack

    I like how people just blindly believe other people without doing any research. So Kevin said if you receive your password in email as plaintext then its stored as plain text. This is absurd and down right dangerous filling heads of people thinking their password is stored in plain text just because they received the password in plain text.

    I might as well go ahead and setup an account on all major sites out there that give you a login and when I recover my password and it gives me my regular password without resetting it Im going to post a ridiculous article stating Im going to announce companies who are not secure.

    You can use a hash and a salt in the database, when you view the table for username and password you dont see your password in plain text, you see a hash and a salt and you dont even know which is the hash and which is the salt. Just an example if your username is whatever and your password is whatever1213 it could look like this in the table:

    username whatever
    fld1 32453gergtrgh76764gdfgefh565gerfg
    fld2 df546t576utrgwdwqerewrt

    Now you tell me if you see whatever1213 in there. Can you use programs to try to determine the password? Sure, the same goes for a md5 encrypted password.

    Dont believe me? Lets use Kevins example, when you use the password, password, and md5 encrypt it you get 5f4dcc3b5aa765d61d8327deb882cf99

    Now go to this site:

    http://www.md5decrypter.com/

    Put in 5f4dcc3b5aa765d61d8327deb882cf99 and guess what? It gives you the plain text password value for 5f4dcc3b5aa765d61d8327deb882cf99.

    April 21st, 2011 at 5:22 pm

      Elliot Silver

      @ Jack

      Why not take this up with Kevin on his blog? That’s far too technical for me.

      April 21st, 2011 at 5:26 pm

    Jack

    @ Elliot
    Sorry, just was reading comments on this post and actually wanted to post something real quick and the post got away from me. Sorry!

    April 21st, 2011 at 5:28 pm

    Larry

    Forgetting the mumbo jumbo for a second (I’m looking into that actually being curious) if I store 10000 passwords in an encrypted file then there is nothing to prevent me from writing a program to unencrypt the file, retrieve a password, email the password, and reencrypt the file. The key to the file can be stored off the server as well. (And not even considering what Jack above is saying I am taking a totally different approach to try and prove this theory wrong).

    So, simply being able to email back a password does not imply the password is not being stored securely. QED.

    Forgetting the fact that a password mailed in the clear is not good practice of course it appears to be a stretch to say that the fact that they email a password means that they don’t “store customer passwords securely”.

    So while he could be right that they are storing passwords in plaintext the fact that they email passwords doesn’t mean that they do that for sure.

    Consequently this statement is incorrect: “If they email you your original password, they are storing it in plaintext.”

    if..then so he is wrong just based on that one statement. Put the word “probably” in there and ok, I would go along with that.

    That being said as this is not my area of expertise I checked with a contact who heads up the security practice at a major firm that is a subcontractor to Verisign and he said “emailing the passwords does not mean it’s stored in plaintext” which of course is what Kevin is saying is happening. Not “probably happening” but “happening”.

    April 21st, 2011 at 8:07 pm

      Elliot Silver

      @ Larry

      Thanks for the insight on this. I am interested to see Kevin’s follow up, although I would hope any potential security issues are fixed before.

      April 21st, 2011 at 8:37 pm

    Kevin Ohashi

    Apparently people cannot read articles fully or grasp what I am saying.

    “They store passwords in plaintext or a system where they can get back to plaintext (which for all intents and purposes are the same).”

    If you CAN decrypt it, it’s not secure. Period. Anything two way shouldn’t happen with any web application. All the ‘its being stored in an encrypted format’ means, it’s using piss poor encryption which is two way, which is perhaps marginally more secure than plaintext but a farcry from what it should be to such a level they may as well be the same.

    @Jack: As far as md5 and decrypting, that uses rainbow tables. Which is why I talk about using Salt. If you add salt to passwords and then encrypt, rainbow tables fail (which is what your lookup website uses, I used a similar site to generate the hashed password). Proper encryption even with md5 will stifle rainbow tables with a unique salt.

    April 21st, 2011 at 9:16 pm

    Kevin Ohashi

    @Acro: I have talked to the company or companies. They are aware of the issue long before I said anything. I am putting this under responsible disclosure. The party or parties know, they have enough time to fix the issue. The public also has a right to know which companies don’t take their security seriously.

    April 21st, 2011 at 9:19 pm

    Acro

    Kevin – Good security and hysteria over it are two different things. If passwords are stored in plaintext (and how would you know that without messing with a remote server) then that’s an issue. If you’re basing your grading of their security level by the ability to retrieve passwords, that’s not necessarily an indication of a security lapse (Larry covered this beautifully).

    On the subject of deciding when the time has come to release the name of the company or details about the alleged security lapse, keep in mind that by releasing any information that might lead to a third party taking advantage of that information you are defining yourself as an accomplish to a potential crime. So the “right time” is – perhaps – after the issue has been fixed. Putting pressure and threatening to unveil names etc. is quite childish and immature on your part.

    April 21st, 2011 at 11:54 pm

    Mike

    @Jack

    Results
    Md5 Hash: e74a84ad29eee9f150d8d5b809e4d21a
    A decryption for this hash wasn’t found in our database

    So much for md5decrypter.

    April 22nd, 2011 at 12:25 am

    Kevin Ohashi

    Acro – Sorry, Larry did not cover it accurately. Passwords shouldn’t be recoverable to plaintext for a myriad of reasons (opens more attack vectors).

    I was also re-reading up on some crypto stuff and hit this gem from an expert cryptologist:
    “To begin, password storage 101: servers don’t usually store actual passwords. Instead, they hash the password, store the hash, and discard the password. The hash can verify a password from a login page, but can’t be reversed back to the text of the password. So when you inevitably lose your SQL password table, you haven’t exposed all the passwords; just the crappy ones.”

    http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

    Also updated my article to reflect later info that MD5 is weaker than SHA-2 and bcrypt.

    Enough time to fix the problem is given, NameDrive fixed their system in less time after actually getting exposed. Instead of waiting until a company gets hacked and MY information gets exposed again, I am going to disclose this information to them and give them the opportunity to fix it. And if they don’t, I will tell everyone, it would be irresponsible for me NOT to let people know that this/these company/companies aren’t taking their security seriously. These companies can seriously affect the livelihood of many domainers, they need to take proper measures to secure our information.

    As far as being childish, I suppose you come from a world where all problems get resolved with a whisper in the ear in the person in charge. Must be a great world you live in.

    April 22nd, 2011 at 12:27 am

    Gerty

    “is quite childish and immature on your part. ” This man definitely knows what he is talking about

    April 22nd, 2011 at 12:47 am

    Logan

    @Kevin – actually, I’ve found a polite email or fax to the CEO or General Counsel making them aware of the situation gets things moving along internally quite nicely.

    April 22nd, 2011 at 3:19 am

    Larry

    Kevin – I think it’s important to realize that the thing that I am (and some others are) reacting to is not whether it is more secure to lessen the attack vectors and follow the best security practices or whether it is possible that the vendor in question is storing passwords in plaintext which obviously is a bad practice.

    What I am reacting to is your use of hyperbole to make your point and how that is picked up by people (like Elliott who know nothing about security as he admitted) and repeated. And then believed as gospel.

    Your headline says “At least one major domain company is NOT SECURE” and “YOUR PASSWORDS AREN’T SECURELY STORED” which of course will bring more attention to your blog post (as it has) then if you said “probably” or “might be”. Same as Techcrunch and the evening news do every day. Personally I think that’s a good blog strategy (as do many others).

    In any case while your blog post contained, as they say, the “to be sure” statements the headline did not.

    The other thing I would be careful about is writing about things that you don’t really know that much about that you’ve only read about because you will have circles run around you by people who know more and loose credibility. I could tell from your “about” that there was no reason to believe you had any particular expertise in computer security and the fact that you said (above) “was also re-reading up on some crypto stuff and hit this gem from an expert cryptologist” seems to confirm that thought.

    By the way if all of this was as concrete as the “experts” make it out to be then the largest companies with all the money and time to design secure systems would get hacked much less. And we know that doesn’t happen. Not only are there are always tradeoffs that companies make (in addition to the screwups) but also the management that hires the security people doesn’t know enough to even vet the various options. In other words if you don’t know something yourself it is very difficult to know who is talking the best game. I’m sure you’ve seen this many times when non-computer people refer to you as “a computer guy” and assume you know “everything” about computers and the Internet.

    April 22nd, 2011 at 10:00 am

    Kevin Ohashi

    Larry,
    I am not an expert cryptologist. That doesn’t mean I don’t understand basic security practices. The source I quoted is talking about security 101, the most basic information. I have studied computer science and cryptology is an area I am quite interested in and an area I make an effort to stay up to date in. I understand basic security practices, hashing passwords fits under the most basic of security practices. The only part of my recommendation that changed is there are more advanced ways to encrypt your password which may add extra security (by increasing the difficult to brute force passwords). I would absolutely rather see any implementation rather than none, be it MD5, bcrypt, SHA-2 being used to secure my passwords. Any programmer worth their salt knows to hash passwords someway and that they shouldn’t be going back to plaintext. It doesn’t take an expert to notice the most basic gaping security flaws.

    Security is not something with concrete solutions to stop every attack. But certain basic measures go a long way. Putting a lock on your door dissuades the most casual of intruders. Putting a deadbolt and iron bars in every window deters even more people. Sticking armed guards in front deters all but the most confident or foolhardy. Not encrypting account password’s would be akin to not even having a lock on the door. It doesn’t change the probability of getting your user information stolen. It does however increase the difficulty for any attacker to make use of the data. Depending on the type of compromise situation it could stop them fully (SQL injection attack). If they gained full root and saw the entire encryption scheme with salt, they would still have to brute force each and every password which would take a lot of computing power (time). Which gives them more opportunity to notice, alert users and take steps to minimize harm done. In plaintext, there is no barrier, there is nothing to stop a malicious person from using that login information on the existing website or trying it for other websites (using the same password for paypal? your whois email address? escrow? something else important?). All I want is a decent lock on the password door, it’s very simple to implement and adds a much greater degree of security for my user data (the strongest password in the world stored in plaintext is as good as ‘password’, but hashed, it could take many lifetimes to break).

    Big companies make mistakes, hell, reddit stored their passwords in plaintext and got their database stolen. It was a design decision to store passwords in plaintext. A very regretful one.
    http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-a-database

    “The guys at Reddit are known for being smart. They thought they had a good reason for storing passwords in their database. They were wrong. If smart programmers can make this mistake, lots of programmers can. Do you think you have a good reason for storing passwords in your database? If so, you’re probably wrong, too.”

    I can show you article after article which will tell you, DON’T STORE PASSWORDS. This or these companies are. There is no valid argument for it, it’s easy to resolve and increases a user’s security an incredible amount in case they ever do get compromised.

    I also didn’t write this warning all willy nilly like people seem to think. I made an effort to alert relevant parties. I discussed it with people more knowledgeable than me (almost everyone said just call them out on it right away) before deciding to delay a bit and go this route instead giving them an opportunity to fix it with a little bit of public pressure but not being called out by name, yet.

    In conclusion, you can attack my character, credentials, motives but the fact of the matter is that the security argument is sound. I’ve already been called a ‘two bit hacker and a thief’ here and many other things over the years. I am a big boy, I can handle the personal attacks and ad hominem. I don’t care one bit about it because it doesn’t change the argument, but if it makes you people feel bigger, go for it, that’s your prerogative. All I want is my damn passwords hashed and I will make every effort within my power to make it happen. Sometimes, the issues get quietly resolved and nobody is the wiser, sometimes you need to scream at the top of your lungs and let the world know something is wrong. I tried being quiet.

    April 22nd, 2011 at 11:09 am

    Jack

    To clarify hashing and encrypting are 2 different things. Also proper password requirements are a useful tool as well, if you allow a person to create an account using a password such as pass123 or password or something very simple then your just making it easier for the hacker.

    In order to get to the passwords you have to hack into the db, if a hacker is able to hack into your db either by lack of server security or badly written sql that allows for sql injection, then you have more problems than just passwords.

    April 22nd, 2011 at 12:02 pm

Leave a Reply

Name *

Mail *

Website