Live data from Hacker News

Security Update

stackoverflow.blog

151–160 of 207 posts

Re: Security Update

#151

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…

Email addresses do a better job of identifying particular individuals in bulk data than a name field in a variable format.

It's a very short hop from email to link technologies from this dataset to place of work and then potential attack routes for a sufficiently capable actor.

Re: Security Update

#152
post #130

Earlier quoted context omitted.

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.

Sure. But that advice was written 12 years ago. I'd be surprised if they didn't update their password storage since then.

Re: Security Update

#153
post #130

Earlier quoted context omitted.

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.

He wrote it in 2007.

Re: Security Update

#154
post #130

Earlier quoted context omitted.

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.

To be fair, Jeff's post was written in 2007 ... this predates Khanna's PS3 clusters. CUDA was released the same year. So I'm not sure it would be obvious in 2007 that SHA-2 would be "worthless for storing passwords".

Re: Security Update

#155

Earlier quoted context omitted.

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…

A rainbow table is the exact attack I'm saying is still infeasible. ("Strong passwords are still just as strong.") It only works by assuming the victim uses one of a known set of weak, easy-to-guess passwords. If they don't, their hashed password is very unlikely to be in the rainbow table at all, because there's just too much hash space. The calculation in my original comment gives the approximate number of hashes necessary to fill a complete md5 rainbow table, on the assumption that you get zero collisions in the process of filling it in. (That is, every time you hash something, you get a hash you've never seen before, allowing you to add new information to the table.) That assumption is not at all realistic. By the time you've filled in half of the space, unless you can choose them cleverly to avoid collisions, half of the strings you hash should be wasted effort.

In a single-target attack, I don't really see the concept of "pre-computation to trade space for time". That hurts you by taking a lot of space, but it doesn't gain you any time, because you spent at least the required amount of time, but almost certainly more, doing the pre-computing. If you can buy someone else's pre-computed rainbow table, then sure, that's an advantage for you. But the adversary actually doing the pre-computing is doing it in order to crack many people's passwords all at once ("this table will let you identify _everyone_ whose password is qwe123"), which is the scenario I described earlier.

(At this point I feel I should clarify that "some people use the same passwords" is a real threat and a real reason to avoid md5. I just don't think the comment I responded to, "It is a question of when not if a hash table is fully cracked", was made in good faith or informed by... anything. To fully crack md5 in that way, you'd need an easily-computed function that inverts it. No amount of hashing speed is ever going to get you there.)

Re: Security Update

#156

Earlier quoted context omitted.

Sure. Nobody claimed you could get the risk down to zero.

Its even more of a risk potentially because big companies have people full time working on keeping systems up to date and monitored. How many self hosters have a full monitoring system powerful enough to detect attacks and keep their software up to date and secured as soon as updates come out? How many people self hosting are even qualified to run a secure system? I bet most of them are just regular devs who know jus…

> Its even more of a risk potentially because big companies have people full time working on keeping systems up to date and monitored.

Beyond the thing about different types and frequency of attacks - sure, I trust Google's security more than my own. But I do trust my own security more than that of Random-Startup.IO, who likely have no full-time security people, and little incentive to get the job right (paying attention to security slows down your incredible journey).

Also, even with big companies, this argument applies primarily to the few like Google, Facebook or Apple. Your Random Megacorp from outside tech community usually focuses its security efforts on satisfying regulators and neutering their own employees, who'd otherwise happily copy out all sensitive data to make their jobs easier.

Re: Security Update

#157
post #141

Earlier quoted context omitted.

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?

i use an alias on stackoverflow, and i use an alias here on HN!

My google profile is also an alias. My facebook profile is also an alias. My twitter, same. And if i had a linked-in profile, it would be an alias too. Some of those alias may be the same, but some i deliberately make different, so that i can choose whether others can associate different aliases together as the same person.

Why anyone puts their real name online is beyond me. When i tell my real life friends, they are shocked, and also ask whether it's inconvenient. Yes, i would answer - it is inconvenient, but it is more control. It gives you the option to prevent others from being able to track all my activities online across different services (at least, not easily).

Re: Security Update

#158
post #139

Earlier quoted context omitted.

It is running on top of hashcat, and at the above-mentioned compute it was benchmarking 45 million bcrypts per second. At that point it is more about the attack plan than the compute. https://imgur.com/a/DXQMsM1 edit: here is the demo video: https://www.youtube.com/watch?v=KnD4f8N1_OE

"X bcrypts per second" is completely meaningless. What was the bcrypt setting? With the right setting, it would not be more than 1 bcrypt per century, or with the wrong setting, an almost equivalent rate to md5. It depends. More meaningful would be the speedup compared to a single CPU core, which is what the developers (should) benchmark against. They should make it as slow as possible, so if their system can do bcry…

> With the right setting, it would not be more than 1 bcrypt per century

You can't really call that a "right" setting when it takes at least as long to log in...

Re: Security Update

#159
post #136

Earlier quoted context omitted.

I haven't checked in a while, what's the cost of cracking a single salted password that is stored properly, e.g. with pbkdf2 or bcrypt or whatever is currently state of the art?

The cost? That depends on the password. How long does it take to crack 123456? That depends on the parameters. In a good case, it takes 50ms per hash on a modern system, so that's 20 attempts per second (instead of 20 billion per second for a plain md5 or so). I don't really expect a popular site to do much more than that, so that's the best case. From experience, most sites will be more around the 20 billion mark th…

> The current state of the art is Argon2

Details for the interested implementer: there's a lot of bad software floating around out there, be careful and do your due diligence.

Use the argon2id function. If the language binding does not expose the argon2id function, but only argon2i and argon2d, then it's outdated, avoid. If the library has not been updated past 2016 (argon2 v1.3), it's vulnerable, avoid. (Some language bindings ship with an embedded library.)

Language bindings to the argon2 library do not document how to pick good parameters because language binding authors do not understand nor care about security, the suggestions in the synopses are laughably undervalued. Compare with the expert recommendations in https://password-hashing.net/argon2-specs.pdf chap. 6.4, 8, 9 and https://tools.ietf.org/html/draft-irtf-cfrg-argon2#section-4 .

Algorithm for picking the correct values on the target server hardware:

    const PASSPHRASE := 6 random words from dictionary
    const SALT := 16 bytes from urandom
    const DURATION := 0.5   ### or greater; this is the maximum amount
                            ### you are willing for your user to wait
    mut T_COST := 1
    mut M_FACTOR := concat(4096, 'M')
    const PARALLELISM := `nproc`
    const TAG_SIZE := 16    ### bytes, or 128 bits

    while {
        const TIMER := benchtime argon2id(
            PASSPHRASE, SALT, T_COST, M_FACTOR,
            PARALLELISM, TAG_SIZE
        )
        if TIMER > DURATION {
            if 1 === T_COST {
                reduce M_FACTOR     ### e.g. divide by a constant
                jump to top of while
            } else {
                jump out of while
            }
        }
        print T_COST, concat(M_FACTOR, 'M'), TIMER
        T_COST := T_COST + 1
    }

Re: Security Update

#160

Earlier quoted context omitted.

> 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.

Sure. But that advice was written 12 years ago . I'd be surprised if they didn't update their password storage since then.

How do you update password storage if you don't store the passwords only hashes?

You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)

Post reply on HN