Slashdot Mirror
Changing Customers Password Without Consent
risinganger writes "BBC News is reporting that a customer had his password changed without his knowledge. After some less than satisfactory service the customer in question changed his password to 'Llyods is pants.' At some point after that, a member of staff changed the password to 'no it's not.' Requests to change it back to 'Llyods is pants,' 'Barclays is better,' or 'censorship' were met with refusal. Personally I found the original change funny, like the customer did. After all, god forbid a sense of humour rears its ugly head in business. What isn't acceptable is the refusal to change it per the customer's requests after that."
Today I forgot my Hertz Gold Club membership (comes with the job) password. Guess what button I got to press...
"Email me my password"
I said no... no... it'll be a new password...
And what did I get in my inbox now 2 minutes later...?
I cringed like hell.
...that neither the submitter nor the editor (samzenpus) are able to spell the word 'Lloyds', despite it appearing a number of times in the original article.
Let's petition CmdrTaco to banish samzenpus to Idle, where his delusions of adequacy will better fit in.
Tubal-Cain smokes the white owl.
Mr. Yorkshire Bank Plc Are Fascist Bastards was able to get a judge to order Yorkshire Bank to issue him a cheque payable to his full name.
--
E_NOSIG
The same thought occurred to me, however would you trust an operator not to make a typo or know e.g. the difference between its and it's; would you even trust their internal system to be safe from an SQL injection?
Me lost me cookie at the disco.
I just love the hypersensitivity out there. I was on a project years ago where there were duplicate records on companies. One fellow that I worked with wrote a drag and drop application to eliminate duplicates. The user would drag the "good" record over an icon for the good company record and drag the "bad" record over the icon for the bad company record. The good company icon was a building in white with a halo over it and the bad company icon was a building in red with horns. I told him that someone with no sense of humor is going to tell him to change the icons. Sure enough, he was told to change the icons so as to not potentially offend someone's religious faith.
The customer does not own his password. As its purpose is to allow access to the services the company provides it is the property of the company. Of course changing it like that was a stupid and childish thing for an employee to do.
"The rules seemed to change, and they told me it had to be one word, so I tried 'censorship', but they didn't like that, and then said it had to be no more than six letters long."
I would have then asked for it to be changed to bollox and then proceeded with increasingly vulgar suggestions. Fanny would be a good choice.
Me lost me cookie at the disco.
My former ISP mailed me my password in a letter (on paper!) in big black letters every time I changed it.
-- Cheers!
They have a total disregard for security by allowing the support staff to read the passwords.
The customer support people there have a horrific culture of ridiculing their customers. Nasty.
I've had more than one website email me my password if I hadn't logged in after a week or two. Because obviously I wasn't logging in due to having forgotten the same password I use at half the websites on the internet, rather than the site sucking. Suffice to say, I've deleted my accounts at all sites where that's occurred. I wouldn't be at all surprised to see several of them vulnerable to SQL injections and I'm sure all of them did nothing but flip the 'account_active' column bit, but I felt better for a few minutes at least.
Wordpress has a pretty good forgotten password system - it emails you a unique link (something like changepass.php?user=firehed&verify=asdf903jfo2i3jf) and you get your new password form. It's never revealed in plaintext. I hope more sites adopt something along those lines - seeing my password in plaintext anywhere always freaks me out a bit. Then again, I've seen it hashed as md5 and sha1 enough times that I could spot probably my account in a 'SELECT id, pass FROM users' result.
I'm still a bit curious as to how banks haven't yet found a better system for getting you your initial ATM PIN when you get a new card than simply sending it separately from the card. Shouldn't they have some automated dial-in where I punch in the auth code they send me and the last four from my SSN (or MMDD birthday, whatever) as a verification code? If someone is stealing your mail looking for a new card, it wouldn't be difficult for them to also grab that 'discreet' envelope with that starter PIN.
Security is really quite pathetic these days. No wonder we keep hearing about millions of customer records being lost.
How are sites slashdotted when nobody reads TFAs?
Your banking auth code isn't necessarily stored as plaintext in the DB. Amazon has my credit card number stored, and I'll be damned if it's in there as 3723-7... I mean, yeah. Anyways, it's in there via a 2-way encryption algorithm - functionally identical to how SSL works, even if the methods involved are completely different.
Now of course I have no way of knowing if they store the phone-in verification codes in some sort of encrypted form, but just because someone at the bank can read it doesn't mean it's STORED as plaintext, it just means it's NOT stored after being put through a one-way hash (md5, sha1, etc). But that's just as true in your bank's DB as on Slashdot's as on that cobbled-together inventory logging system I made a couple years back for a small biz project. If you didn't have a hand in building the system, and said system isn't open-source, you just have to hope and assume that they've done things with a reasonable degree of security. (FWIW I did encrypt the passwords in that thing, even if the rest of the system was clumsy as hell)
How are sites slashdotted when nobody reads TFAs?
Everybody knows passwords. We're all used to them. But they suck rather miserably for real security. They are a vast improvement over nothing at all, but they just aren't good enough, anymore.
All it takes is one leak of your password, and you're hung. Worse, you don't know that you're hung. You can't let somebody else use your password. Ever. You can't ask a family member to enter it in for you while you're on the road while they look up your bank balance on the way to the airport without disclosing your password.
And lots of people can see your password. Techies. Poorly-paid tech support people in India. System administrators. Clerks, counters, janitors, and people who dig up your stuff out of the pile of computer hardware behind XYZ large firm.
Passwords are a terrible, terrible idea for security, and have left the social environment highly vulnerable to vast compromises.
On the other hand, dual-key cryptography is rather good for security.
It doesn't matter who sees the key exchange. If somebody else gets your public key, it doesn't weaken the strength of your private key. Nobody else can see your private key. You don't need to disclose your private key to anyone to use it.
Personally, I'd like to see a password-key machine. Basically, a weak form of dual-key cryptography (at least as effective as a password) stored in a small doohickey. It has your private key. Rather than type in a password, you are given a set of characters that you need to encrypt with your doohickey. You type the characters into your doohickey, and indicate which private key you want to use. (since it's private, you really only need one)
You enter in the passphrase for your private key. You enter the response back into your website, whatever.
Weaknesses? Not many.
1) You can lose your doohickey. At which point you need to get another one, regenerate a private key, and hand out new public keys to everybody. But even with the doohickey, $RandomBadGuy can't do much without the passphrase. Which is not a "password" in the usual sense because it's only stored there, in the doohickey and cannot be seen by anybody else.
2) You can use your doohickey thru the phone. Your son-in-law is checking your bank balance for you, and you want him to - this time. He sees the challenge, and tells it to you. You enter challenge into doohickey, give him the response, and he types it in. That gives him nothing more than a login that time, because next time, the challenge will be different, and without doohickey, he can't do anything more.
3) Nobody else sees your private key. It's yours. It's private. Websites and such will have your public key, but it won't help them any since they don't have the private key that matches.
Doohickey doesn't have to be much - it could easily fit into a cell phone. Processing a small, 32-bit key isn't difficult, and the challenges don't have to be very long to well exceed the security of your average password. (EG: Wife's middle name, the street you were born on, etc)
I have no problem with your religion until you decide it's reason to deprive others of the truth.
What hacks me off the most is that where I work (defence contractor) we have to have baseline encryption on our entire laptop drives and a second encrypted area for the more sensitive stuff. USB drives have to be encrypted as well, and PDA type (so ipod's phones etc) devices can't connect unless you are in the priviledged few who need to share data with external agencies or with our test systems.
(My personal laptop (the one I'm typing this on) I've got my own encrypted linux filesystem on, only the windows bit isn't encrypted and bar photoediting its not used much)
Why if we have to jump through various hoops or lose our supplier status can't the UK government departments and contractors working directly on their behalf do the same? (And ditto for banks.)
Everyone involved with handling personal data needs to look into data minimization and data protection (integrity, access control, non-repudation, auditing, the whole shooting match), and any company found not doing so should be banned from handling personal data ever again. Government departments are harder to control (after all the MPs won't vote in a law which would neuter the IRS ;) ) - so make the law such that the minister and the civil servant in charge of the affected department face a 1 month jail sentance for every 100 records lost, loss of pension rights, barred from being company directors etc...
--- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
My bank asks me the jth and kth letters of my password and never (and corresponds regularly to tell me so) asks for my complete password. Whilst this suggests they they do have the plain text stored on their system, could one devise a system that encrypted each letter of the password in some way that did not compromise the security of the stored hashes any more than the original hash?
Assuming a "strong" 8 letter password and two letters for verification it means that there is a 1 in 676 chance of a client guessing correctly in a single operator/client session. Not an unreasonable risk given the securiity that could be built into the session to avoid brute strength attacks.
I am having a bit of a think about it and I can think of a couple of techniques, but I am not sure that they are worthwhile. For example;
Just store the all the encrypted pairs (NC2) where N is password length, assuming 8 characters, only 28 combinations. Can these be stored without compromising the crackability of the whole password? I guess it would but by how much is a bit beyond my thumbnail calculating ability. Or;
Can we build a sufficiently strong transposition cypher so that we can compare specific letter positions encrypted without knowledge of the other letters?
My other bank uses SMS messages with one time codes to do verification. That seems to be very effective.
"The first thing to do when you find yourself in a hole is stop digging."
Actually, LTSB verification involves being asked for (three, I think) letters from your password / passphrase. I believe that the operator has no access to the letters involved --- they are prompted to ask for three and eight, type them in, and now know what they are. If you don't know, they don't either: the letters aren't displayed to the operator. Online, you supply a username (which is related to you, not to your account) and password, and are then prompted for three characters from a passphrase as pull-down menu items (presumably to make key-loggers a little less useful). The telephone and online systems use different passphrases.
Now of course this isn't flawless: there are a lot of attacks one can envisage, mostly involving operators always asking for different letters --- ie if they already have three, five and eight, and are prompted to ask for three, five and nine, they ask for four, six and nine, supply three and five from their previous knowledge and now have six letters instead of the four they would otherwise have. By this technique they can get the password in n/3 attempts, less if (as is likely) you don't need all the letters to see what the whole word/phrase is. It's a thin attack given the chances of you arriving at the same operator, or the operator's confederate, that many times, but might be possible as a large conspiracy by a corrupt call centre (LTSB have in recent months re-on-shored all their call centres; make of that what you will). If you fail to authenticate, for whatever reason, you're asked for the same characters next time, so an attacker cannot make repeated attempts hoping to be asked for characters they already have if they don't get a favourable set the first time.
Some things about this story don't ring true, by the way. Firstly, LTSB have not, to my knowledge as a customer, had a limit on the length of pass phrases either for telephone banking or on-line banking as short as is claimed. The on-line `memorable information' (ie password) is six to fifteen characters, spaces not permitted, and I can't believe the voice system is different.
There are some things that could be improved. You can change the greeting between given name, given name plus surname and a few other options, but you can't have a custom greeting. That's a powerful phishing prevention mechanism: if I can customise my bank's website to greet me, after supplying my password but before supplying my selected characters from the passphrase, with a picture I supply (say) then that massively ups the problems a phisher faces. I have my passphrase as six random characters (ie knowledge of five doesn't provide the sixth) so that if I'm ever asked for character seven or greater I know something bad is happening, but it's not ideal. But the rest they do well: initial contact URL is https and won't work as http, ie http://online.lloydstsb.co.uk/ doesn't answer, so anyone bookmarking it will bookmark the https. Menus don't accept keyboard accelerators. More if I could think of it before my first coffee. I checked it through pretty thoroughly before signing the ts and cs, and I'm reasonably happy.
ian
That is actually one of the schemes that I use. I have a keyword that I use to generate the password for all websites; I concatenate the keyword and the site's domain name and use an hash of that and allow Firefox to store it. That way I get a different pwd for each site yet I can regenerate it if I need to.
So basically every single operator they've ever employed, can find or just remember your username _and_ password if they want to. And who's to stop them from calling after hours and pretending to be you?
And you don't see the problem yet?
How about: when you tell that guy your password, he types it on the computer, which compares it to a hashed (and salted, please!) value in the database. There we go. It wasn't that hard, was it?
Of course, now when you talk to an operator, you tell them your password. So now we're back to problem 1, albeit with less people having access to it.
So, better yet, how about making you type it on the phone pad? Then their PBX can extract any such keypresses and send them directly to the computer. There is no need for the human operator to ever hear or read that sequence.
So basically, you can jolly well stop pretending that crap security is anything else. Yes, it may require some 5 minutes of thinking to solve those problems, but they _are_ solvable.
This kind of thinking inside the box (basically, "it's been done so before, so I guess we'll have to do the same"), and throwing your hands up in defeat each time it requires more thought than applying verbatim what you already know, is the real problem with security nowadays. Most people don't even bother trying to think about what could go wrong, and how (if at all) it's preventable.
A polar bear is a cartesian bear after a coordinate transform.
even then it should never be in plaintext.
hash it, the operator asks for the pass, types it in, it's checked against the hash and if it matches it's correct.
People reuse passwords too much for this to be safe .
As long as you have access to something that can generate MD5 hashes (any system with OpenSSL or GNUTLS installed, including any *NIX machine, any Mac, and some Windows machines) you can trivially regenerate your password. If you wanted to use the same password for mybank you would use hash of 'mybankpassword' which is '4281a3b1440b23b1106655dfeb849057'. Given either of these, it's very hard to recover the original input. It's a bit easier if you know that the format is {site name}{password}, but you could easily do something different, like interleave the letters, giving the hash of 'pmaysbsawnokrd'.
I am TheRaven on Soylent News
Source
You better watch out, there may be dogs about . .
Fragile assumptions are the building blocks of society.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Imagine your password is 'password.'
I don't have to imagine - after a recent spate of account hijackings to send spam, I ran a check and found 127 users with passwords of "password". This is a case where I reset their passwords without talking to them first as well as imposing some requirements on the passwords. It annoyed the call center, but it's better than getting blacklisted for spamming.