Client storing customers passwords in plaint text

[Lance]

Hashing passwords doesn't require a 'proper password management tool', and basic security measure aren't optional extras, and should have been costed in at the start. I'd just make sure you have a lot of evidence that you have raised it and leave it at that. If you raise it with infosec now it'll be pretty obvious who it was.

A hashed password isn't any use if you're going to try and type it into a system you're logging into. They need to be encrypted. But then the people who need to decrpyt them need a password to do that.

That's why you buy a product to do it for, specifically one with role based access control and auditing.

Since the question makes no mention of salt/pepper, we'll stick to plain hashing of password (a terrible idea by the way). I'm assuming we're doing server-side hashing, as client-side hashing is also a terrible idea.

Let's denote the following:

P: the password
H(P): the hashed password
You enter P in the login form of the website. The backend computes H(P) by running it N (let's say 1000) times through sha-256 (just to pick one). The backend looks up your user entry in its database and checks whether the computed H(P) matches the H(P) stored as your password. If it does: congratulations, you're you. Otherwise, "wrong password".

Now, an attacker got his grubby little hands on a dump of the database's user entries, including username and the H(P) for each user. However, the attacker does not have direct access to the database.

The attacker goes to the website, types in your username and H(P) as your password. The backend computes the hash of your password: H(H(P)). But lo and behold, H(H(P))≠H(P) because one is hashed 2∗N times, the other N times.

All that's left is for the attacker to try to get the original password out of the dump of hashes. But this is a story for another day.

PS: if you do want to do client-side hashing, you still need to do server-side hashing. The stored value in the database would be Hserver(Hclient(P)). Never store client-side hashes, that's just as bad as storing the password.

taken from a technical guide

[man]

I'd suggest KeePass or similar for password management (GNU license). It's not completely ideal (as it's a shared encrypted password database(s) with a single passphrase to access the whole vault of passwords), but it sounds a hell of a lot better than what you've got in place. And easy to set up, this is online freeware and IIRC doesn't even require a local admin account to install and use.

As the password vault is stored in a single file, it'd be easily stored on a file share for team use (or in a cloud storage account).

I've experienced KeePass being used on most customer accounts (one KeePass database per customer) at one of the big name FTSE100 outsourcers, so if it's good enough for them, your FTSE350 client should consider it.

[pauldee]

Hashing passwords doesn't require a 'proper password management tool', and basic security measure aren't optional extras, and should have been costed in at the start. I'd just make sure you have a lot of evidence that you have raised it and leave it at that. If you raise it with infosec now it'll be pretty obvious who it was.

[Lance]

won't pay? Or haven't looked at what's available?

Pricing Details - Key Vault | Microsoft Azure

Storing passwords at a huge cost of €0.026 for every 10,000 transactions.
So basically free.

Also FTSE-350 isn't really an SMB is it?

[DaveB]

Ok so I’ve recently started working for a new client which is a SMB consultantancy and it turns out they have a public folder structure with each of their clients config in, including their usernames and passwords for domain admin accounts.

This is a huge security issue in my opinion but the consensus I get from the other guys who work there is yes we know but management won’t pay for a proper password management tool.

Surely there is some legislation or laws they are breaking doing this?? Anyone got any experience regarding GDPR or similar that can shed any light on this?

I’m not interested to grass them up, more so I educate them and give them actual hard facts as to why this is a major no no

Cheers all

If the accounts are generic Administrator accounts and dont use isentifiable names, and the config data doesn't contain any information that would allow you to identify an individual then there is no GDPR / Data Protection issue.

It is a general security issue but from that point of view it's a business risk for them to accept or do somewthing about. They may be relying on robust boundary controls at the perimiter and access restrictions on the folders so that only known and identified individuals can access them. Not ideal, but also not unusual.

GDPR may come into it if the admin credentials gave acess to systems containg personal data relating to identifiable individuals, howver the legislation doesnt specify the controls, technical or procedural,required, only that they be "appropriate".

The liability will be in the contracts they have with their clients to manage and maintain their systems. If the client suffers a loss as a result of this then the contract is where that liability will be defined.

[LondonManc]

Not your problem then. Don't get involved I'd say.

I once pointed out to a client that their their highly sensitive CRM which was administered by IBM didn't have a change password on first log in, nor did it have an expiration policy. They also created all users with something akin to w3lcome (obviously not that one but you get my point) as standard.

Pulled the contract and it stipulated that change on log in, expiration was in the requirements and it specifically mentioned unique random passwords for new users or resets.

Oddly enough I became center of a right tulipstorm. Wished at the time I'd just kept quiet.

Odd, I could never imagine you causing a tulipstorm at work.

[northernladuk]

They don’t have an information security bod which I think it part of the problem. What’s laughable is they are. FTSE 350 public limited company

Not your problem then. Don't get involved I'd say.

I once pointed out to a client that their their highly sensitive CRM which was administered by IBM didn't have a change password on first log in, nor did it have an expiration policy. They also created all users with something akin to w3lcome (obviously not that one but you get my point) as standard.

Pulled the contract and it stipulated that change on log in, expiration was in the requirements and it specifically mentioned unique random passwords for new users or resets.

Oddly enough I became center of a right tulipstorm. Wished at the time I'd just kept quiet.

[SouthernManc78]

Raise it with their information security bod.

They don’t have an information security bod which I think it part of the problem. What’s laughable is they are. FTSE 350 public limited company

[GreenMirror]

Raise it with their information security bod.

Anonymously!

If this thread was in general I would ask about the best way of blackmailing the company.....

[LondonManc]

Sounds like it has more to do with operational risk than GDPR. Leaving yourself open to a data breach because data isn't encrypted is different to incorrect data retention policies. If those account details are needed, then as per GDPR, they don't need to be removed.

Raise it with their information security bod.

[SouthernManc78]

Ok so I’ve recently started working for a new client which is a SMB consultantancy and it turns out they have a public folder structure with each of their clients config in, including their usernames and passwords for domain admin accounts.

This is a huge security issue in my opinion but the consensus I get from the other guys who work there is yes we know but management won’t pay for a proper password management tool.

Surely there is some legislation or laws they are breaking doing this?? Anyone got any experience regarding GDPR or similar that can shed any light on this?

I’m not interested to grass them up, more so I educate them and give them actual hard facts as to why this is a major no no

Cheers all