Live data from Hacker News

Twin brothers wipe 96 government databases minutes after being fired

arstechnica.com

81–90 of 463 posts

Re: Twin brothers wipe 96 government databases minutes after being fired

#81
post #55

How did they get access to 5k passwords? Are they being sent/stored in cleartext? This is the most baffling part of the article for me. The second part I'm unclear about is how you could pass SOC2 when you aren't terminating account access simultaneously with the employment termination.

And how exactly do you want to store passwords if not in plain text (and then encrypted of course)? 5k is a lot, the authorization process is broken, but this is not related to how the passwords are stored. The only solution is correct access segregation and a bastion

Hashed, you store them hashed (and salted). A breach should never reveal passwords.

Re: Twin brothers wipe 96 government databases minutes after being fired

#82

> On Feb. 1, 2025, Muneeb Akhter asked Sohaib Akhter for the plaintext password of an individual who submitted a complaint to the Equal Employment Opportunity Commission’s Public Portal, which was maintained by the Akhters’ employer. Sohaib Akhter conducted a database query on the EEOC database and then provided the password to Muneeb Akhter. That password was subsequently used to access that individual’s email accou…

It's probably some sort of crusty old application written before salt and hash was SOP. No agency is going to spend money on hardening something non-critical unless there's an incident or there's free money to do so. And that application was likely written by some contractor who's no longer around or has the source code available so any fixes would require an entire redo. And while you're redoing the whole thing, let's add in a bunch of features and scope creep to balloon the cost and schedule. Oops, the new contractor writing the app is overrun so let's bail and go back to the old version.

Re: Twin brothers wipe 96 government databases minutes after being fired

#84
post #79

Earlier quoted context omitted.

And how exactly do you want to store passwords if not in plain text (and then encrypted of course)? 5k is a lot, the authorization process is broken, but this is not related to how the passwords are stored. The only solution is correct access segregation and a bastion

Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.

Also, you need to add salt. Otherwise every person using "Password123" has the exact same hash. Before they broke their search engine, it was common to google the MD5/MD4 hashes to "decrypt" or "unhash" them.

Re: Twin brothers wipe 96 government databases minutes after being fired

#85
post #55

How did they get access to 5k passwords? Are they being sent/stored in cleartext? This is the most baffling part of the article for me. The second part I'm unclear about is how you could pass SOC2 when you aren't terminating account access simultaneously with the employment termination.

Policy and practice might not be the same thing. The company and the entire management staff should be on somebody’s blacklist for future procurement.

Re: Twin brothers wipe 96 government databases minutes after being fired

#86

Earlier quoted context omitted.

Ready access to AI tools sure makes vandalism easy.

Ai is just a tool. You can kill with hammer, doesn't mean you ban hammers. And they could have used stack overflow instead of ai.

You are the first person in this conversation to mention banning. I am not sure what your comment has to do with anything.

Re: Twin brothers wipe 96 government databases minutes after being fired

#88

so, apparently, the passwords were stored in cleartext.

Remind me of a forum a long time ago that sent me my password in clear when I used the "forgot password" link. When I advised them that it was a bad idea to store password in clear, they answered that they keep it in clear so that they can send it when someone forget. Defeated by such argument, I deleted my account.

> Defeated by such argument, I deleted my account.

I'd bet your account wasn't actually deleted, just marked as deleted or inactive.

Re: Twin brothers wipe 96 government databases minutes after being fired

#89

Earlier quoted context omitted.

Meh. Don't leave anything at work. Forgo the convenience and carry your things on your commute. Use a bag. If there's "too much stuff", that's a sign to pare back what you "need" at work.

I know this is not a good year on the job market, but if you are traveling to work with a "go bag" and not leaving coffee mugs on your desk to prepare for being laid off maybe it is time to carry that go bag to some other buildings...

The obvious middle ground is don’t leave anything valuable at your desk that you wouldn’t want to lose. You shouldn’t leave valuable stuff at your desk even if you don’t expect to be laid off. Unless you work in a very secure environment, you don’t really know who will be sniffing around your desk.

Go ahead and leave a coffee mug, who cares if you lose a coffee mug?

Re: Twin brothers wipe 96 government databases minutes after being fired

#90
post #55

How did they get access to 5k passwords? Are they being sent/stored in cleartext? This is the most baffling part of the article for me. The second part I'm unclear about is how you could pass SOC2 when you aren't terminating account access simultaneously with the employment termination.

And how exactly do you want to store passwords if not in plain text (and then encrypted of course)? 5k is a lot, the authorization process is broken, but this is not related to how the passwords are stored. The only solution is correct access segregation and a bastion

You should never store passwords in plain-text, encrypted or not, you should always use a one-way cryptographic hash like bcrypt [0], scrypt [1], or PBKDF2 [2], combined with a single use salt [3] and optionally a pepper [4], and then store the output of the hash in the database.

To confirm a user supplied password matches you run input into the same hash function again with the salt+pepper and compare it to the value in the database.

That way if the database is stolen, the attacker cannot recover the contents of the passwords without brute forcing them. Encrypting passwords is not recommended because too often attackers are able to recover the encryption keys during the same attack where the password data is extracted.

[0] https://en.wikipedia.org/wiki/Bcrypt

[1] https://en.wikipedia.org/wiki/Scrypt

[2] https://en.wikipedia.org/wiki/PBKDF2

[3] https://en.wikipedia.org/wiki/Salt_(cryptography)

[4] https://en.wikipedia.org/wiki/Pepper_(cryptography)

Post reply on HN