Know your data 42: an indicator of attitude towards password security

Why Meta got fined by Ireland

Know your data 42: an indicator of attitude towards password security

News came out that Ireland fined Meta (formerly Facebook) $100 million for storing user passwords in plain text (link).

The mystery is why they did it. Why even a big tech firm is putting its users at risk by not securing their passwords. Storing passwords in plain text is in itself not harmful to users; the harm appears when bad actors steal these passwords.

The lack of password security is frequently a feature, not a bug, of our technology landscape. Meta surely isn't the only culprit; they happened to have attracted regulatory oversight.

***

Let's ponder an uncontroversial use case: a support staff member needing to access my user account in order to service me.

For example, I might have called the support hotline because I couldn't figure out how to change the email address in my account settings. As often happens, the support person clearly sees the same account screens as I while she is serving me. In reality, she has logged into my account so she could replicate the steps I told her I took, in order to figure out what I did wrong.

Further, after she solves the problem, she can relay to me in minute details which buttons to click, and what to do. These steps should replicate perfectly because she simulated these actions in my account.

Now, the question is: how does she gain access to my account that is protected by my password?

The simplest way is if the website stores my password in a database, and the support staff just fetches my stored password from the database and log in in exactly the same way as I would have.

This use case is one (but not the only) possibility why Meta and other websites store passwords in plain text.

***

Let's assume they don't store passwords in plain text but store them in some encrypted form (including so-called "hashed" form). In this case, the user authentication system accepts the encrypted or hashed password as input. If bad actors gain access to the database, they can log in as me, just like the service staff, so I don't think it makes much of a difference.

The difference is that if a bad person who has stolen my encrypted password wants to know my plaintext password, they would have to work hard to decrypt or unhash it but why would they need my plaintext password if they could just gain access using the encrypted version?

***

Instead of mimicking user logons, the website could provide separate staff access to user accounts so that the staff members no longer need to know individual passwords. But these staff accounts are effectively master accounts with master keys.

The risk has arguably gone up. If the bad actors steal the master password, it opens up all accounts. Meanwhile, the user passwords are still stored in the database in whichever format.

***

That's the way technology works. Providing service staff tools to service users adds pressure on security. Storing passwords in plain text is a convenient way to enable this feature. Other ways create other problems. Not storing passwords in plain text only reduces the risk slightly. I suppose it has a signaling effect - if plaintext passwords are stored, it may indicate the company's attitude toward password security.