
TalkTalk customer Schadenfreude...
Mine has just evaporated, now I know my own ISP also engages in equally cretinous practices...
Contrary to password storage security standards, BT-owned Plusnet is still delivering plaintext strings back to forgetful users, and seems to have no plans to tidy itself up any time soon – despite years of warnings from security experts and the advice of GCHQ. Plusnet has stated that it "goes to great lengths to ensure we …
Actually, they *must* store the plaintext password. This is because they use BT's wholesale ADSL network, which requires CHAP for PPP authentication (RFC 1994).
With CHAP the plaintext password is not sent over the wire; but instead you must possess the plaintext password at both ends. Storing a hash of the password would be no good, because then you would be able to authenticate using the hash; the hash itself would be as good as a cleartext password.
However, that is no excuse for their systems revealing the cleartext password, either to staff or users themselves. It should be pushed down to the RADIUS servers using a write-only mechanism. If a customer forgets their password, then staff should be able to change it but not reveal it.
Probably the reason they don't do this is because it would also require the user to change the password stored in their ADSL router, which is a support headache. They should consider using a different password for ADSL authentication than the one used for accessing the portal; the latter could of course be hashed, and used to reset the former.
Finally, there is another reason they use cleartext passwords, which is to authenticate a user phoning the call centre. They challenge the user by asking them to give (say) the first and last letters of the password, and this requires the individual characters of the cleartext password. It's worth remembering that many banks and utilities use the same practice.
> It would appear that Demon users also have a common password for their ADSL and their mail account.
Complete bollocks.
My mail password is not the same as my ADSL password and while we had web space the password for that didn't have to be the same either.
Given the weirdness of the claim I've just asked two other Demon customers that I know (Radio 3 joke goes here) and they confirmed they also have different passwords for each.
AC because people get whiny when called out as wrong.
"Complete bollocks."
Thank you. I checked before I posted. I have three passwords logged for my Demon account that has been running for nearly 20 years. They are for my ADSL/POP3, the old FTP, and the old webmail.
Trying to navigate the Demon home pages is a pain. Apparently no up front "login to your account" to change all details. I remember at one point they changed the password validation rules and my old password was no longer acceptable. It seems I missed an opportunity to separate the two passwords. I will investigate.
> Not sure why they need any password for ADSL authentication, it's a point to point connection over a landline.
A wholesale connection aggregates a whole load of DSL sessions down a single pipe, and offers them to the customer (i.e. the ISP) as L2TP, which is essentially PPP tunnelled over IP.
The original BT wholesale service "IPStream" service doesn't include any indication of the physical location of the originator in the session. So the username and password is the only way you have to identify the customer who is generating the traffic - and therefore to configure the session appropriately, e.g. to give them a static IP address if they have one, and to work out which users are generating the most traffic.
Newer wholesale services ("IPStream Connect") *do* provide an indication of the customer line in the session, and the network is slowly being upgraded, but the remoter exchanges are likely to stay on IPStream for a long time.
Talktalk's wholesale network similarly is able to identify your line, as long as you are connected to one of their own DSLAMs, and so for some of the customer base the username/password is ignored.
Paul Moore wrote:
To be fair, Plusnet's overall approach to security is one of the best in the industry.
I'm afraid it isn't, despite at least 7 years of complaining by customers their POP3 and SMTP mail severs still only support plain text login.
So if you check your email from a mobile device...
If you type in your previous password on Google, it tells you that you changed your password x months ago. I realise this is automated and more of a creep-out than a security risk, but it shows they store your previous passwords, and as they are subject to every petty legal request it emphasises the need for unique passwords everywhere, all the time.
I don't think it necessarily follows that they're storing your old password.
If I understand you correctly, it simply means they record when it was last changed.
It *might* mean they are comparing hashes of your current and old passwords, but that doesn't require them to keep the password itself.
Doesn't mean they can get at them. A one way hash can confirm you entered (in all probability) an old password without it being reversible. This is quite common and nothing to worry about for most use-cases. Obviously don't ever let Google have the password you use for your bank though...
"Obviously don't ever let Google have the password you use for your bank though.."
Bank? Bank? I don't need no steenkin' bank. Not since SWIFT and then the DWP both stopped paying me. Have you ever tried to explain the need for personal privacy and password security to prisoners? They don't get it, and they kind of have a point.
I was spilling my work history to a famous, decent political blogger earlier today, trying to make that point, and they said "Did you see the Snowden piece that showed they were double dipping into SWIFT. How'd they manage that, any idea?"
"
Basically, you're either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you'll probably be fine if you pick a good password and don't respond to emails from ChEaPestPAiNPi11s@virus-basket.biz.ru. If your adversary is the Mossad, YOU'RE GONNA DIE AND THERE'S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they're going to use a drone to replace your cellphone with a piece of uranium that's shaped like a cellphone, and when you die of tumors filled with tumors, they're going to hold a press conference and say "It wasn't us" as they wear t-shirts that say "IT WAS DEFINITELY US," and then they're going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them. In summary, https:// and two dollars will get you a bus ticket to nowhere. Also, SANTA CLAUS ISN'T REAL. When it rains, it pours.
"
https://www.usenix.org/system/files/1401_08-12_mickens.pdf
"Mossa'ad talk a good game"
Fair comment, I believe the quote was indirectly aimed at the NSA and GCHQ.
There are things in the Snowden revelations that honestly nutty conspiracy theorists used to claim, and I'd bat down with "No, that just isn't technically possible yet", or "No, someone would have found that out if it was true" or "Why would they do that when they could do this?".
And I was wrong. I don't want to be defeatist or alarmist, some things seem to work today even against APT, like properly implemented encryption, and there are 'best practices' for techies and best advice for non-techies (like ProtonMail and Tor) but basically we as individuals are "attached to another object by an inclined plane, wrapped helically around an axis".
I'm increasingly anti-ISIS, I've pals missing since the attacks there, but I still recognise my own government policy has killed more Britons in the past decades than they ever could.
You are quite correct, I trust Google to have salted and hashed my old password. My point is I still use a variation of that password here, and if the NSA were to get my old Google password then soon they'd be able to discredit me here through silly posts. And I just got my bronze badge!
Its quite a standard practice in systems that you cannot re-use passwords over a certain period or number of changes, if you turn that feature on. We used to set it to can't re-use any of the previous 30 passwords and forced changes every 2 months or so. Annoying users got a 39 character password minimum with and expiry date of 3 days - you have to get your laughs somehow.
"Its quite a standard practice in systems that you cannot re-use passwords over a certain period or number of changes"
As is the quite standard user response of using the same basic password and simply incrementing a suffix (or appending the current date) to generate an endless series of different passwords that, in your mind, never change.
At least one championship football club also stores your password in plain text. Recently they sent an email to all account holders to let them know tickets where for sale online.
"The details we have registered for you to buy online are:
Username: xxxxxx@yyyyyyy.co.uk
Password: AaaaBbbbCccc
Thank you for your support."
They appear to have at least not done this since but the fact remains they still store them in plain text.
Reminds me of a quote on bash.org, wherein a user would attempt convince fellow chat room users that the programme was sophisticated enough to hide plain text passwords typed into chat.
Always wondered if there was anything real on bash, or if it was all made up. Probably the latter.
Do they still exist?
Plusnet has stated that it "goes to great lengths to ensure we protect and secure our customer data"
This is simply a lie. You just cannot claim that you go to 'great lengths' to ensure xyz if you do not adhere to well known and widely accepted practices. Surely, in a case such as this when the organisation has actually been advised of the deficiencies of their approach (so even hard-to defend ignorance is no longer and excuse) and instead of saying "oops, we'll fix that ASAP, thanks for bringing it to our attention." they prefer to justify their original poor choices, making the statement "we go to great lengths" is actually fraudulently misrepresenting the services they sell?
> You just cannot claim that you go to 'great lengths' to ensure xyz if you do not adhere to well known and widely accepted practices.
Absolutely. OTOH, adhering to well-known and widely accepted practices - whilst the right thing to do - is scarcely "going to great lengths" either; it's "going to straightforward and routine lengths". Doesn't sound so catchy, though.
PlusNet accounts have the same password for the webby bit "Membership Centre" as they do for the ADSL/FTTC dialup connection.
If an ISP wants to run an automated line test for a customer's connection via BT OR then they can send the end user's username and password to BT's system and they (BTOR) use that to get their system to connect and hence test the connection, bypassing the end user CPE (Customer Premises Equipment)
That's almost certainly why the password is in clear text. The obvious solution is to have a separate ISP account for end users with salted/hashed passwords and a different password for the dial up bit.
Go blurry eyed and do a Google search on my own root password when I am not using it to log into all my other online services. So far it has not come back with any results, unlike 'Huge Cock Transsexual Anime'... that gets lots of results which seems to indicate an affiliation between Google and PornHub, so I think I am fairly safe. Obviously my root password is not 'Huge Cock Transsexual Anime' coz I kept missing out the extra S so I didn't changed it and still have to suffer Google pointing out I cannot spell Transsexual every time I want to visit PornHub.
What you are partially referring to in this article is more, the pci-dss standard...
Im sure even the 'plaintext' password is somewhat transmitted over HTTPS? (SSL / TLS) or at least I hope so, otherwise it wouldn't be pci-dss compliant.
'Rainbow tables' comes to mind when talking about supposedly 'one-way' hashing and salting using commonly available/commercial crypto... which is not too hard to decrypt such hashing / salting, so it doesn't really make an ounce of difference to the 'knowledgeable'...
Next, CESG would advise businesses to use publicly available FIPS...? Or would that be a step too far?
'Rainbow tables' as an argument against hashing / salting. Lots of big words and acronyms there, but you my friend have literally no idea what you are talking about! I mean Wow man, least informed comment here.
At my previous [corporate, well known name] employer, the IT department subbed out some employee website or other to an external provider, which needed a username and password. Lots of folk didn't realise that it was an external provider (it wasn't made obvious) and used the same username and password they used for the corporate Windows setup. Then after a little while someone with a clue (someone outside IT) forgot their password and asked for a reminder. The password came back in cleartext in an email, no security checks. The Windows domain password. Neat eh?
IT department management were notified and their response is summarised here as "Where's the problem?"
I had this argument with them some years ago and told them I'd offer my services as an expert witness to their customers for free if they were ever compromised. Not sure if they still do it but they were utterly adamant.
Encryption. Keys in accessible places else I wouldn't be able get your system to show me my password, think about it.
"go back 10 or 15 years when the internet was still a fairly naive place and plaintext passwords were probably more common than not"
I'd dispute this. Some of the hashing algos used might have been sketchy but it was never common practice - and certainly wasn't known/agreed best practice.
I was invited by the Job Centre to go to one of those Trinity Street in Stoke, type places to learn how to write a CV. They had a standard password for their Windows Office system and at the end of the session you had to send your CV to the teacher so she could go over it. All the CVs remained on the system for an unknown time.
I tried telling them the system was not secure but they couldn't understand me. It wasn't that they didn't believe me but that they did not understand. I jacked into some lads CV and tried to inject humour into it but in those days I was... Well I still am a shit.
Hmm, so you "*really really* don't want to be a PlusNet customer if that's your approach to security"
.... yet when asked if you want the cancellation line details to cancel your service.
You *really really* didn't want to leave. Because despite the security concerns, you still were happy with the service.
Indecisive much?
Boring. And old.
This is being done by many major websites already that run call centres (if you've ever been asked what X character of your password is... TADA!). This is nothing new.
Now what would be much more interesting would be some real reporting. Passwords on a website is nothing compared to the number of vulnerable routers out there.
I wonder how many ISPs have vulnerable routers out there that they aren't patching?
I can bet that would be a much more scary report. And no ISP would be safe.
I used to work for a more respected ISP than most and they to stored passwords in plain text, in fact the internal system was web driven with very little protection/verification I could have very easily have harvested all customer credentials and then deleted or changed accounts with a few lines of perl.
The issues were raised and pointed out and deemed to hard to fix right now. I doubt after being like that for a decade they have been fixed recently.
"When a web site is able to 'remind' you of your password by emailing it back, that's a symptom of very poor security practices."
Ironically the Register did this the last time I forgot my password. I still have the email containing my password in clear in the body of the message.
This post has been deleted by its author
To make it easy they present a box filled with the user name and (obscured) password ready to accept
On the off-chance you're serious...
That's your browser filling in the information. It is not sent by the server.
Vic.