4 ms·

Upstream post: https://www.vpnmentor.com/blog/report-biostar2-leak/ https://www.vpnmentor.com/blog/report-biostar2-leak/ Quote : Our team was able to access o

by e12e 7y ago

Upstream post: https://www.vpnmentor.com/blog/report-biostar2-leak/ https://www.vpnmentor.com/blog/report-biostar2-leak/ Quote : Our team was able to access over 27.8 million records, a total of 23 gigabytes of data, which included the following information: - Access to client admin panels, dashboards, back end controls, and permissions - Fingerprint data - Facial recognition information and images of users - Unencrypted usernames, passwords, and user IDs - Records of entry and exit to secure areas - Employee records including start dates - Employee security levels and clearances - Personal details, including employee home address and emails - Businesses’ employee structures and hierarchies - Mobile device and OS information One of the more surprising aspects of this leak was how unsecured the account passwords we accessed were. Plenty of accounts had ridiculously simple passwords, like “Password” and “abcd1234”. It’s difficult to imagine that people still don’t realize how easy this makes it for a hacker to access their account.

tossAfterUsing 7y ago
> Unencrypted usernames, passwords, and user IDs I am shocked... SHOCKED! Actually, I'm not. Maybe, I should be? Commence anecdote: When evaluating which of 2 positions to accept, I settled on {CompanyX} because of the CTO, who seemed like an excellent person to learn from. Something like 20 years in leadership & a linux chops that I'll probably always be envious of. By the time, I'd accepted the offer & taken 2-weeks to get settled into a new town, he'd left the company (quite the surprising red-flag for me)... but was still monitoring Github as part of the changing of the guard. The first issues I filed at {CompanyX} was "we are sending passwords in cleartext(!!!)". It wasn't 5 minutes before CTO-LINUX-GURU shouted me down. "IT'S HTTPS, NOT CLEARTEXT!". His message was sharp, and the obvious subtext was that I was dumb. Well, if you say so... I let it go, and kept my head down. Months later, we had to reset a bunch of user accounts because those passwords were being logged (in cleartext) to emails, and also saved to error logs when users had a difficulty logging in. After 8 months with the company, I'd finally had enough. 2 months after I left, the friends I made there called me to tell me they were looking for work. The company had run out of money, and laid off a bunch of engineers.
- johnday 7y ago
  I mean... It sounds like he was right, in the sense that sending passwords verbatim over HTTPS is completely normal and fine. Obviously (not) logging cleartext passwords is the kind of thing you learn in Security 101.
  - FakeComments 7y ago
    The thing you learn in Security 102 is that you should encrypt passwords in HTTPS anyway, because so much of your middleware will assume fields aren’t secured, and will happily log them — that while from a theory standpoint, password-over-HTTPS is fine, in practice it’s a liability due to organizational issues. You can securely send plaintext over TLS, but it’s best not to when avoidable — precisely because it’s inviting the disaster above.
    - johnday 7y ago
      Client-side encryption is security theatre. If clients encrypt the password, then an attacker can send a log-scraped hash just as easily as a plaintext one. If anything, the faults (like the one above) would still exist and just become harder to spot.
- rahimnathwani 7y ago
  So what was the actual situation? A) The password was being sent in full to the server, over HTTPS? B) The password was being sent in full to the server, over a plain text (unencrypted) channel? It sounds like the CTO was claiming the former (A). If you are running JS on the client anyway, then it seems reasonable to pass the client the salt, and ask only for the hash of the salted password. But, if you say it's never OK to send the full (unhashed) password over HTTPS, then this implies it's not OK to have a fully server-side web app with password authentication. Because the only way to validate the password is for the client to send the whole password (unless you only ask for specific characters, but then password storage gets harder).
  - arethuza 7y ago

by e12e 7y ago

tossAfterUsing 7y ago

> Unencrypted usernames, passwords, and user IDs I am shocked... SHOCKED! Actually, I'm not. Maybe, I should be? Commence anecdote: When evaluating which of 2 positions to accept, I settled on {CompanyX} because of the CTO, who seemed like an excellent person to learn from. Something like 20 years in leadership & a linux chops that I'll probably always be envious of. By the time, I'd accepted the offer & taken 2-weeks to get settled into a new town, he'd left the company (quite the surprising red-flag for me)... but was still monitoring Github as part of the changing of the guard. The first issues I filed at {CompanyX} was "we are sending passwords in cleartext(!!!)". It wasn't 5 minutes before CTO-LINUX-GURU shouted me down. "IT'S HTTPS, NOT CLEARTEXT!". His message was sharp, and the obvious subtext was that I was dumb. Well, if you say so... I let it go, and kept my head down. Months later, we had to reset a bunch of user accounts because those passwords were being logged (in cleartext) to emails, and also saved to error logs when users had a difficulty logging in. After 8 months with the company, I'd finally had enough. 2 months after I left, the friends I made there called me to tell me they were looking for work. The company had run out of money, and laid off a bunch of engineers.

johnday 7y ago
I mean... It sounds like he was right, in the sense that sending passwords verbatim over HTTPS is completely normal and fine. Obviously (not) logging cleartext passwords is the kind of thing you learn in Security 101.
- FakeComments 7y ago
  The thing you learn in Security 102 is that you should encrypt passwords in HTTPS anyway, because so much of your middleware will assume fields aren’t secured, and will happily log them — that while from a theory standpoint, password-over-HTTPS is fine, in practice it’s a liability due to organizational issues. You can securely send plaintext over TLS, but it’s best not to when avoidable — precisely because it’s inviting the disaster above.
  - johnday 7y ago
    Client-side encryption is security theatre. If clients encrypt the password, then an attacker can send a log-scraped hash just as easily as a plaintext one. If anything, the faults (like the one above) would still exist and just become harder to spot.
rahimnathwani 7y ago
So what was the actual situation? A) The password was being sent in full to the server, over HTTPS? B) The password was being sent in full to the server, over a plain text (unencrypted) channel? It sounds like the CTO was claiming the former (A). If you are running JS on the client anyway, then it seems reasonable to pass the client the salt, and ask only for the hash of the salted password. But, if you say it's never OK to send the full (unhashed) password over HTTPS, then this implies it's not OK to have a fully server-side web app with password authentication. Because the only way to validate the password is for the client to send the whole password (unless you only ask for specific characters, but then password storage gets harder).
- arethuza 7y ago