While you can’t see your password, I can in the HTML

Saturday, December 19, 2009
By Richard Orelup

passwordWhile I was reading “The Usability of Password Blobs” by Bryan a little bit ago it hit me another issue that many developers don’t realize.  Most people don’t realize that even though your password is obscured on the page, it’s in plain text behind the scenes.

I stumbled onto this issue a couple years ago when we had purchased a new CMS solution for the University.   This CMS worked differently then most, instead of generating the HTML on the fly by pulling information out of the database, it sits on it’s own server and reprocesses the HTML and saves it to your web server.  We found this cool because then if you had a DB failure your whole website down and most of our pages are static content anyways.  It gave you 2 methods to publish content, save it to a local place or fpt/scp it to another location.

So me and a student begin playing on the system to see how exactly we accomplish this (it’s such a weird concept when your brain had it just as a given that their was a DB powering it.)  I told the student to just use their student web space to save the generated pages they made.  So I was poking along looking at things when I needed to setup my own connection to save my test pages.  I looked at the students to see what setting they had picked for something when I noticed the password field was filled in.  I though “that’s strange” so decided to view the source cause I wondered what they had put in so they would know you changed it.  Then I realized, there was her password in plain text to me.  This is bad, especially being that we use LDAP to authenticate everything around campus because anyone could see this and have access to everything the person had.  On top of that, this wasn’t even over https so anyone sniffing would have seen it as well.  I deleted her PW from the system and told her we would figure something else out.  We opted for creating mounts to our web server after I noticed the issue with the ftp/scp option.

So what does this mean for a developer?  Don’t ever give someone back their password.  There was no reason for them to give that information back to me.  Leave it blank and if there is new info that I enter take it and replace the old.  This also isn’t a password that should be seen ever by anyone because if this was to our live server someone could have access to our entire site behind the scenes and we most likely wouldn’t notice.  While you think you are being nice by auto filling something so they don’t have to you are leaving yourself open to possible security issues.

As well as a user you should verify that sites you are using don’t do this either.  Now just because the password is automatically filled in doesn’t mean the site did it because browsers will do this for you as well.  To verify for sure put your password in you should view the source and see.  If you see your password anywhere in the source, please email the service you are using and let them know they need to correct it.  You can even point them to me if they need some consulting on it.  :)

Thanks for reading and if you have any questions on this please feel free to comment and clarify anything I said.

Author Info: Richard Orelup

I have been PHP/Mysql developer for 7 years. I work mainly with YUI on the JS side when developing applications and I have been using jQuery on the standard websites. As well I have been doing a lot with Adobe AIR and Titanium for developing apps on the desktop side. I currently work at Valparaiso University and my personal web development is done under Mu Studios.

3 Responses to “While you can’t see your password, I can in the HTML”

  1. Bryan Redeagle

    Yes, this is a serious security issue in software that does this. And being a developer myself, it’s something that I avoid like the plague. Anyway you could let us know what CMS this is?

    Something I also do (as an addendum) is store passwords in the database as a salted hash. I take the password, attach the username to the end and then run it through an SHA1 hash. This makes it so that it’s programmatically impossible to retrieve the password without already knowing it. You can only match the resulting hash.

    As a bonus, storing hashes (which are always the same length) is far more efficient than storing variable length passwords.

  2. Cascade is the name of the product but I doubt anyone around here would ever run into it as it’s really expensive for what it is. I’d personally never recommend it to anyone but really doubt anyone would ever need to ask. It’s one of those products that Higher Ed peeps get stuck with :) The issue was fixed last I knew but they have been through 2 major version (which they seemed to push were full rewrites, as little sense as that makes) so it could have creeped back in for all I know. We don’t use that method anymore so haven’t checked recently.

    I do the same just with MD5. Never had a need to optimize my process on this one.

    The problem with that though in this case is that the password is needed and there is really no way around that. You should still always encrypt it and have a way to get it out in the case that an attacker gets access to the DB but not how you are encrypting it, but when you it needs that pass to login to another system there is little you can do to avoid that. Some protocols are using things like OAUTH which is great to get around this issue (like twitter) but when it needs to ftp into something there is little you can do to fix that.

Leave a Reply