3 ms·
They also had some really bad security holes recently exposed too: https://news.ycombinator.com/item?id=10078967 https://news.ycombinator.com/item?id=10078967 s
by hermanradtke 11y ago
They also had some really bad security holes recently exposed too: https://news.ycombinator.com/item?id=10078967 https://news.ycombinator.com/item?id=10078967 so they really didn't have this covered with 20 people.
- segmondy 11y agoWhat's your point? There are companies with thousands of engineers with pretty bad security holes too. They did it with 20 people, get over it.
- hueving 11y agoIt means the quality isn't great for the limited amount of functionality it provides. That doesn't count as 'they did it' in security-sensitive groups.
- merb 11y agoThe problem mostly can come from your tooling. I mean lots of people use and used MessageDigest.isEqual in Java however that class had a huge issue in Java 6 until Java 6 - 17 which could attackers use time attacks against your authentication scheme. Also it's not really easy to prevent against such security things with small teams if you can't rely on the tooling inside your language. Building Crypto things is really hard. So People needing to rely on. Today I've rewritten a authentication / authorization layer for one of our internal Apps, now the App is hardended against csrf, timing attacks and many more things. The only things that I used was the internal PBKDF2HmacSha256 for Passwords of Java Sha256Pnrg for Salts and I copied behaviors of the Auth0 JWT Library (i just used another json implementation which the app already had) and i have something like 200 Lines of Code. It's secure as long as MessageDigest and the PBKDF2 Code of Java is secure and that's something people can't avoid. Especially in small teams.