Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security Checklist

securitychecklist.org

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Security Checklist

#51

Post by technion »

tptacek wrote: post #14
beefhash wrote: post #11

Earlier quoted context omitted.

Wouldn't it be wise to wait for argon2 to get some more cryptanalysis and testing in the field before jumping on it, sticking to scrypt or bcrypt in the meantime?

No. The reason not to use Argon2 is that it doesn't have great library support yet. Password hashes don't really fail like ciphers do. Nothing that is discovered in Argon2 is going to make it worse than PBKDF2, and using PBKDF2 is just fine if that's all you've got.

The reference library we do have looks set to make further breaking changes[0], which complicates this further.

[0] https://github.com/P-H-C/phc-winner-argon2/pull/119/files

Re: Security Checklist

#52

Post by NickNameNick »

DrScump wrote: post #43
msbarnett wrote: post #6

> Are all form fields (with the exception of password fields) validated with a restrictive regex? Please, whatever you do, do not try to regex validate people's names. A friend couldn't complete an order on a site the other day because it was rejecting his name as "invalid" per its shitty regex. See also Falsehoods Programmers Believe About Names[1] [1] http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...

Or email addresses, without knowing all the legal characters. (An annoying percentage reject '+', which is a great Gmail tool for spotting how your email address "leaks out".)

And a huge number don't suport email addresses with 'bare' tld's.

see rfc 7085 "Top-Level Domains That Are Already Dotless"

https://webcache.googleusercontent.com/search?q=cache:rySaMA...

Re: Security Checklist

#53

Post by mrmondo »

nthompson wrote: post #47
mrmondo wrote: post #37

Good start indeed, it'd be nice to have a small open source tool to do these checks, maybe even with a simple web interface - anyone seen a simple security checklist / analyser that's well maintained with the latest standards?

SSL labs is the gold standard: https://www.ssllabs.com/ssltest/ But I don't see a way to automate a test for the integrity of (say) a password recovery flow or that one user cannot access another user's data.

Yeah that's what I use at present, if it's not an A+ it's not OK. Would be nice to have an open source version of this that could perform additional checks though.

Re: Security Checklist

#54

Post by breakingcups »

NickNameNick wrote: post #52
DrScump wrote: post #43

Earlier quoted context omitted.

Or email addresses, without knowing all the legal characters. (An annoying percentage reject '+', which is a great Gmail tool for spotting how your email address "leaks out".)

And a huge number don't suport email addresses with 'bare' tld's. see rfc 7085 "Top-Level Domains That Are Already Dotless" https://webcache.googleusercontent.com/search?q=cache:rySaMA...

I thought those weren't allowed / encouraged by either ICANN nor IAB? They have a real-world possibility of colliding with internal hostnames.

Re: Security Checklist

#55

Post by devit »

tptacek wrote: post #14
beefhash wrote: post #11

Earlier quoted context omitted.

Wouldn't it be wise to wait for argon2 to get some more cryptanalysis and testing in the field before jumping on it, sticking to scrypt or bcrypt in the meantime?

No. The reason not to use Argon2 is that it doesn't have great library support yet. Password hashes don't really fail like ciphers do. Nothing that is discovered in Argon2 is going to make it worse than PBKDF2, and using PBKDF2 is just fine if that's all you've got.

Huh?

A password hash could happen to be reversible, or could map lots of passwords to the same value.

Re: Security Checklist

#56

Post by tptacek »

devit wrote: post #55
tptacek wrote: post #14

Earlier quoted context omitted.

No. The reason not to use Argon2 is that it doesn't have great library support yet. Password hashes don't really fail like ciphers do. Nothing that is discovered in Argon2 is going to make it worse than PBKDF2, and using PBKDF2 is just fine if that's all you've got.

Huh? A password hash could happen to be reversible, or could map lots of passwords to the same value.

No, neither of those things are going to happen.

It might happen if you designed a password hash from first principles, but that is not how Argon2 was designed, or, really, any of the Password Hashing Contest finalists. They're built on top of existing crypto primitives.

Re: Security Checklist

#57

Post by justinclift »

xpinguin wrote: post #26

I could call that list deliberately malicious from user experience standpoint: >Are password entropy checks done during user sign-up, using, say AUTH_PASSWORD_VALIDATORS? No. It's my information to be stolen, not yours. So then it is my choice, whether to use 123 as password or not. Why should I care to manage the complex password, when I use your service eg. twice an year and have no important information there? (if…

> As you could imagine, it takes several tries, dozen or two, maybe even three - depending on that cool password validator of yours.

That's confusing. Are you saying 3 dozen login attempts for an existing account shouldn't trigger a lock out?

That seems unusual. ;)

Re: Security Checklist

#58

Post by theandrewbailey »

tptacek wrote: post #4

Quibbles: * You're right now fine with 2048 bit keys. The thing that jeopardizes 2048 bit keys might end up knocking RSA out entirely. * There's really no point to fail2ban if you disabled passwords for SSH, and doing that is much more important than fail2ban. * The checklist item for password security should make it clear that you need a password hash (PBKDF2, bcrypt scrypt, Argon2), not just a "hash". Given the con…

4096 bit keys are useless if your root or intermediate is 2048 bit. How many CAs even offer 4096 roots and intermediates? Do CAs even bother to ask, or do they give you 2048 anyway, because FU?

Re: Security Checklist

#59

Post by theandrewbailey »

elchief wrote: post #16

4096 bit RSA key is overkill and slow. 2048 is fine for years You probably need to support TLS 1.1 for some older clients Password entropy checks should only be used in a corporate environment. You'll lose customers in a retail environment. You should certainly encourage your customers to use high entropy passwords, but forcing them to will just lose you money. Login throttling and IP banning is a waste of time. Logi…

I might be missing something, but I've never come across software having TLS 1.1 support without TLS 1.2.

Re: Security Checklist

#60

Post by elchief »

theandrewbailey wrote: post #59
elchief wrote: post #16

4096 bit RSA key is overkill and slow. 2048 is fine for years You probably need to support TLS 1.1 for some older clients Password entropy checks should only be used in a corporate environment. You'll lose customers in a retail environment. You should certainly encourage your customers to use high entropy passwords, but forcing them to will just lose you money. Login throttling and IP banning is a waste of time. Logi…

I might be missing something, but I've never come across software having TLS 1.1 support without TLS 1.2.

https://en.wikipedia.org/wiki/Template:TLS/SSL_support_histo...

Plus user agents that aren't browsers

Post reply on HN