Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security Update

stackoverflow.blog

Post reply on HN
Print view View original

141–150 of 207 posts

Re: Security Update

#141

Post by chii »

stetrain wrote: post #95
9nGQluzmnq3M wrote: post #40

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…

They have job listings, information about listings I have applied to, and a copy of my resume with contact information.

Job listings are public information, your resume may also be considered public info if you have sent it out to recruiters or public job posting sites.

Listings you've applied to could be potentially private. But if you use an alias (and only reveal your real name after the company agrees to interview you), then it's not a problem either!

Re: Security Update

#142

Post by INTPenis »

nerdbaggy wrote: post #80
chairleader wrote: post #9

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.

This sounds a lot like an IDS for SQL. I've worked with government agencies that focus very heavily on IDS in firewall systems.

SO not only do they catch attacks early, in the perimiter network, but they also often block legitimate traffic and handle such cases regularly.

But it's a default deny policy so that comes with. It also costs a ton of money for the best IDS solutions. I believe it comes from companies like Checkpoint, Cisco and Symantec.

Re: Security Update

#143

Post by tialaramex »

thaumasiotes wrote: post #138
AstralStorm wrote: post #127

Earlier quoted context omitted.

No, MD5 has about 18 bit collision strength. Combined with predictable salting practice, this is crackable with a calculator. Welcome to Merkle-Damgard construction allowing any prefix or suffix. Given random salt (random placed or mixed) or HMAC, you have to use the more complex preimage attack at 123 bits. This is crackable with a medium sized botnet or a supercomputer. 48 THash is an underestimate. Specialized har…

At 123 bits, you're five bits short of the 128 bits I calculated with. I don't think a medium sized botnet can rise to the level of doing 8 quadrillion years of work within your lifetime. What problem are you trying to solve? As I understand it, we're discussing enumerating the hash space, such that: 1. You are given a hashed value, such as 2b0f4e60b80da7ef1e84573d764f1bf4 . 2. The value is someone's hashed password.…

I agree with your thrust that your parent poster (AstralStorm) is barking in a different forest from the tree we care about, but for salting it is also a defence against pre-computation to trade space for time.

With an unsalted hash an adversary can do as much work as they want in advance, store output and then trade that in once they have your hashes to get all or most of the same rewards as if they'd done the work after getting your hashes. Rainbow tables are the most famous example, but they're part of a family of similar attacks.

Salt lets you arbitrarily discount this advance work because the attacker must do it for all possible salt values and you get to choose how many there are - the early Unix crypt() salted pessimised password hash discounts it by a factor of 4096, modern schemes often use many orders of magnitude more salt. An attacker who has $4M to attack my password scheme probably doesn't want to spend $4M now to have a $1000 advantage once they get the hashes, and they certainly won't for a 1¢ advantage.

Re: Security Update

#144

Post by kerng »

pvg wrote: post #118
kerng wrote: post #113

Earlier quoted context omitted.

There are many different ways to get compromised. Reducing attack surface is always a good idea. And, yes I do close all browser windows/processes before login, and after logout of important websites for instance to make sure cookies and passwords are gone from browser memory.

I don't think this really addresses my point. You're saying the in-browser password manager is somehow more dangerous than some external password manager. I don't think this is true. And the browser presents the same attack surface if you're, you know, using the browser. If your browser is a vector for successful compromise, you're boned if you use the browser, whatever elaborate protective ritual you follow while us…

>> You're saying the in-browser password manager is somehow more dangerous than some external password manager.

Correct.

Re: Security Update

#145

Post by justwalt »

erichurkman wrote: post #11
keyle wrote: post #6

Earlier quoted context omitted.

You'd have to copy/paste a serious chunk of code you don't understand to really cause any damage. I think this comment is either taking the pun or misguided.

Q: "How do I recursively set ownership of folders in Linux?" A: http://thejh.net/misc/website-terminal-copy-paste

Reader mode exposes the full text of the command, if anyone is wondering and doesn’t feel like doing exactly what the post is telling you not to do.

Re: Security Update

#146

Post by _fbpt »

bigiain wrote: post #75
plasma wrote: 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 securin…

Mozilla Persona was deaigned so "the identity provider does not know which website the user is identifying on." But it did nto catch on.

As a user, it seemed like "so i need to login to Google on Mozilla.org... it's just a wrapper for my Gmail and/or Mozilla account?"

Re: Security Update

#147

Post by tgsovlerkhgsel »

jve wrote: post #130
robomc wrote: post #64

Earlier quoted context omitted.

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…

Of all the sites and people, I expect Jeff Atwood and Joel Spolsky to have followed best practices in storing user passwords. Jeff wrote this in 2007: > Do not invent your own "clever" password storage scheme > Never store passwords as plaintext. > Add a long, unique random salt to each password you store. > Use a cryptographically secure hash. I think Thomas hates MD5 so very much it makes him seem a little crazier…

> MD5 is vulnerable. Why pick anything remotely vulnerable, when you don't have to? SHA-2

For the purpose of hashing passwords, there's no significant difference between MD5 and SHA-2. Both are awful choices.

Edit: Actually, SHA-2 may be worse because CPUs have hardware acceleration and thus the attacker may be able to crack it somewhat faster than MD5.

Re: Security Update

#148

Post by dagenix »

chii wrote: post #141
stetrain wrote: post #95

Earlier quoted context omitted.

They have job listings, information about listings I have applied to, and a copy of my resume with contact information.

Job listings are public information, your resume may also be considered public info if you have sent it out to recruiters or public job posting sites. Listings you've applied to could be potentially private. But if you use an alias (and only reveal your real name after the company agrees to interview you), then it's not a problem either!

> But if you use an alias (and only reveal your real name after the company agrees to interview you), then it's not a problem either!

Do you do that? Do you know anyone that does? If so, how do people react to it?

Re: Security Update

#149

Post by dagenix »

jve wrote: post #130
robomc wrote: post #64

Earlier quoted context omitted.

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…

Of all the sites and people, I expect Jeff Atwood and Joel Spolsky to have followed best practices in storing user passwords. Jeff wrote this in 2007: > Do not invent your own "clever" password storage scheme > Never store passwords as plaintext. > Add a long, unique random salt to each password you store. > Use a cryptographically secure hash. I think Thomas hates MD5 so very much it makes him seem a little crazier…

> SHA-2 or Bcrypt would be a better choice.

As the sibling comment points out, SHA-2 is worthless for storing passwords. A GPU can crank through an obscene number of SHA-2 hashes per second. Bcrypt is is intentionally much slower and harder to use a GPU to brute force. The two algorithms are almost totally unrelated and it's concerning they were mentioned together.

Re: Security Update

#150

Post by dagenix »

dhritzkiv wrote: post #109
bredren wrote: post #105

Earlier quoted context omitted.

I work on an enterprise infosec tool that just demonstrated 48 trillion MD5s per second using AWS GPUs. Hashed passwords are cracked so easily it is a minor obstacle at this point. It is a question of when not if a hash table is fully cracked.

MD5 is one thing as a password can be retrieved from a hash table. But pulling out passwords from a hashed + salted value (e.g. via bcrypt) is many orders of magnitude more infeasible, no?

Salting was originally important as a defense against rainbow tables - which are more or less obsolete with GPUs that can crank through trillions of hashes per second. The real reason that bcrypt is a better way to store a password isn't just because it uses a salt - it's because its designed to be slow and to use a bunch of memory which makes it much harder to brute force.
Post reply on HN