sarciszewski

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 companies can afford to waste less money than they need too.

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.

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

https://archive.is/exvT2

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?

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

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

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

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

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.

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.

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.

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

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

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

How does that look now?

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?

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.

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.

It's also hosted on a relatively cheap VPS.