SaaS CTO Security Checklist | Hacker News Reader

SaaS CTO Security Checklist

sqreen.com

407 pointsvinnyglennon107 comments

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

Easy to remember high-entropy pass phrases still makes the most sense to me, with maybe a number or symbol thrown in somewhere for added extra oomph.

correct horse 19 battery staple

https://xkcd.com/936/

Just don't use that as the key to generate your BitCoin address. I saw a funny video, can't remember where, where a guy does that to prove a point. He sends a small amount of BitCoin to the wallet address, and someone steals it within seconds.

There's an article floating around about Ethereum private keys, where people use "0x[...]0000" or "0x[...]0314" or what have you. You can check the corresponding public addresses on Etherscan and see funds being systematically siphoned out by the same few accounts.

Yeah but when you partner with companies, they sometimes force your company to adhere to those ancient guidelines.

I’ve worked for companies where they ask for the out of date NIST stuff you mention and it’s either you follow what they ask or you lose out on a deal to fund your company.

If you require PCI DSS compliance it won't fly either.

https://pcipolicyportal.com/blog/pci-compliance-password-req...

If you require PCI DSS I hope you're not just blindly following some random post on hackernews for your policy ;)

I'm not, that's why I know PCI DSS requirements off-hand.

No. You can use NIST guidance and are not required to change your password every 90 days

At least 8 characters, upper and lower, numbers and symbols... that advice is from the 70s [1]

[1] - https://security.stackexchange.com/questions/33470/what-tech...

fourwordsalluppercase

ONE WORD ALL LOWERCASE

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/

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.

I'm not sure I agree with that assumption, as the entire purpose of a passphrase of words rather than a password of random characters is that the passphrase should be easier to remember. If you're randomly picking words like 'gargarize-youster-noctivagant-axilla', it's not exactly accomplishing that purpose very well. It's also a huge PITA to type in, which based on my experience in the IAM space, is an immediate dealbreaker.

    $ egrep '^[a-z]{4,10}$' /usr/share/dict/words | wc
      50768   50768  433477
    $ for i in `seq 5`; do egrep '^[a-z]{4,10}$' /usr/share/dict/words | shuf -n 4 | xargs; done
    droned engraves developer manoeuvre
    lifeforms lurked pursuing subjugated
    hooligans underplay sudden command
    quartettes soapbox blacklist pigtails
    roughening chefs mortals earthy

In my experience, things like that are both easier to remember and to type than things like fa#klwgjl5235 - I type sequences of English words far more often than I type anything else.

I’d rather pick from obscure words I know than at random. In my case the words might lean tech/business/news/sports, but I’m sure I could come up with a good list. It might be interesting to try and generate passwords from a corpus of email and/or browsing history... assuming you blacklist sensitive subjects.

I let my password manager pick words for me, and I keep hitting refresh until I get one that I think I'm likely to get the spelling correct when needed.

1Password just gave me this: land convolve witchery bequest

Having said that, since I use 1Password, these are rare and almost exclusively used for things where I need very-short-term memorable passphrases for things that won't let me copy/paste from 1Password (like my Apple ID or the passwords my bank ask me for over the phone...) Everything else just gets 25 random chars (or the maximum number of chars the input will allow).

If i used that model i am pretty sure there would be some kind of proper noun or fantasy novel reference, meaning the Dictionary would need to be pretty extensive.

And - of course - Randall has us covered here too:

https://xkcd.com/1133/

A 1000 word vocabulary is quite understandable, though a little awkward.

A random word might be as few at 10 bits of entropy. If a person is picking them out of their head, I'd bet it's unlikely to be as many as 12 or 13 bits. Most of the words we "know" aren't ones that come to mind when we're "randomly choosing words"...

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 weathercocks

foremasts milkmaid bashful maddened

disposes shrunk propose stanchion

midwived romantics gallbladders spotlighted

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

What is the size of that dictionary?

About 60k words.

What I find interesting about the XKCD is that the entropy analysis is basically spot-on, even very generous towards the opposition. It shows that a) the typical "strong password" that people pick is not truly random (i.e. not 26+26+10+10, but worse), and b) that under these conditions even a 4-length pass phrase picked from a measly dictionary of 2048 words is better. (This is probably an even more interesting / compelling argument.)

Yet somehow, each time the XKCD is posted, someone will "point out" that pass phrases can be dictionary attacked, which is kind of like me saying "I know which letters are on your keyboard, and can therefore brute force your password!", but not having done the math beyond that.

This is really dependent on the size of the dictionary.

