(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.
> 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).
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?
Because if they're going with option B, wow.
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?
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.)
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.
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).
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.