I know the majority decision is keys over passwords but every time I hear a security issue its over keys being stolen as typical malicious programs knows the standard go to place to grab them after getting you to sudo something evil. and the next response is you have time to change them before blah blah blah but attackers don't send you a email that says hey I have your keys! Wouldn't fail2ban with passwords be better for those who don't know how to manage every step of this ?
Security Checklist
41–50 of 65 posts
Re: Security Checklist
#42> 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...
A friend and I made this for fun. It is a joke and only here for entertainment value, don't put it in production. https://github.com/JonZudell/Genetic_Expression
Re: Security Checklist
#43> 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".)
Re: Security Checklist
#44I 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…
> No. It's my information to be stolen, not yours. And when the site gets broken into years later, irresponsible users (or "morons" as you put it) will pillory them publicly even though it's their own damn fault for using a crappy password or using the same password for their email. The number of people who will stop using a site because they can't meet basic password strength requirements is minimal and not worth ca…
>irresponsible users (or "morons" as you put it)
Me?! God is my witness, I do not. Rather, it is creators of that "checklist", who suggest that your users are idiots, who should be punished even for being unable to remember their password. IMHO, the really bad thing about the list is the fact that technically legit (I am not a webdev though) points are casually mixed with statements implying derogatory stance towards target users. I do not want you to control the ways I manage my information, that's the point of my rant.
After all, it is not a big deal if some crappy SV startups whose ultimate fate is to die silently after an year or two anyways, will adopt the practice. Problem arises when thing would go in the wild, bringing only headache and distraction to those who is able to control their information flow.
Re: Security Checklist
#45I 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…
> It's my information to be stolen, not yours. Many computer logins protect information other than the password-bearer's- for example, any business or government. As a result it's best to consider it, then discard as your use case may require. I absolutely agree on the account recovery point - it WILL happen, your choice as designer is just whether it happens within a designed process or without.
>Many computer logins protect information other than the password-bearer's
That is my problem, as the user, not yours. If you'd like to help, then just put some warning or notification on the form, and I'll appreciate that. Just don't prohibit registration if password of my choice is eg. '1'.
Most of the time, your bussiness - is your service, not the access to it.
Re: Security Checklist
#46> Do you have an account recovery flow? Delete it immediately. What about users who need to, you know, recover their account?
This checklist was designed for corporate-to-corporate and corporate-to-military sites which host data deemed valuable. If you are designing consumer websites where the user data is not particularly sensitive, then this advice is not appropriate.
In my applications, it was the customers who demanded that account recovery flows be removed, which I imagine is far from your own experience.
I will make a note about the intended customer group in the page . . .
Re: Security Checklist
#47Good 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.
Re: Security Checklist
#48It'd be nice if this was an actual checklist. i.e. checkboxes rather than images of a checkmark so that you could run through it.
I thought so too. I also thought it so too so I created this: https://github.com/gshaw/security-checklist
Damn dude. This looks way nicer than my page (and has links to hipper tools) . . . I need to take a course in web design . . .
Re: Security Checklist
#49I don't see e.g. a GitHub repo to comment on, but the HSTS header example is `Strict-Transport-Security: max-age=63072000; includeSubdomains; always` `always` has no meaning, and probably indicates a typo in an nginx configuration. As others have pointed out, there is other TLS advice here that you shouldn't follow blindly, like a 4096-bit cert (especially if your intermediate is smaller) or TLS 1.2 only. Rationales…
The 'always' was a typo, thanks for the catch.
Re: Security Checklist
#50There's a problem with viewing security as a "checklist" problem, it treats everything as binary, black or white problem/solutions. In reality, this is _far_ from the case. For example: > Is TLS1.2 the only supported protocol? Do you know what the implications are from actually implementing that? One probably should do additional research before making that decision. > Have you ensured that your content cannot be emb…
>> Are you using fail2ban to throttle ssh login attempts? >> Have you disabled password-based login over ssh, and only allowed key-based login? > The first really is of debatable value if the second is also used. Actually, no. It makes perfect to block repeat offenders because they might get lucky; they might be exploiting an RCE you're not aware of that takes multiple steps; and they could be trying to DoS that serv…
> Besides, the right answer is: use bastion hosts to proxy SSH connections, preventing them from the outside world
Agreed
> It makes perfect to block repeat offenders because they might get lucky
No, just no, please don't spread this nonsense. There is no such thing as "lucky" when the probably being discussed is 1 in (2^4096 - 1).
> they might be exploiting an RCE you're not aware of that takes multiple steps
I'll take my chances. If unauthed RCE exists in SSH (regardless of number of attempts required) there are far more serious implications than any server I manage. Additionally, I'm curious if you have an existing CVE where this kind of exploit has ever been discovered.
> they could be trying to DoS that server by filling the logs and thus your disk ... this isn't too hard to imagine
Hard to imagine? No. have I ever actually seen in the real world? Also no. Even if one server happened to be dos'ed by this, not a big concern, that's why you run multiple redundant servers behind a load balancer. The only viable attacks would be random in nature since attackers have no idea what the IPs of your actual app servers are. (And if someone can mount an attack that can determine them, you probably have bigger problems then a dos attack from ssh logs)
All in all, I feel like this just strengthens my original point, of viewing security as a checklist is a dangerous approach, one needs to actually understand what they are doing.
I'm all for layered security, but the problem with using it just because "why not" is that this methodology leads to an environment where there is so much "stuff" nobody knows what is secure, what is not secure, and what strange dependencies were the only reason something was secure in the first place. As far as security goes, everything should have a well-defined purpose.