If your dictionary is smaller than 50,000 words, all you would have to do is add another word.

10,000^5 > 50,000^4

> assuming a dictionary size of 50,000 words

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

Quoting:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

- Passwords obtained from previous breach corpuses.

- Dictionary words.

- Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

- Context-specific words, such as the name of the service, the username, and derivatives thereof.

[1] https://pages.nist.gov/800-63-3/sp800-63b.html

If I read that correctly, it's about comparing the entire password, not portions thereof, so it's not really about "multiple English word" passwords (except that I assume "passwords obtained from previous breach corpuses" is likely to contain some specific examples of the breed, almost certainly including "correct horse battery staple").

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.

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 of it. MFA is a big part of why complexity is reduced in the NIST guide, and you MUST have it if you’re going to remove complexity requirements. If you can’t have MFA for some reason (and yes, there are legitimate reasons for this), then you still need to use complexity, expiration, etc.

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!.

I totally agree.

Every time I start in a new organization, I spend some time to sit down and make a very strong password. The kind of password I would trust my retirement savings to. I'll sit down and dedicate a solid 30 minutes to transforming a bizarre but easy to remember phrase in 20-30 special characters with abbreviations instead of full words. Then I'll spend the time to commit it to muscle memory. I've done this probably 30 times over the past 20 years.

60 days later, maybe I make another new very strong password. 60 days after that, it's 8:15 and my computer is forcing me to update my password and I have an 8:30 meeting and now my password is asdfg;lkjh. 60 days later it's asdfg;lkjh1. And so on.

Password expiration dates are one of those things that just don't work with human beings. It's the "work harder, not smarter" approach to security. Somebody wrote it down once, and now everybody who came along later copied the same bad checklist and added more bad things to it. Instead of working to improve the practical security of their system, they work to adhere to their arbitrary checklist. It only makes sense from the most cynical Dilbert perspective.

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

So much this.

If you make your security policies into a problem for your people trying to do their work, they'll find ways to work around it.

That either means 1) your policies are misplaced and you need to relax then, or 2) you need to fire everybody who creatively works around them.

If your adversary is Mossad, the option 2 is the right one. If your adversary is not-Mossad, you can almost certainly have a security policy that people won't feel the need to work around.

There are, of course, shades of grey below "Mossad adversaries", but in my opinion at the upper end of that you have policies that include providing every employee with a good password manager, TOTP apps/devices, and/or USB 2FA keys - and choosing services which integrate properly with them.

"Change your password every X days" is an admission that you're going to leak passwords somehow, and that you only care about your data/systems enough to close the attack window down to X days. Which means you're screwed before you start, and may as well just turn everything off now.

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.

This is simply not true. You can read SP800-63B Appendix A to see the rationale NIST provides for not enforcing password complexity; it has nothing to do with MFA, and NIST believes the old rules to be intrinsically bad.

> and as a result are actually causing many security problems.

That's completely contradictory to what the NIST guidelines state:

> The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought [Policies], although the impact on usability and memorability is severe.

It depends on your definitions of easy to remember, hard to guess. 6 dictionary words with one random character is sufficiently complex to thwart planetary scale brute force attacks. It's much easier to remember than 20 random ascii characters.

I use the first three letters of each word in book titles/song lyrics and a number that means something to me like 186282 (speed of light in a vacuum in miles per second) for master passwords everything else is stored in Keepassxc.

aphiofsofdes68537513 is good enough and defeats a dictionary attack.

It requires discipline but I’m responsible for people’s PII at work and I treat that seriously.

For my personal stuff I keep a separate vault but with the same criteria.

I did something similar but you really should get some randomness in there. If an attacker is brute forcing solutions, it's conceivable, even likely, that attackers are going to smash together datasets like song lyrics or anything that comes up high in a google search to prioritize the search space. You could search millions of permutations of song lyrics for the 50% most popular songs on Spotify. You could do the same with text previews for books on Amazon. It probably wouldn't take that long for a targeted attacker.

If 2fa is involved it's a different story, but if you're talking about something liiiike the pass key of a private key that you can't guarantee is secret? Or if it's the private key used to do things like sign certificates? Please add randomness.

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.

Discussed previously:

https://news.ycombinator.com/item?id=16615593

In the year this has percolated with me, I've grown to actively dislike it. I have three major problems with it:

