This is a misunderstanding. The CS agent has access to a plaintext (security question) password that can be used under special circumstances. It must be readable to function.
My solution to security/recovery questions is to generate or make up ransom answers, and store the question/answer pair in the notes field of the entry in my password manager.
This kills the “knowing things about you” vector of phishing and impersonation and make it as secure as any unique and random password.
Absolutely. Like how many times has my mother's maiden name and the name of my first pet been leaked.
I hate the ones that don’t have a single objective answer. Like “name of your best friend in 3rd grade” or “city where you first fell in love”.
Or weirdly ethnocentric questions like “what’s your favorite food” with multiple choice answers like “spaghetti, pizza, hamburger”. Good thing everyone who recovers their password is American!
Or “what instrument do you play”, when multiple instruments I play are in the multiple choice list but only one can be correct. And what the fuck is the point of multiple choice security questions when anyone has a 1/10 chance of correctly guessing on any login attempt.
United Airlines is by far the worst major company I have ever seen in all of these and deserves to be shamed.
Those are the best! You're supposed to use a random answer like "cookie monster" or "flatulence"
If you're storing it next to the password, then you've killed the point of the recovery questions anyway. May as well not store them at all.
That assumes that there's no other way to get your password than by accessing the contents of your password manager. The service itself could have its passwords/hashes leaked, and people unfortunately do reuse passwords across services even with a password manager, so it's very plausible for someone to get your password but not the answers to your questions.
If that's an option it's usually what I do but often they're mandatory.
This is also similar to my solution, however not so relevant here.
The "password" here is only used over the phone in place of an account number or similar where a customer can't recall other information.
The reddit user here would have had to provide this password over the phone before to another agent. It's the only way for it to get there.
"What's your mother's maiden name?"
"42_red_banana_&"
This is why I choose random but plausible answers.
"Mother's maiden name? Cruz-Valdez"
"First Concert? Lil' Mermaid"
"City you were born in? Ubuntu"
The way I usually do this is with the random article button on Wikipedia, until I find something that sounds plausible.
1password team, integrate this feature please
Ditto. Have you ever had to use one? It's always a laugh.
CSR: What's your mother's maiden name? Oh wait, looks like an issue on our side.
Me: No issue. My mother's maiden name is Q5D6Erty#76cjWE1H. She's Dutch.
I did do this once, but it didn't really inspire confidence in the security of the whole thing.
Me: "ok, but it's some random text: Q 5 --"
CSR: "--yeah, ok, that's fine"
Since then I just make up a random, fake but real-sounding answer so the humans don't get confused.
I didn't realize I would have to say the answers over the phone when choosing the answers (and thought it would only ever be me filling them in online)
CSR: "What is your mother's maiden name?"
Me: "do you really want me to say it?"
CSR: chuckling. "Yes, I need you to say it"
Me: "Diarrhea"
The trick is to enjoy confusing humans and share the story of why when you get there. I went to the mall for the first time in a long time, every place wants to sign you up on the mailing list for a small discount. So they can email me at <Name of store>@mydomain this way I unsubscribe and if I see email coming to that address I know which store is the rat. They look confused, ask for 'a real address' well that is a real address I say, and here's why: ...
I get a little thrill every time.
How can you be sure that a targeted attack can't exfiltrate all available fields?
For the record, I don't have a great answer to this either -- genuinely curious.
You can't. I see that as a far lesser/more manageable risk than traditional security questions are though.
This is the login password. It was an unintelligable text with non alphabet characters.
Source: I posted that on reddit.
The easiest solution is to call them and ask why they have that password and why they can read it. They will verify everything I have already said.
Nice try, Toronto Hydro
I made no such claim. I merely have knowledge of the exact system in question.
Could it have changed since you last saw the system? Because the OP disagrees with you: https://news.ycombinator.com/item?id=41631791
No, the system was updated in August of this year.
I don't see why the security question answer has to be stored in the clear. If you have to give it over the phone, the agent can type it into a form field that hashes it and compares, just like a password on the site.
Because security question answer have high variability for the average user. They're asked say, what street they grew up on. Is it "S. Main St." "South Main", "south main", "south main street", etc...
Security questions in general are terrible so don't take this as if it's in defense of them.
My favorite are the presumptive ones that assume something like "Where did you meet your spouse?"
Someone should just go over the top: "Who was the editor of your first successful novel?" "What investment did you make your first billion with?"
My bank's list of security questions are almost all about your children or your spouse.
Other than two about your birth location and mother's maiden name, both easily found answers for someone
There's viral social media posts that do security answer farming with prompts like
"Your superhero name is the name of your pet + favorite teachers name"
You'd click on the comments and there's tens of thousands of people volunteering answers. Some are of part of the hustle to till the honeypot, but I'd see people I know comment on them with real information. It's wild
For some of us, finding our mother's maiden name is as simple as looking at our name, either because it is a hyphenated name or because there was a time when the government refused to acknowledge the existence of the father in certain cases.
It is very hard to come up with universally good security questions.
It should be web of trust.
You add let's say, up to 3 peoples names and mobile numbers for recovery and then they are contacted requesting to reach out to you to authenticate.
Something like
"You've been added to X's web of trust for account recovery at example.com. If X needs to recover their account, we may ask you to confirm with them that it's genuine."
Then something like
"X is trying to recover their account for example.com. Please contact them within the next Y days to confirm it's genuine and if it is, respond with the the 4 digit recovery code X gives you"
Then from x's side:
"Your web of trust has been contacted. Feel free to contact them now and give them the pin YYYY so they can confirm this is genuine"
This approach pretty elegantly addresses a number of security question limitations and existing 2FA infrastructures shouldn't be that hard to modify in order to implement it.
Probably my favorite feature of this approach is it requires the various security code social manipulation scams to be successful against 2 people instead of 1 which is rather statistically unfavorable for the scammer.
A lot of people don’t want their trusted web to know what websites they are looking at? Think Grinder/other dating sites, financial/crypto, pornhub, certain message boards etc.
Well don't use it for porno sites then or just give different personal email addresses for your web.
Also there's a 100+ year old workaround for that which used to be used in the postal service so people didn't have boxes on their doorstep with giant labels on it reading things like "Dildos Direct": Either leave the company name off or use some alias.
Including the company name is really just a user interface flourish to dealienate the feature
It's a security question to access information on the account over the phone. It's not used in the web based system, which is completely detached from the phone system.
What city were you born in: “Millwaukee”. The agent would be able to tell it was Milwaukee, but if he or she typed “Milwaukee” it’d go “bzzzzt” just because the user typoed the input initially at set-up.
It's still awful security. city of birth is public info
It’s just an example to illustrate a point. Coulda been “Starbux lovers” instead of “starstruck lovers”.
There's several alternatives to such an insecure system. That simply isn't the right way to do it.
Source?
Worked on the recent upgrade done in August.
Which really should not be the same!
This is actually more commonplace than you'd think. It doesn't seem to be updated anymore, but there is a web site that listed such services:
Toronto Hydro isn't just "a major utility company"
It is entirely government owned and the largest electricity provider in the province.
It’s been a while since I’ve lived in Toronto but I’m pretty sure neither of your points is correct.
I believe you’re thinking of Ontario Hydro, though it looks like that’s been privatized and/or split up.
https://www.toronto.ca/city-government/accountability-operat...
Happy to be corrected though if I'm misreading this!
There was this alleged Alberta AHS privacy breach:
https://old.reddit.com/r/alberta/comments/1c7lk3z/ahs_privac...
Don’t know if that went anywhere… anyone know?
Is Reddit considered a news source now? Half of the posts on the front page are made up fictional writing, and the other half are politics and repeated questions, for the purposes of karma farming.
How do we know that the OP of this post did not make these claims up?
Based on the wording alone I would believe the OP had thr experience they claim. They just misunderstood what was being asked.
I've never designed a system that needed to be secure, nor have I been tasked with breaking one, but...
Is plaintext really that much worse than hashed/salted/whatever storage? If the user generated a hard-to-guess password, then the user is also unlikely to reuse it. If the user generated or reused a memorable password, then it would be not too costly to guess most of them using a dictionary attack or whatever the state of the art is for guessing non-random passwords.
Is this just defense in depth, or deterrence, or is there something I'm missing that makes the plaintext storage really much more dangerous?
Assume the database gets dumped. Plaintext you immediately have a password.
If hashed/salted, this would need to be cracked and takes time/resources. It's not perfect/ideal but it buys time. A raw pw dump you're good to go to start testing them on other sites.
In short, its like having a kia/hyundai vs. any sane car manufacturer. All cars can be stolen, some just make it easy.
Look into "rainbow tables" and "salting & peppering" in the context of password storage.
> Is plaintext really that much worse than hashed/salted/whatever storage?
Bruh...
Any random rouge employee (and judging from OP's post, it's accessible to not just DB admin/IT but also regular supports) can easily scrape any password they want.
Considering OP was told the password on a call, I'd guess a low tech social engineer could easily extract any password they want as well.
> Is this just defense in depth
You use "just" as if "defense in depth" is just some security theater term with no substance.
I say "just" because if I'm missing something fundamental about how passwords are properly stored, then defense in depth might not be the point.
I read up a bit more on salting passwords, and now I see that it makes guessing the passwords _way_ harder, because it adds a factor of O(n) to the guessing (n is the number of passwords leaked).
The usual plan of attack looks like this:
1. Get a raw dump of a database from
2. Take the usernames and passwords
3. Try logging into eTrade with those usernames and passwords
This takes advantage of the fact that a third of people use the same password everywhere [1] and they resist using two factor authentication. You aren't protecting your own site from getting hacked (nobody cares if someone gets the password to your blog comments section), you're protecting your users from themselves.
The next step that people will do is hash the password. This makes it much harder to figure out the original password, and it used to be enough. But the problem is that if two people have the same password then their hashes will be the same. Rainbow Tables exploit this problem by doing some pre-work and parallelizing the users being attacked to make the problem space much much smaller.
The next step is to add salt to the password hash. Each user gets a few random bytes mixed in with their password before it gets hashed. Now if two users have the same plaintext password their hashes will be different. Rainbow tables don't really work any more because the parallelizing is gone, making the pre-work useless (you could do the pre-work per salt, but that's just as much work as cracking the hash).
It's arguable that the next step is using SSO with an identity provider. The downside to this is that you are relying on another company. The upside is that you don't have to store passwords or build the login flow at all. Tradeoffs.
I've got news for you - they aren't the only ones. Other big companies in the utilities and financial sector also do this, and even some banks.
Often it's a product of repeated acquisitions, where the lowest common denominator across disparate systems is some kind of text-based format.
That said, I'm surprised a customer service agent ostensibly had access to it.
From my own observations (some made during efforts to champion change), industry has gotten better over time. There shouldn't be cases anymore where salted hashes or other alternatives can't be achieved, and I'm pleased to see the public take security and privacy seriously.
This should be a criminal offense at this point.
Who are you prosecuting?
I believe they're suggesting the people storing the plaintext passwords. Who else would it be?
I guess there's no one person to hold accountable. They probably just get a small fine and move on.
The engineers, just like any other real engineering field.
Whoever is in charge. That's who you charge. They're the boss. They pay the penalty.
They might not know what is being done. They might not even know it is a bad practice. I work in government and you wouldn’t believe how many people are clueless about good practices.
Ah yes, the classic "ignorance of the law is a perfectly valid reason to break the law" defense, which famously works all the time.
It's literally their job to know.
[dead]
SRP, one of the two major utility services in Phoenix does this as well
This is bad for anyone who recycles passwords. Most everyone I guess.
I’m sure they aren’t the only company to do so
I don’t think having an online account with your utility provider is required or smart. Good old postal mail is the way.
Paying by checks through the mail is so annoying and difficult to stay on top of. I can't understand how you would prefer that approach in general -- is there some strategy here that I'm missing? Or is it that you open mail always immediately when you receive it, and minimize changes in address / vacations?
My strategy is to have a "disposable" password that you use for low-value purposes, like paying utilities. I assume this password is public knowledge, and accept that if somebody has it they can do such nefarious things as... pay my utilities bill.
My guess as to what OP means: postal mail, as in, mail me my bill. And then pay electronically through your bank, not the company’s online portal. At least that’s the way I do it.
Nice things about checks:
- not subject to the annoying daily / monthly limits of Interac eTransfers, EFT's, etc.
- easy to hand to someone, especially where there's no internet
- generally no extra fees
- for B2B, pretty much everyone accepts them
- post-dating (one tactic toward your question of how to deal with regular payments, eg. rent)
- in the US, a picture of one (meeting certain criteria) has the same legal status as the original
- float (not nice at all for you, but a not-insignificant revenue stream for your bank/insurance company/etc)
Do you really want to bank on your utility to have their shit figured out so you don't pay the utility bill for your whole town? Even if you do entirely get it resolved, that seems like extra hassle when you could just... use a password manager.
That’s fair, a password manager would be a good (and likely better) alternative. The only reasons I haven’t made the switch:
1. Even password managers are unreliable, with many popular ones getting hacked in the last 10 years. And I don’t like the idea of storing _all_ my passwords with a single service which may be hacked. I suppose I could just store a subset of my passwords, but that eliminates a lot of the convenience
2. I still find password managers somewhat annoying to use in general. Copy-pasting is disabled on many login forms, so I often would have to manually type an unfamiliar password. And when I’m not using my personal laptop I have to “log in twice” to complete a single intended login - this has historically been fairly common for me, though maybe less common recently
There is always discussion about people re-using passwords. Why don't more people use something not cloud based like KeePass to keep track of that? I do not get it.
Title is: PSA: Toronto Hydro is able to see your login password in plaintext.
I wonder if they in-housed this or paid some external contractor obscene amounts of money for it?
The thing is probably running on decades-old code that makes common security practices (like storing only salted hashes of passwords) hard.
I wouldn't be surprised if there's code in there written in old-style mainframe COBOL or even (gasp) RPG.
Sigh.
Great. Now all I need is someone to hack my account and pay my electricity bill for me.
I think the vector I'd be more worried about here is that someone does a database dump of usernames & passwords, and then proceeds to use that data for credential stuffing. The hygenie of users being on average probably "not great", that would probably lead to subsequent compromise down the line, of things more valuable than the electric company's account.
But, IDK, if they're storing passwords in the clear — something so trivial to get right, and so obviously not best practice — I'd also be wondering if the user's bank account routing & account numbers aren't in that same database table…? I can imagine some damage from that.
Utility bills can be used as proof of address for voting.
https://www.elections.ca/content.aspx?section=vot&dir=ids&do...
[dead]
[flagged]
Why is this a big deal? Hiring a contractor is 100% more insecure than this. I’m not recommending you do it, but it’s basically just people celebrating they now how to do this, but it’s actually never been exploited once in human history. Yet big brain security people trust contractors to write code and nobody bats an eye.
This is an attack called "credential stuffing" and the OWASP page for it has multiple examples of it being used in the real world: https://owasp.org/www-community/attacks/Credential_stuffing .