sarciszewski

(Switching back to my old account because rate limits.)

I wouldn't ever use something like FizzBuzz to assess a candidate. It would be more of "here's a mostly finished sample application with a corresponding SQL file, add this feature (e.g. a search bar for a blog) and fix any (intentionally introduced) security bugs you find".

They would be evaluated based on how successfully they complete the main task, and if they have an eye for finding/patching vulnerabilities, that's a bonus that can be used as a secondary selector if a lot of candidates pass. If no one does, it won't be used against them.

That's how I'd approach it, personally. Something specific to the kind of work we're doing, but abstract enough to be approachable without a lot of insider knowledge.

All true but my observation is that the companies that put candidates through multi-day-out-of-town interview processes can afford to miss out on the candidates that can't do it.

All companies can afford to waste less money than they need too.

RSA security depends mostly on how you build your private keys and ECC security depends on what parameters and what curve was chosen.

No. RSA security depends on getting your parameters right and padding.

http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-...

http://framework.zend.com/security/advisory/ZF2015-10

Russians cryptoexperts doesn't fully trust DJB they found that at the last iteration of picking parameters by DJB for Curve25519 was a bit questionable.

Tell them to publish their findings and propose a better solution.

Changes was done for "better performance" but no one found what exactly was speeded up.

What "changes" exactly? The word "changes" implies there was an early draft with vastly different parameters.

I don't know details, but when curve parameters was tried to be being compromised by NSA was almost always was about adding such "performance optimizations".

If you don't know the details, try doing some research. Knowledge is healthy.

I really appreciate the level-headed discussion in this thread so far, especially the comment I'm replying to.

It's a stark contrast to the CFRG mailing list. (At least, so far, no one has tried to derail discussion here with "hey check out my custom cipher it's soooo secure but you need to compress the data before encrypting it or else you can observe a repeated structure out of it".)

I like 25519's school of thought. If you use the smallest possible value for a given performance/security goal, there's less room for conspiracy theory (provided the person making the theory understands what's even going on).

http://pastebin.com/AYW682BJ

https://archive.is/exvT2

Person: "I'm starving and barely able to get by working for Yelp in SF."

Yelp: "You're fired." (Good luck paying rent without a job.)

Yelp CEO: "The cost of living is too high here, so we're going to instead move offices to Arizona and pay the same wage."

Does this mean that Yelp is going to...

    a. Help all of its employees move to AZ where they can enjoy
       a lower cost of living?
    b. Fire all of its employees and hire replacements in AZ?
    c. Something else?

The cost of living in SF is one of the reasons I refuse to ever move there for work, but it seems like a scapegoat in this case. Why not just pay your employees a livable wage to begin with?

How would transforming it before sending it over the wire help here?

No, it's one-way cryptography, but it's not a form of encryption.

https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...

Cryptocat was not secure. No argument there! Decryptocat was the proof in the pudding.

If a secure product could be as user-friendly as Cryptocat was while still being secure, then most peoples' communications would be more secure.

That's all I was saying. I'm not trying at all to hand-wave the proven insecurity. I'm saying that the only thing they got right was the one thing that secure products have consistently gotten wrong. (Barring Signal.)

See: "but the execution was flawed."

Security at the expense of usability comes at the expense of security.

It got the usability part down, it just wasn't secure. And I wasn't claiming it was.

Cryptocat was a good concept (i.e. it was USABLE!), but the execution was flawed. It grew a lot of criticism and Nadim made mistakes in handling some of his critics, creating a schism between him and the cryptographers who might have been able to help him. (Not all of this was his fault, of course.)

I hope that not only will this new product of his be developed with "A pure vision of democratized, pleasant secure messaging", but also that he has matured significantly. I hope that Cryptocat v3 will come out after it has been thoroughly audited by several reputable third parties.

Most importantly, I hope their crypto is boring.

https://security.stackexchange.com/questions/6095/xkcd-936-s...

http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf

Warning: Autoplay video.

"shoulder surf protection"?

No, you're saying "which of this limited set of companies are you going to authenticate with" instead. If you don't want to be guilty of taking users' agency away from their own trust decisions, you need to do one of two things:

1. Let every website on the Internet potentially be an OAuth provider.

2. Make OAuth optional.

If you follow option #2, then this article is still relevant because you need to handle passwords securely.

I don't understand why they would trust <crappy forum owner> over a dedicated authentication storage place but that's their choice.

What if <crappy forum owner> happens to be a security engineer, and <crappy forum> happens to be Silk Road 13?

The trust decisions people make are situational and nuanced. OAuth is great if that's where people invest their trust. Otherwise, you're outsourcing it for the user to a company they might fear.

My question was: "What if your users don't trust any of the existing providers on Earth?"

It's hard to make a blanked recommendation like that, even for "only 99%" of websites. Neither you, nor the person building the website, has any insight into who the website's users trust.

Offer OAuth2 as an alternative to passwords: Great move.

Only offer OAuth2 and don't let people create an account: Questionable.

This requires your users to trust whichever OAuth providers you decide to integrate with. Sometimes, the set of "trusted OAuth providers" for your users is {}. What then?

99% of the websites that "require" me to create an account and log in don't need to store primary credentials for me

Why are you giving them valuable credentials? Give them a throw-away password (password managers are great for this).

If you're using any of: PBKDF2, Bcrypt, Scrypt, Argon2, then you're fine. Our recommendation is:

    1. Use the best option available, but
    2. We provided example code in multiple languages for the
       best one that's widely available

I did say "morally equivalent" rather than "technologically equivalent".

By that, I mean the overall security of your password scheme is analogous to what people get out of a password manager.

This is morally equivalent to using a password manager to encrypt your passwords with a "master password". :)

What do you do if your name is Dread Pirate Rogers and the set of OAuth providers you and your customers trust is "None"?

https://paragonie.com/blog/2016/02/how-safely-store-password...

How does that look now?

That's not very useful for web programmers that are handling their users' passwords, is it?

I believe the Ruby example is incorrect

Unfortunately, there's nothing I can do about that, unless someone can point me to an alternative that uses a constant-time comparison.

I've left a comment on the pull request so that, hopefully, it can be merged.

(and likely others)

Which others?

That makes a lot more sense. His Facebook profile didn't indicate anything about his background.

I feel that this is needlessly dangerous, personally.

How are the salts managed? This detail is important. SHA256(scrypt(password, constant_value_instead_of_salt)) is going to produce collisions in the stored hash.

How are you going to calculate the scrypt hash, client-side?

Doesn't that scrypt hash then become the password, from the server-side application's perspective?

How are you storing the salt for the user if your server only knows about a SHA-256 hash.

MITM attacks won't get access to unencrypted fields.

That's TLS's job. If you, for example, are building a web app and you're delivering Javascript to perform the scrypt calculation, a MitM can replace the code to exfiltrate the user's plaintext password. It doesn't make sense for the threat model.

Thanks for the suggestion, I'll put it on the list. :)

It would make for a good interactive "chart", perhaps. Whereby, as long as your sliders aren't all the way to the left, the chart is mostly green.

The blog post that HN is reading is served by PHP-FPM + nginx, without any extra special features to handle the load of an unexpected "oh hey we made it to the front page of HN".

It's also hosted on a relatively cheap VPS.