1. This cutesey "seed, A, B" triage scheme is misleading. In reality, you can break everything down into just two categories: "do it before product/market fit" and "do it after product/market fit" (or "now" and "later", or whatever you'd like to call them).

2. Most of what this list defers to later phases shouldn't be deferred --- or at least, if you're going to do it at all, there's benefit to doing it early. Monitoring computers? Much harder to start at "series B". SDLC? Same. Share accounts until "series A"? I like how their product category, "RASP", is assigned "seed" stage, though.

3. It's not internally consistent, or, at least, to make it internally consistent you would have to make silly decisions. For instance: use 2FA where possible early, and later centralize authentication?

I feel like this list is unserious, and serves essentially the sole purpose of putting "RASP" on the "do now" agenda.

2FA on SaaS applications is free and easy, while centralising authentication is much harder - you need to manage an authentication platform instead of just using the application's own authentication.

Taken by itself the suggestion is odd, but in concert with the next entry "use password management software" it makes for a low-cost, zero management, higher security stance than not suggesting 2FA by itself. Noone should ever ignore the option to turn on 2FA.

RASP under "seed" did massively stand out as a "whhaaat?" moment

This list seems incredible helpful. As a security-conscientious CTO, one of the challenges I faced was determining how much we should be doing now (during YC and while raising our seed round) versus pushing down the line. For example, we obviously should be monitoring outdated and insecure dependencies from the outset, but when is the right time to switch our servers and external tools to centralized account management, or to pay for an external pen test.

Now, I would probably move the external pen test up to seed if the company is well-funded (e.g. post demo day) and holding PHI. But that’s personal preference and my security paranoia talking. Overall I think this list really gets it right.

I also liked seeing a recommendation against sharing your WiFi network in the seed stage. Network segmentation to separate your computers and IoT devices, printers, etc. should probably appear somewhere in series A/B.

The best indication that you need an external penetration test is that you have client prospects demanding to see the output of those tests. A less important indication would be that you (1) have product/market fit, (2) have implemented your core product, (3) can predict what development on that product will look like for the next 12 months, and (4) have revenue sufficient to eat the $20-30k cost of a penetration test.

I would not generally recommend that seed-stage companies contract out penetration tests simply because they've raised enough money to do so. You should be on a relatively stable, predictable path with regard to product engineering before you start asking contract pentesters to beat you up.

I feel like this is a pretty good illustration of how not useful lists like these are. It's simplified down to this "seed", "series A", "series B" thing in order to suit the format and make it punchy; the real, serious advice isn't as slick, and doesn't showcase their product, so it's nowhere to be found.

Having someone on the team who understands security (can be a security engineer who also writes software, or a software engineer who also has some serious clue about security) should happen as early as possible.

You will almost certainly need some form of authentication system in a couple places, and it doesn't take a lot to keep you from making the worst mistakes.

Once you've build your entire (internal or external) auth system in a broken way, fixing it afterward is much more expensive, and you can expect to have weekly breaches while you do it.

This doesn't need to be back-breaking (compare: WhatsApp), but it is avoidable.

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 quarterly".

I don't see any value in relating anything to the financial stage of the company because it's irrelevant.

Security also needs a time and priority aspect to it. For example if your company hasn't done anything on the checklist yet then what should come first, what is most important? Also it would be good to know what are the biggest typical weaknesses - a security chedclist can have so much stuff on it that it becomes hard to know where to focus.

> Checklist item 1: Hire an outside security auditing firm to report on the state of this checklist quarterly

Security auditing firms cost a lot of money. Money you don’t have when you’re a small startup. Besides, an auditor audits and the hard part about this list is implementing it. Until you can afford to hire someone to take care of security, it’s usually the CTO’s job to make sure security is not an afterthought.

> I don't see any value in relating anything to the financial stage of the company because it's irrelevant.

It is extremely relevant, for at least two reasons. The first one is that the company’s financial resources dictate what you can or cannot do (e.g. hire a dedicated security resource, pay for pen testing). The second is that some recommendations just don’t make sense before a certain size (e.g. there’s no sense in setting up an AD and GPOs when there’s just 3 of you in the company).

How lucrative is security work? It’s a direction I’ve been considering moving towards but the salary info I’ve seen is not great. Am I looking up the wrong terms/titles?

As an employee, application and infrastructure security work pays somewhat better than normal product engineering work (there are good jobs and bad jobs, of course).

There are lots of security jobs that don't pay especially well and are career dead-ends --- enteprise IT security isn't a good place to end up, nor is sales engineering ("security engineer") for security product companies, nor is malware analysis.

My feeling is that software/application security consulting is a reasonable route to go, if you want to work for a consultancy, but I'd be wary of any other kind of security consulting.

Thanks for the insight!

>if your company hasn't done anything on the checklist yet then what should come first, what is most important?

Security practitioners like to use the risk analysis matrix for this exact reason. One axis is likelihood of problem occurring (ranging from unlikely to almost certain) and the other is impact problem occurring will have on the business (ranging from embarrassing to bankrupting the business). As you can immediately see this is a very good tool to focus the efforts on the right remdiations.

Quarterly audits are very much out of the norm among SAAS startups. Checklists that don't reflect reality don't help anybody --- but then, I guess I don't think this checklist does, either.

> but then, I guess I don't think this checklist does, either.

Why do you say that? Do you think the items on the list are not useful/well prioritized? Or that most companies are not positioned/incentivized to follow most of this advice?

We use tools for automatic continuous assessment against a bunch of standards. They're not perfect but they help separate the signal from the noise immensely.

Continuous assessment is good (tool-driven continuous assessment can be sketchy), and is a norm at larger tech companies. Quarterly 3rd party assessments aren't, even at large companies (big companies might get many more than 4 audits per year, but will not as a rule re-assess things more often than annually or at major revisions).

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 than being specifically about actual funding levels.

Definitely open to feedback if that way of grouping things doesn't resonate!

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.

Cool idea! I like the self-assessment angle.

We wrote this for CTOs since prior to hiring a dedicated security engineer, security responsibilities in a company often fall to the CTO. But really, any more technical person in a company with some ownership or interest in security can leverage this.

The "SAAS security dashboard". Grab that domain!

Features:

- Including an overall alert status red/yellow/green.

- Critical issues rise to the top somehow for the team's attention.

- Mechanisms and best practices for reporting security issues.

- A knowledge base linking to relevant articles on each topic.

- A button must be pressed to say that backups have been tested, failing to do so raises alert level.

- Team members jointly contribute ratings out of 10 for the companies security practice in each checklist item

- Team discussions/actions/priorities.

- Register your companies tech stack with the service and it sweeps the net for security reports about stuff that you use.

- Integrate ansible to gather information about the versions of the software you are using and issue dashboard alerts when stuff in your software stack is vulnerable to attack.

- $5,000/month

- database lives on client site

etc etc

Don't know why I give these ideas away for free. Maybe I'll get onto building it!

I did - early beta. Based on my experience as CISO for SaaS a well as running security engineer team at a Fortune 5 company, performing Tier 1 PCI DSS, NESA, scans, etc https://joinsecurekit.com/

This sounds really good! I've just signed and I would definitely use this. I'd be happy to help with beta testing.

Would you be able to share some details about the pricing and business model?

EDIT: I get a "You are already signed in" error when I try to fill out the welcome form: https://www.dropbox.com/s/bfxfpm2tczbyn7d/Screen%20Shot%2020...

A lot of these features are actually already inside our product Sqreen, but it "only" starts at $250/month.

We're also hiring if you want to help us build the missing items ;)

What are the chances that the security auditing firm is going to look through code and find

  var sql = “select * from Users where firstname = ‘“ + firstname + “‘“;

  var s3 = new S3Client(secret_key,access_key)

"At Sqreen, for example, if someone catches another person’s laptop unlocked while they’re AFK, they can type “Cookies!” in that person’s Slack. That person will then have to bring in cookies for the office!"

This sounds like a fun idea, but has anyone ever refused to bring in cookies?

We would send emails to the office from unlocked machines.

e.g, long detailed emails about my little pony and asking to start a company My Little Pony fanclub.

Or similar for Celine Dion etc.

Change their wallpaper to something embarrasing, or their homepage etc.

Or just send out an email to everyone in the company saying how much you love everyone, and how lucky you feel to work with such lovely people xxx

In my experience, when someone refused was because he/she forgot to bring the reward. Some time ago, before Slack, we used to type "donuts" in the email's composer and send the message to the team's mailing list or to the full office.

Imagine your co-worker on the next day with two or three dozens of Krispy Kreme products.

I don't think you can enforce this, would be horrible for morale and probably illegal. I like to have similar "punishments" in my teams, people generally have fun with it. (And the rules apply to me too of course) But if someone doesn't want to, they can just ignore it. (Usually 1 in 10-20)

Multiple teams I've been on at multiple companies have done this process, but with donuts and other foods. A little bit of public shame goes a long way.

As our team is growing, having to bring cookies for a larger group can be a lot. Also, you're a bit less inclined if this happens to you two days in a row...

(message for Tyler: we're still waiting on those cookies)

This is exactly what the team I'm in does as well. It's fun, and people actually learn to lock their machines as a routine pretty quickly.

It's not something we hardcore enforce, since it's more about having a fun way to build good security habits with your devices. Being lightly called out in Slack has an impact in and of itself. The actual cookies are just a bonus. But people do like cookies, so there is some social pressure from your peers asking when the cookies are coming!

I'd be more inclined to do a "drinks" option.

Except for those that obstain. Of course, not all people can eat cookies either, I suppose.

It doesn't even have to be alcoholic drinks

Psst…I think you meant "abstain".

whoops

Solid milk chocolate! ;-)

A new take on "jinx you owe me a soda"

The slider of funding rounds is a neat idea but it's kind of hard to read in chronological order without mentally keeping track of which items appeared each time I slid it forward.

Would love to see a plain, non-javascript version of this content.

Don't know if the post author is the one who submitted it here, if so, it would be way nicer to read the list if items within each category (employees, code, ..) would be sorted by timeline (seed, series a, series b+).

Yea, this threw me off as well.

Thanks for the feedback! That makes complete sense. We are going to update that

While you're at it, "Monitor your user's computers" appears twice. The first time under your users appears to be correct, but the second occurence has a description about how lets encrypt is a free, easy to use option. I'm guessing the second heading should be "Use encryption on all your web sites and APIs" or similar?

Thanks! Deploying the fix and stealing your heading suggestion :)

