Live data from Hacker News

Security Update

stackoverflow.blog

71–80 of 207 posts

Re: Security Update

#71
post #64

Earlier quoted context omitted.

I would like to hope Stack Overflow of all companies doesn't store passwords in plaintext, but you never know.

They don't have to store them as plain text for it to be a problem. If they're not salted it's trivial to crack the hashes, and if they are all uniquely salted, while it's time consuming, they can still gradually crack them. Given that you could probably sift through the users to find particularly juicy targets (usernames of maintainers of top open source projects with github repos for example?) that could justify th…

Also "Some level of production access" could easily include the ability for the attacker to intercept and exfiltrate passwords as users log in.

Re: Security Update

#72

What tends to be the first indication of breaches? It's one thing to do a forensic analysis after learning of a breach, and it's another to detect it in the first place.

Mostly, Troy Hunt e-mailing clueless companies saying "Hey, this data breach I got sent seems to check out as real, at least a few of the users in it have validated that's currently or recently been their $company website credential to me."

(Only mostly joking...)

Re: Security Update

#73
post #54

Earlier quoted context omitted.

It doesn't have to be more secure, it just has to be less likely to get hacked.

I'm not sure that off-the-shelf software on your own server is necessarily less likely to get hacked. It's easy to fall behind on security updates when you don't think about deploys regularly. Look at the logs for your existing infrastructure. I can pretty much guarantee that there are drive-by Wordpress attacks, regardless of what software is actually serving requests. There will be ssh login attempts.

You're not showing anything by telling me to look for attempted attacks. I realize they will be there, I don't even need to check. But if attack attempts are how you measure risk then I'd bet you whatever attack you can think of, Google et al. will have orders of magnitude more of them than I would.

You gotta realize, it's not like I'm arguing you should set up a server with 1234 as the root password. I'm assuming you're reasonably competent in security, just mostly lacking in the bandwidth needed to e.g. keep your server constantly checked and updated on a daily/weekly basis. With those assumptions I have no reason to think the slightly increased risk of getting hit by a brand-new attack through an IP scan or something is going to outweigh all the entire classes of risks that you do away with as a result of not being part of a massive corporate attack target.

Although, heck, if you're absolutely paranoid about random IP scans, you could just move your stuff to some obscure port, which I'm sure you realize already. There you go, you're not going to be found through random mass scans anymore.

Re: Security Update

#75
post #8

Reflecting on this, I wonder if a PaaS solution that is a "vault" of confidential information would be a good thing. Similar to how Stripe handles payments with a token, we could all store tokens for User information (eg the Id) and query the vault (or operate on the vault, eg, validate login, or return email, etc) using keys. The service could be hardened (like Stripe) to ensure the data is stored securely, and dete…

You've just invented from first principles Single Sign On, OAuth, SAML, and Identity Providers.

You can rent it from AWS, of course. It's called Cognito.

https://aws.amazon.com/cognito/

You can also offload that responsibility for user data/credentials to Google/Facebook et al as you see many places with "Login with Facebook", making your users pay in privacy-invasion instead of bearing the burden of properly securing your user's PII yourself...

Re: Security Update

#76
post #3
post #2

I think we've reached a point where it's safe to say that if you're using a service - _,any_ service - assume your data is breached (or willingly given) and accessible to some unknown third party. That third party can be the government, it can be some random marketer or it can be a malicious hacker. Just hope that you have nothing anywhere that may be of interest or value to anyone, anywhere. Good luck.

I've made it a point to start self hosting anything that's particularly sensitive that I don't want third parties to have access to. KeePass and SyncThing probably have my most important information, and it's all owned by me.

StackOverflow is a forum, not a password manager or a file storage service. If people only participate in forums they self-host, each will have a community of one.

Re: Security Update

#77

Serious question: what sensitive user data is there on Stack Overflow anyway? Questions, answers and comments are all public, the content is Creative Commons licensed and even available in handy downloadable & queryable form: https://data.stackexchange.com/ As far as I can see, the primary sensitive user data they have is e-mail addresses, but (unlike, say, Reddit) most StackExchange forums don't deal with personally…

I've seen plenty of questions that include API keys or credentials and they're later edited to "remove" them although the revision history is still there. It would make up a minority of content on Stack Overflow but it's still there.

Re: Security Update

#79
post #2

I think we've reached a point where it's safe to say that if you're using a service - _,any_ service - assume your data is breached (or willingly given) and accessible to some unknown third party. That third party can be the government, it can be some random marketer or it can be a malicious hacker. Just hope that you have nothing anywhere that may be of interest or value to anyone, anywhere. Good luck.

Someone make a service that I can submit my email and you'll generate tons of fake passwords for me, then "accidentally" leak them all. When my email and password make their way into the big password lists I want to dilute the real one with thousands of fake ones. If it became the norm that password lists are suddenly full of junk the demand for them would proboably evaporate.

Re: Security Update

#80

What tends to be the first indication of breaches? It's one thing to do a forensic analysis after learning of a breach, and it's another to detect it in the first place.

I worked at a company that logged every single SQL query and made a rule set based on that. May not of been the most efficient but it worked great. There was basically a whitelist of sorts and if the query structure wasn’t in there then action taken. Also worked by knowing what queries came in what order when doing certain things.
Post reply on HN