Is this a security risk?

[bug_girl]

I have a question for those of you more hack savvy than I.

Our office uses a piece of vendor software [...] on the web.

I have always been uncomfortable that none of it is in https.
But, just recently, I looked at the page source to try to find a problem, and found something completely unexpected--my user name and password!
It's in some javascript at the top of the page--

std_vars = { user : "xxxxxxx",
password : "xxxxx",
somevar : "xxxxx"};

Egad! Should I be as freaked about this as I am?
Unfortunately, I'm the resident tech nerd, so it's up to me to figure it out.

Help!
Thoughts? I need a REAL tech nerd

Edited to add: all the data is stored on a remote server several states away owned by the vendor; it isn't retrieved from our office server.

[editted at bug's request - Terry]

 

[Molinaro]

If by "I looked at the page source" you mean that you used the 'view source' option within your browser, then yes.. big problem.

If on the other hand you looked at an offline copy of the source, then you have a smaller problem.

 

[Hellbound]

Well, if it's an active page, and you'd already logged in, it's not quite as bad, but still bad. If an active page then it dynamically adds that information into the page when you log in (active pages are created on demand, more or less) and sends the page to you. So, in theory, you should be the only one seeing that in your source.

However, since it isn't secure, someone could possibly intercept the transmission. Your password could be recovered by, say, anyone on the same network segment as you using a packet sniffer, or anyone on the same segment as the server. It is a security risk, most definately. Considering that https is not really that hard to implement, it suprises me that they wouldn't.

 

[bug_girl]

yeah. this is not the first time there has been a security issue, either.

We were having issues with a search saying it found [...] records, but not actually displaying anything. I thought maybe I could see the [...] records (or why they weren't showing) if I looked at the HTML using "view page source". Suprise! there was my login id and my password.

BTW, it's a ".pl" page (perl?)

It's the "in theory" part that bothers me, since a trace shows the active page goes through at least 18 different nodes before it gets to me. That's a lot of different places for eavesdropping.

[Editted at bug's request - Terry]

 

[skoob]

Also, since web pages are stored (for a limited period) in the web browser's cache, your password will be stored in cleartext on any computer with which you log in to that system.

So, if someone else uses your computer (and has read access to the browser cache) or you log in to the system using someone else's computer, they can read you password.

There's no reason (except incompetence) why the password should ever have to be sent back to you.

 

[Hellbound]

Also, since web pages are stored (for a limited period) in the web browser's cache, your password will be stored in cleartext on any computer with which you log in to that system.

So, if someone else uses your computer (and has read access to the browser cache) or you log in to the system using someone else's computer, they can read you password.

There's no reason (except incompetence) why the password should ever have to be sent back to you.

Good call here, I didn't think about the cache.

 

[bug_girl]

ooohhh. Good point about the cache.
Sigh.

*beats head on desk*

 

[Metullus]

ooohhh. Good point about the cache.
Sigh.

*beats head on desk*

Careful with your antennae, dear...

 

[jeremyp]

I have always been uncomfortable that none of it is in https.
But, just recently, I looked at the page source to try to find a problem, and found something completely unexpected--my user name and password!
It's in some javascript at the top of the page--

std_vars = { user : "xxxxxxx",
password : "xxxxx",
somevar : "xxxxx"};

Egad! Should I be as freaked about this as I am?

Damn right you should be freaked.

1. Your password is being sent in clear text across the Internet in both directions.

2. It's probable that the password is being stored in plain text on the server

3. Your password is being stored in your browser page cache.

4. Whoever wrote this page obviously has no clue about writing applications for the Internet. The correct paradigm (session cookies) is well documented in just about every Web Applications 101 book that has ever been written. If the coder can't get authentication right, god knows what else they've screwed up.

 

[jeremyp]

yeah. this is not the first time there has been a security issue, either.

We were having issues with a search saying it found student records, but not actually displaying anything.

This all supports point 4 from my previous message. The programmer was basically clueless and their cluelessness probably extends to the whole application. BTW, you could send your original posting to The Daily WTF. I reckon it stands a good chance of publication.

BTW, it's a ".pl" page (perl?)

Yes, but that's not necessarily bad.

 

[bug_girl]

Actually, I can't send it anywhere. If our university tech people found out about this, they would completely shut us down. one week before school starts. And no viable alternatives that could be up and running before a month or two. Very, very bad.

In fact, I could get in a lot of trouble if it's discovered I'm asking about this here, since I'm not supposed to say anything (boss' orders). I wanted to get a more tech-savvy opinion, since I can't talk to my sysadmin about how good/bad/neutral this is. My instinct was--it was bad. This seems to be the consensus here.

Next question--what would it take to FIX this?
If we had the vendor switch to SSL, that would solve the sniffing problem, and could probably be done quickly without major rewites. (other than updating non-relative links.)
The info would still be in the cache, but I don't know enough about SSL encription to know how that affects cache storage.
I'd really like to demand that this be fixed before class starts. I'd be satisfied with a SSL fix, but I'm not sure how long that would take to implement. We've gotten and installed a certificate within a week in the past, but we didn't have to change any code, either.

Man, I wish I still drank.
Maybe a vicodin.

 

[Hellbound]

Actually, I can't send it anywhere. If our university tech people found out about this, they would completely shut us down. one week before school starts. And no viable alternatives that could be up and running before a month or two. Very, very bad.

In fact, I could get in a lot of trouble if it's discovered I'm asking about this here, since I'm not supposed to say anything (boss' orders). I wanted to get a more tech-savvy opinion, since I can't talk to my sysadmin about how good/bad/neutral this is. My instinct was--it was bad. This seems to be the consensus here.

Next question--what would it take to FIX this?
If we had the vendor switch to SSL, that would solve the sniffing problem, and could probably be done quickly without major rewites. (other than updating non-relative links.)
The info would still be in the cache, but I don't know enough about SSL encription to know how that affects cache storage.
I'd really like to demand that this be fixed before class starts. I'd be satisfied with a SSL fix, but I'm not sure how long that would take to implement. We've gotten and installed a certificate within a week in the past, but we didn't have to change any code, either.

Man, I wish I still drank.
Maybe a vicodin.

SSL would take care of any possibility of intercept in transit. However, SSL only works between the network connections, IIRC the session layer of the OSI model. In layman's terms, once it's in a file on your computer, it's no longer encrypted. You could set the system to automatically clear the cache every so often (IIRC it can be set to clear the cache on log off), so that should take care of that issue (at least acceptably...someone could still access your info if they could access the hard drive while you were logged on, through the network, for example).

It really needs to be rewritten, both to utilize industry-standard authentication methods and to use SSL encryption for end-to-end communications. Quite frankly, it sounds as if either they have an incompetent web programmer (one who has not been trained or does not have the experience for this job) or they gave a web programming job to whoever wanted it, assuming "computer work is computer work". They either need to replace the original programmer (if this is, actually, part of the job he's supposed to be qualified for) or hire someone to do this type of work.

It is something that needs to be brought up, but I understand your reluctance. Sooner or later, this will be a problem. Likewise, the lack of attention to security in this area (as well as apparant lack of oversight and discouragement of anyone bringing problems to the attention of those who could fix them) leads me to suspect other areas where security was sidelined for no real reason.

Also, if your boss knows your concerns and has told you to keep quiet, that makes me a little nervous. If you have anything in writing showing where you voiced your concerns and were told not to say anything (even emails), I'd hold on to it. You have to protect yourself from all eventualities.

 

[kevin]

if using IE goto tools...internet options...advanced and turn on Empty Temporary Internet folder when browser is closed. That helps with the caching issue (kind of).

Make sure your password on this system is different from your password on any other system.

That's about all you can do on your system to mitigate problems.

If SSL were turned on with a real (not self-signed) certificate that would mitigate sniffing attacks and man-in-the-middle attacks between your comptuer and their computer. Additionally I believe most browsers refuse to cache SSL pages these days (I thought had an IE option for this but I can't find it.)

The real fix for this solution is implementing a challenge-response password system. There are several available that use MD5 to store passwords (mitigates insiders stealing passwords from the database), for example:

http://perl-md5-login.sourceforge.net/