> Connections to your infrastructure and non-public properties (hosted CIs, admin interfaces, databases etc.) should only be accessible through a bounce host (in a VPC, behind a bastion host or VPN, etc.).

How valuable is this?

I see articles for [1] and against [2] this practice.

And not a lot of interest in the subject from security SE. [3]

[1] https://cloudacademy.com/blog/aws-bastion-host-nat-instances...

[2] https://medium.com/@henriksylvesterpedersen/you-dont-need-th...

[3] https://security.stackexchange.com/questions/194024/should-i...

Lots of talk about passwords, but fewer about password managers. The password managers listed in this do not protect against backdoors. Lastpass, for example keeps all your passwords in plain text once you've unlocked it. Passwords stored in Apples Keychain can be synced across devices and a remote attacker can do something like a sim port, gain access to your iCloud account and then sync to their computer leaving you vulnerable.

Password managers should be bound to hardware tokens and each password should be individually encrypted, as well and individually decrypted that also force physical tap.

Password Store is a perfect example of this. Physical password managers are also on the rise, see: Ledger and Mooltipass

I don't believe it is the case that you can SIM-swap your way to someone's iCloud Keychain. Despite the "iCloud" in the name, it's not simply a file stored on iCloud; it's bound by keypairs to both devices and your iCloud password.

