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

SaaS CTO Security Checklist

sqreen.com

Post reply on HN
Print view View original

41–50 of 114 posts

Re: SaaS CTO Security Checklist

#41

Post by wiml »

ddxxdd wrote: post #22
jupp0r wrote: post #18

> Enforce a password policy > (links to https://www.digicert.com/blog/creating-password-policy-best-... ) where they give the usual (at least 2 special characters, but not " or \) advice This is counterproductive and is actually discouraged by the latest NIST guidelines, that prefer passwords that are easy to remember, but still hard to guess [1]. [1] https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...

What does NIST have to say about passwords like CorrectHorseBatteryStaple [0] that can be easily cracked by brute-forcing concatenations of dictionary words? [0] https://xkcd.com/936/

They can't be, unless you generate them badly.

A diceware passphrase has 6^6 possibilities ≈ 15 bits of entropy per word, so an unremarkable 5-word password has 77 bits of entropy — generally good enough — and if you have a high value target that might be susceptible to offline attacks, 90-100 bit passwords are still pretty easy to remember.

I wish people wouldn't use XKCD as the go-to reference for "collection of randomly selected words"-style passwords; it always seems to leave people confused about why the technique works.

Re: SaaS CTO Security Checklist

#42

Post by codetrotter »

montecarl wrote: post #30
cardine wrote: post #24

Earlier quoted context omitted.

Even if you knew the pattern, four random lowercase dictionary words (assuming a dictionary size of 50,000 words) would take longer to crack than a randomly generated 10 digit password with letters, numbers, and special characters. 50,000^4 > (26+26+10+10)^10

Its not quite fair to assume that people are choosing randomly from 50k words. Here is what those passwords look like. I excluded proper nouns and possessives. If you want to try, this command works on Ubuntu: echo $(cat /usr/share/dict/american-english | grep -v \' | egrep -v '[A-Z].*' | shuf -n 4 | tr '\n' ' ') trawled scratch protract sagings perpetuates barium entreated credits integrals virago chronicled weather…

Good point. The EFF has made and published three lists of words to use that are easy to spell and generally easy to remember.

I wrote a command-line tool in Rust for generating passphrase using these wordlists. I use it myself any time I need a password.

My tool is fast, free of charge, open source and it can also tell you the entropy that will result for any given choice of number of words.

For example let’s say I want it to give me four words from the long wordlist, and I want to know how many bits of entropy this corresponds to.

    pgen -l -n 4 -e

    Current settings will create passphrases with 51.70 bits of entropy.
51.70 bits of entropy.

What does that mean, you might ask.

The Wikipedia article on password strength (https://en.wikipedia.org/wiki/Password_strength) explains it well:

> A password with an entropy of 42 bits calculated in this way would be as strong as a string of 42 bits chosen randomly, for example by a fair coin toss. Put another way, a password with an entropy of 42 bits would require 2^42 (4,398,046,511,104) attempts to exhaust all possibilities during a brute force search. Thus, by increasing the entropy of the password by one bit the number of guesses required doubles, making an attacker's task twice as difficult. On average, an attacker will have to try half the possible number of passwords before finding the correct one.

Ok, so how good is 51.70 bits of entropy, you ask?

Wikipedia, same article again:

> The minimum number of bits of entropy needed for a password depends on the threat model for the given application. [...] RFC 4086, "Randomness Requirements for Security", presents some example threat models and how to calculate the entropy desired for each one. Their answers vary between 29 bits of entropy needed if only online attacks are expected, and up to 96 bits of entropy needed for important cryptographic keys used in applications like encryption where the password or key needs to be secure for a long period of time and stretching isn't applicable.

So let's say that you are satisfied with 51.70 bits of entropy in this case. What does a password like that look like? Let's generate one.

    pgen -l -n 4

    plastic case refocus demise
Pretty memorable if you ask me :)

Oh yeah, and about the claim that it's fast. Just how fast is it? Have a look.

    time pgen -l -n 4

    browbeat hummus sandbox unfixable

    real    0m0.005s
    user    0m0.001s
    sys     0m0.006s
That's 5 milliseconds.

But hey, let's say we wanted to generate a bunch of passphrases at once.

How much time does it take to generate 10.000 passphrases and dump them into a text file?

    time pgen -l -n 4 -k 10000 > 10k.txt

    real    0m0.132s
    user    0m0.073s
    sys     0m0.058s
About zero point one seconds. Not that generating 10.000 passphrases is something that you are likely to do, but it just speaks to how fast this tool is ^^

Source and instructions on how to install it are on GitHub.

https://github.com/ctsrc/Pgen

Re: SaaS CTO Security Checklist

#43

Post by andrewstuart »

jdreyfuss wrote: post #33
andrewstuart wrote: post #15

I really like this idea - alot. But aimed perhaps at everyone, not just the CTO. In fact the CTO probably needs one thing on their checklist. Checklist item 1: Hire an outside security auditing firm to report on the state of this checklist quarterly". And if the company has the financial resources: Checklist item 2: Hire a second, independent outside security auditing firm to report on the state of this checklist qua…

Checklist author here. Glad you liked the idea! Figuring out a clean shorthand way to group these best practices was something we definitely thought about. The idea behind using funding rounds was to find something that can work as an easily digestible placeholder for company maturity and capabilities for most SaaS startups. Something closer to “just starting out,” “product-market fit,” and “starting to scale” rather…

Maybe this concept should just get rid of the CTO aspect and position it as the "SaaS security checklist".

Then gamify it so that all the technical people in the team can each give their independent rating of how the company performs on each checklist item.

Then give each checklist item and owner and assign action items, status and followup discussion.

The outcome of that is something the CTO would be interested in because it would be a dashboard with accountability.

Re: SaaS CTO Security Checklist

#44

Post by TrueDuality »

orev wrote: post #28
jupp0r wrote: post #18

> Enforce a password policy > (links to https://www.digicert.com/blog/creating-password-policy-best-... ) where they give the usual (at least 2 special characters, but not " or \) advice This is counterproductive and is actually discouraged by the latest NIST guidelines, that prefer passwords that are easy to remember, but still hard to guess [1]. [1] https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...

Starting to feel like this is one of those things that people just blindly parrot all over the Internet without understanding the full context of the NIST guidelines, and as a result are actually causing many security problems. You can’t take one recommendation that you like out of a whole body of work and start running around telling everyone to do this one thing. If you’re going to follow NIST, you need to do all o…

They actually increased the password strength recommendations in the newest guidelines. Length counts more towards the security of the password than character classes which was increased.

Even without MFA the lack of password expiration is still considered best practice. It's not just parroting.

Separately though applying MFA anywhere possible is a best practice and should be separately encouraged from the strength and rotation policies.

Re: SaaS CTO Security Checklist

#45

Post by [deleted] »

txcwpalpha wrote: post #36
cardine wrote: post #24

Earlier quoted context omitted.

Even if you knew the pattern, four random lowercase dictionary words (assuming a dictionary size of 50,000 words) would take longer to crack than a randomly generated 10 digit password with letters, numbers, and special characters. 50,000^4 > (26+26+10+10)^10

It would be very interesting to see the results of a study asking people to come up with a list of random words. I really doubt that the actual dictionary size would be anywhere near 50k, and probably would have a high frequency of common words like 'apple', 'house', 'food' etc, making them easier to crack, and almost no frequency of less common words.

[deleted]

Re: SaaS CTO Security Checklist

#46

Post by dyu »

txcwpalpha wrote: post #36
cardine wrote: post #24

Earlier quoted context omitted.

Even if you knew the pattern, four random lowercase dictionary words (assuming a dictionary size of 50,000 words) would take longer to crack than a randomly generated 10 digit password with letters, numbers, and special characters. 50,000^4 > (26+26+10+10)^10

It would be very interesting to see the results of a study asking people to come up with a list of random words. I really doubt that the actual dictionary size would be anywhere near 50k, and probably would have a high frequency of common words like 'apple', 'house', 'food' etc, making them easier to crack, and almost no frequency of less common words.

the assumption is you do not come up with your own words, and pick words at random from the whole dictionary.

Re: SaaS CTO Security Checklist

#47

Post by privateSFacct »

technion wrote: post #31
orev wrote: post #28

Earlier quoted context omitted.

Starting to feel like this is one of those things that people just blindly parrot all over the Internet without understanding the full context of the NIST guidelines, and as a result are actually causing many security problems. You can’t take one recommendation that you like out of a whole body of work and start running around telling everyone to do this one thing. If you’re going to follow NIST, you need to do all o…

If for some reason you're stuck without MFA (and I appreciate why it happens), I can't agree short expiration adds value. I've done brute force exercises. Some people always pick bad passwords. Tell an organisation to change every 60 days and a lot more people give up and land on May2019!.

This 100%.

I have a complicated google password - I use it no where else. I have a security key. In 12 years I've NEVER had to change my google account password AND I have not been hacked. This works well. Because google is resistant to brute force I don't even bother adding tons of weird special characters.

I worked at a govt related agency. They had to change passwords every 30 days and there was a dual password requirement (one to login to the VPN, the next for the app). Result?

  - Many folks used a shared account with a public password emailed out every 30 days so everyone else did not have to deal with all the hassles of the password expiration dance. It was also super hard to onboard anyone new (ie, 3-4 months for staff with 12 month projects) This account ended up posted next to every computer.
The idea that making security so user unfriendly will makes folks like and use security is a ridiculous approach.

- Rate limit attempts - Block after 4 tries for an hour, after 8 tries till a reset - Screen against password lists - Screen out other obviously bad (ie, too short etc). - Allow hardware 2fa BUT allow staff to validate computer.

This alone gets you a ton of mileage

Re: SaaS CTO Security Checklist

#48

Post by GuB-42 »

orev wrote: post #28
jupp0r wrote: post #18

> Enforce a password policy > (links to https://www.digicert.com/blog/creating-password-policy-best-... ) where they give the usual (at least 2 special characters, but not " or \) advice This is counterproductive and is actually discouraged by the latest NIST guidelines, that prefer passwords that are easy to remember, but still hard to guess [1]. [1] https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...

Starting to feel like this is one of those things that people just blindly parrot all over the Internet without understanding the full context of the NIST guidelines, and as a result are actually causing many security problems. You can’t take one recommendation that you like out of a whole body of work and start running around telling everyone to do this one thing. If you’re going to follow NIST, you need to do all o…

There are guidelines for just passwords that don't involve MFA. Very important ones few people do, because it is not trivial to implement.

- No password that is part of a leak. It requires maintaining a database, or using an online service.

- No upper limit on length and character set. It requires full Unicode support and proper string processing.

Re: SaaS CTO Security Checklist

#49

Post by dllthomas »

ddxxdd wrote: post #22
jupp0r wrote: post #18

> Enforce a password policy > (links to https://www.digicert.com/blog/creating-password-policy-best-... ) where they give the usual (at least 2 special characters, but not " or \) advice This is counterproductive and is actually discouraged by the latest NIST guidelines, that prefer passwords that are easy to remember, but still hard to guess [1]. [1] https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...

What does NIST have to say about passwords like CorrectHorseBatteryStaple [0] that can be easily cracked by brute-forcing concatenations of dictionary words? [0] https://xkcd.com/936/

> easily cracked by brute-forcing concatenations of dictionary words

This is probably misleading (and possibly confused).

Diceware style passphrases are easily brute forced relative to a random passphrase of the same length but that doesn't mean they're "easily brute forced". Assume your attacker knows how you're constructing your password, estimate the amount of entropy, and be sure it's enough.

44 bits is low for offline attacks, but (as the comic points out) still better than a lot of passwords people use even when they're trying to make a good password and following NIST guidelines. If you use 5 words and draw from a longer list, it's easy to be solidly out of the range that's crackable on modern hardware.

Re: SaaS CTO Security Checklist

#50

Post by montecarl »

j88439h84 wrote: post #39
montecarl wrote: post #30

Earlier quoted context omitted.

Its not quite fair to assume that people are choosing randomly from 50k words. Here is what those passwords look like. I excluded proper nouns and possessives. If you want to try, this command works on Ubuntu: echo $(cat /usr/share/dict/american-english | grep -v \' | egrep -v '[A-Z].*' | shuf -n 4 | tr '\n' ' ') trawled scratch protract sagings perpetuates barium entreated credits integrals virago chronicled weather…

What is the size of that dictionary?

About 60k words.
Post reply on HN