Security Checklist • Hacker News Board

Re: Security Checklist

#61

Post by xpinguin » Tue, Mar 22, 2016, 5:48 AM UTC

justinclift wrote: post #57

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

No, it should not. Why it is unusual? Happens to me from time to time (not exactly three dozens, though, 20-25 attempts).

Re: Security Checklist

#62

Post by bweston92 » Tue, Mar 22, 2016, 2:26 PM UTC

koolba wrote: post #36

> Do you have an account recovery flow? Delete it immediately. Lol. Have fun doing this at scale for any consumer site. Like everything else in security, having a password reset/account recovery flow is a trade-off between security and convenience. For the vast majority of websites, convenience wins.

When I saw that all I thought was how else might a user recover their account?

Re: Security Checklist

#63

Post by justinclift » Tue, Mar 22, 2016, 10:03 PM UTC

xpinguin wrote: post #61

justinclift wrote: post #57

Earlier quoted context omitted.

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

No, it should not. Why it is unusual? Happens to me from time to time (not exactly three dozens, though, 20-25 attempts).

Lockouts on the 5th attempt is fairly common.

If you need 20-30 attempts to get into your own account... that sounds like you're doing something wrong. :(

Re: Security Checklist

#64

Post by andreyf » Tue, Mar 29, 2016, 6:28 PM UTC

tyingq wrote: post #28

andreyf wrote: post #22

Earlier quoted context omitted.

I thought this at first, too, but giving the author the benefit of the doubt, perhaps they meant that if someone deletes their account, you should actually delete their account, not just disable it. I haven't seen anyone do this, but as a user, I would prefer an option for my account information to be emailed to me in a relatively readable format, so that I can keep my data / re-upload it if I ever want to undelete m…

Sounds like a great idea, but I wouldn't word that as "Do you have an account recovery flow? Delete it immediately." Account recovery is shorthand for forgotton passwords and userids everywhere I look.

might be a stretch but https://en.wikipedia.org/wiki/Principle_of_charity

Re: Security Checklist

#65

Post by movedx » Wed, Mar 30, 2016, 9:25 PM UTC

nmjohn wrote: post #50

movedx wrote: post #40

Earlier quoted context omitted.

>> 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 t…

Looks like we will have to agree to disagree then. I've obviously had different experiences to you, and have seen disks being filled up, systems getting exploited after repeated attacks, and so forth, but you seem too stubborn to work with on this point.

Good luck!