I think you need to provide approval from one of your other devices, or enter your iCloud security code before the sync can occur.

iCloud security code can come over SMS if your account is configured as such, therefore the above example of a SIM port applies

No, the iCloud second factor can come over SMS. That's not the same thing as your iCloud password.

I'm not 100% sure about this, since it's been a while since I've added a device to my iCloud account, but IIRC the prompt is not the standard 2FA one: it basically asks you to approve the addition from another device, or forces you to use your security code.

They also have a good free site security eval:

https://www.sqreen.com/scan

It was after that I found out the only way to have HSTS for Cloudfront/S3 is creating your own Lambda@Edge function [1] :/

[1] https://aws.amazon.com/blogs/networking-and-content-delivery...

The correct entry URL appears to be https://www.sqreen.com/scanner .

This is... not a useful general-purpose scan tool for web APIs. A warning because port 443 is open, no kidding? And a lot of carping about HTTP headers relevant to frontend apps.

While it's easy to pick holes in specific areas of this, overall I really like the layout and presentation of the advice.

[The SaaS] CTO Security Checklist

Just a small correction.

The majority of these items are applicable to any startup.

It kinda reminds me of TwistLock (which just got bought for a boatload of money).

SAASPASS can do most of the items covered. 2FA Computer Protection with 2FA Enterprise Password Manager Single Sign On Directory Services

It's not exactly sporting to plug the product you work on without disclaiming that you do[0].

It also seems half-baked, to be frank, and really doesn't seem like it does "most of the items covered". The badly-written marketing all over your website immediately makes me think you're borderline scammers, too--I've got my beefs with Okta but they aren't trying to scare me about "man-in-the-mobile" attacks just because they use push notifications rather than SMS.

If you're serious about putting forward your product as a serious option in this space, can you tell us why we should trust you and how you're demonstrating that you deserve it?

[0] - https://news.ycombinator.com/item?id=19714999

Reply on news.ycombinator.com