KCOM-owned Eclipse FAILS to cover up the password 'password' A Register reader has exposed another privacy howler at KCOM - this time involving its Exeter-based ISP Eclipse Internet, which displays passwords in plain text to users via a webpage. Customers who log in to their personal Eclipse user site are somewhat surprisingly shown the password for their account. Today's tip of the …
You think that's bad? My boss thought it a good idea to buy a domain name from Eclipse, they charge £100 per year for a .com domain! I've tried to move it away from them several times and given up because they insist they will blank the records before transfer, leaving us with no email, website, etc for some time.
If this is confirmed, I'd say Eclipse Internet deserve everything they've got coming to them.
Anyway, a domain name should take 24 hours or less to switch. Couldn't you do it anyway and publically put the blame where it belongs when the site comes back up? Give existing customers advance warning of an outage perhaps.
Hmmm, not sure what plan your boss bought but I have a handful of domains with Eclipse - a mix of .com and .co.uk. Domain registration only no hosting or email etc*. I think I pay about £8+VAT per year per domain - renewed for two years at a time.
If you're being charged £100/domain/year I suspect you're getting more than just a domain registration. It sounds more like a SOHO or SME web/email hosting package.
[*I use their redirect function to redirect web visitors to those domains to the actual website hosted elsewhere]
Indeed. It's not like they have any excuse either. Pretty much any server-side language worth its salt (heh) is going to have some kind of readily available Digest library. This could be fixed with.. well, I'm no huge expert but I'm reckoning less extra lines of code than I have fingers.
Keep on 'em, Reg. You wouldn't want to miss the inevitable massive hack attack. I'm wondering if they even sanitise dirty data? They going to get intimately familiar with Bobby Tables soon?
All they needed to say is "Oops, cockup, sorry, we've fixed that now". I would respect the company, and wouldn't rule out using them.
But the response "We havn't done anything wrong, everything is fine" makes me think they don't care, and so I won't be using Eclipse again.
Well played Mr Spokesman.
Whether advisable or not, a good number of people leave their browser to auto-complete login pages with usernames and passwords so it is entirely possible for an account holder to login in without knowing/remembering what their password is.
That however is no excuse for displaying the password once logged in.
For example, your broadband connection password, which is *not* the same as your Eclipse username password.
Why it displays the password for your user information (i.e. when you log into the interface and look at your own user details) is a security failing, considering that THAT password gives you full access to the Eclipse account.
No, the point is that it means they have stored the passwords in either plain text, or with a reversible hash. It's not ok. Not only should they not show the password, they should not be ABLE to show the password. It should never be stored anywhere - just the (non reversible) hash of it should be stored.
@SP
I logged into my Eclipse account this morning and the passwords were obscured by **** on the User admin screen shown in the article.
That doesn't mean they've rectified the more serious issue of storing passwords in Plain text or reversible hash, but the more visible problem of showing them in clear text on the user admin web pages has been apparently solved*.
*At least for me YMMV
The password being shown isn't the one used to log into that page. The one shown is the main DSL password. Which was actually quiet handy for me once to be honest when my router last went tits up and I needed it last time without having to deal with tech support or go through the pile of paperwork to find out what it was. Anyhow, if you have access to that page and wanted to do any kind of damage, the password is the least of it as you have full access to cancelling, or altering what the connection is, or altering your bandwidth shaping as well, or purchasing no end of other things off them.
Ok, this is typical user friendliness v security, but in this particular case when needed, I did find it useful once.
Sorry Nya, but that's not true. It's not only the DSL password, but your user password too! If you log into 'My Eclipse', go to 'My Users', then click on your name. Your password (that you logged into My Eclipse with) will be displayed to you in plain text.
This is a major security failure. I've sent a strongly worded complaint and expect them to address this (and explain themselves) before I get in touch with the ICO.
While I can accept that displaying the DSL password is a good idea, from the look of that screenshot that's the account password and not the DSL password.
However I don't use their services so have no way of knowing for sure, but it's under the section "users" and not "DSL" or "modem".
+1 Nick Ryan and SP
The admin page shown in the article is the user administration page (My Users) so the password shown would be for your Eclipse online account accessed through the Eclipse website. This would also be used to authenticate other services like email.
The DSL password (that is entered in your router's settings for PPPoA or PPPoE authentication) is shown in clear text on the Eclipse admin pages (Connection Manager) but as already stated this isn't as big a deal (debatable I know but there is a case for allowing this to be shown). Showing the password for the user account is definitely NOT acceptable (again as mentioned/discussed already) and it is that which is at issue in this article.
Sorry SP but you seem to be mistaken. Just logged in, and the user passwords (all of them) are all hashed out even when logging in with the main admin account. The DSL password is visible, but the user accounts aren't at all. Although you can still change them from here using the admin account.
or somewhere similar. You know. Somewhere where the boss knows it all.
My case in hand (slightly security related) was a software project I worked on back in the 90s. When we upgraded from VB4 to VB6, we also made some changes to the INI file settings - transferring them to the registry. After I joined the project I noticed that they were being written to HKEY_LOCAL_MACHINE which was depracated under MS developer guidelines. The reason being that MS *security* guidelines, recommended that applications not be allowed to write to HKEY_LOCAL_MACHINE by default (you need admin rights).
This was when NT4 introduced registry security.
I flagged this up to my boss (who was a BA from Oxford) and when he heard it would cost x man-hours to correct, invited me to "go away". I did so, ensuring I had emailed him with my analysis.
Of course, you can guess the rest. We flogged the product (and associated hardware, which was what everyone really cared about) to a firm that employed IBM to run it's IT. Went to install the program - instant error. Couldn't write to registry. IBM advised their client not to install the software, since it didn't follow accepted guidelines. Cue shitstorm with sales and my boss. Cue boss trying to shit on me from a great height. Cue me producing email to boss (verified by *our* IT guys). Cue a grovelling apology.
Anyway, point being, I will bet there's a boss at KC who thinks security is a dirty word. Like work ....
It's good that you recognised the problem. Nowadays though,proving that you emailed the boss (so covered your a$$) isn't good enough in business. Your organisation still failed, regardless of fault.
That no action was taken means that either you didn't make the case clear enough to your boss (unlikely), or that you didn't try hard enough to raise awareness within other parts of your organisation.
We in IT must recognise when to go over our bosses' heads, or call a meeting with others to gain more support, or go direct to the Account with our concerns. It's harder to do and takes more effort and guts, but liek it or not that's what will make the business succeed rather than fail. Bosses aren't always right, and we in IT can't hide behind 'told you so' these days.
Hurts to say it, but it is true.
Moving from INI file to registry settings was the first mistake.
Step 1) Ask the Operating System where data files should be stored for your application.
Step 2) Write INI files there. Or even XML files, your choice.
Avoid the useless nightmare that is the registry at all costs. There are no real advantages to using it for most application purposes and it's best left well alone.
Want to be able to easily support your product? Simple with INI of other file based settings. When (not if) the computer goes down you can far more reliably and easily extract files from the file system than settings from the registry. Want to copy a customer's configuration? Easy, copy the configuration files from their system to yours. Want a user's configuration to follow them around the network? Easy, store them in their roaming profile (assuming that it's configured, but that's a different problem).
Another big security failing I get all the time is account information being sent to me which is obviously for another person - somebody entering there email address wrong when they sign up for a service.
Recently had O2, Vodafone, Charter etc. all send me logins, passwords, bank account information - you name it all because there sign up process doesn't first verify the email address.
I hate to break it to them but entering your email twice is not the same as verifying it.
As a security consultant, I repeatedly tell clients that their customer password should never be able to be retrieved even by the customer.
Look at Microsoft AD, it may have many issues, but even if you are the Domain Admin with every right across the whole AD domain you cannot view another users password, you can delete it, you can change it, but you can't see it.
It a customer wants to reset their password fine, they can input to old password and change it.
If they forget their password, have a temporary one time password sent back to them, or even have an operator generate a one-time password for them to use.
If a operator or call center operative can see a customer password you have an instant oppurtunity for fraud within the business.
However companies seldom listern to security people (even if they are paying massive consultancy fees), because security doesn't generate revenue, however if a marketing/customer experience person thinks it would be 'easier' for customers to recover they own password or have a call center agent look it up, then that becomes the norm. Of course when an incident take place it's not their fault it's an IT issue.
This will keep happening until some government has the balls to say that when a company has a security breach, the C-levels will be in the dock, looking at some time at her majesty pleasure.
Having just logged on to Eclipse to check out the revised users page, I discovered I'd created a User a *long* time ago to use solely for Eclipse Webmail. I couldn't recall the password, and I'm reasonably sure it wasn't 8 asterisks...
Anyway, the Webmail front end doesn't give any mechanism to reset the password, but fortunately the normal Eclipse site has a Forgotten Password link.
Ever helpful, that page tells me:
"Your password has been emailed to <user@domain>.
You should use the username and password we have sent to login."
Thanks for that Eclipse... Of course I guess I could just phone you up and ask what the password is...
Anonymous as I'd obviously never use the same password anywhere else ...
One thing that has bothered me, some Active Directory-based systems have these policies that are like "Not the same last x passwords, also not the last x passwords with minor changes." "Last x passwords" just involves storing the hashes and making sure they don't match. But minor changes, doesn't that mean it is in fact storing several old passwords in plain text?
Anyway, it's better that eclipse is now X'ing out people's passwords on this page. But I'd really like to know if they are still storing plain-text passwords (probably they are.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
