This kills the “knowing things about you” vector of phishing and impersonation and make it as secure as any unique and random password.
"42_red_banana_&"
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.
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.
For the record, I don't have a great answer to this either -- genuinely curious.
Source: I posted that on reddit.
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?"
It is entirely government owned and the largest electricity provider in the province.
I believe you’re thinking of Ontario Hydro, though it looks like that’s been privatized and/or split up.
Happy to be corrected though if I'm misreading this!
https://old.reddit.com/r/alberta/comments/1c7lk3z/ahs_privac...
Don’t know if that went anywhere… anyone know?
How do we know that the OP of this post did not make these claims up?
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.
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?
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.
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 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).
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.
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.
- 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)
I wouldn't be surprised if there's code in there written in old-style mainframe COBOL or even (gasp) RPG.
Sigh.
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.
https://www.elections.ca/content.aspx?section=vot&dir=ids&do...
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
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.
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.
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"
I get a little thrill every time.
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.
"Mother's maiden name? Cruz-Valdez"
"First Concert? Lil' Mermaid"
"City you were born in? Ubuntu"
Other than two about your birth location and mother's maiden name, both easily found answers for someone
"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
It is very hard to come up with universally good security questions.
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.
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