Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

move OWASP up, and a more broader link. prefer auth as a service though #29

Merged
merged 9 commits into from
Mar 9, 2017
Merged

move OWASP up, and a more broader link. prefer auth as a service though #29

Changes from 7 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
1c61cfc
move OWASP up, and a more broader link. prefer thrid party products t…
itaifriendingerforter Mar 8, 2017
b16558d
fix link
itaifriendingerforter Mar 8, 2017
a2fe0b7
fix link again
itaifriendingerforter Mar 8, 2017
20fe5f3
added more info to the idaas
itaifriendingerforter Mar 8, 2017
336a95d
Update security.md
Mar 8, 2017
7d665b9
Merge remote-tracking branch 'origin/master' into link-to-idaas
itaifriendingerforter Mar 9, 2017
ca7d186
move hash passwords to second pahse
itaifriendingerforter Mar 9, 2017
87278c5
Update security.md
Mar 9, 2017
db5d9af
Update security.md
Mar 9, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 11 additions & 10 deletions security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,15 +67,6 @@ Monitor your endpoint's public certificate expiration date, to detect prevent ce

Remember that SSL encrypts network traffic, but does not supply authentication. SSL is also not a replacement for 2FA.

### Hash your customer's passwords with a proper password hashing function

This might seem to technical and for your developers eyes mostly but you need to be prepared for that data breach and this is low effort - high reward! If your database was breahed and published it's much worse when your customers' passwords are included and easily cracked - folks reuse passwords. [It's true](http://mashable.com/2017/02/28/passwords-reuse-study-keeper-security).

* Use a well known hashing algorithm to store customers passwords in your database: bcrypt, PBKDF2 or scrypt with a work factor that takes [about 1 second for the password hash](http://security.stackexchange.com/a/3993/69959).

* Do not use MD5, SHA1 or other hashes that are *not specifically designed for passwords*. Passwords stored like this are cracked in seconds usually.

* [Follow the OWASP guidance](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet) and demand your developers hash passwords using one of the above.

### Picking a SaaS vendor

Expand Down Expand Up @@ -149,6 +140,16 @@ Using git would allow you to add outsource/freelance developers for a limited ti

* There are extra protection products on top of an antivirus called EDR (Cyberreason, BlackCobalt) but these are usually costly.

### Hash your customer's passwords with a proper password hashing function


If you can afford it, use a [third party authentication service](#customer-users-management) to handle password storage, password management and password recovery.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree that a third party authentication service is "security 101". This is a decision that needs to be weighed more carefully than just hashing passwords right.

Additionally, chances are that devs are going to pull a package and store internally in 90% of cases in the first instance/version/mvp. This "101" advice just reminds/informs them to use a hashing function specifically designed for passwords. I think adding the complexity of a third party service is more cognitive load and potentially another instance of indirection.

Aside: if you care for advice, try to keep the #UX of even this document in mind: you don't want it to become too big to navigate. Folks will churn if they can't move from section to section easily without being bogged down with so many different suggestions. You don't need to please everybody, cater for all vendors or cover every possible alternative. An opinionated view might help to keep this concise and easy to consume. HTH

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cottsak Regarding your first point. Hashing passwords right is only 1 task out of 4 or 5 that you need to get right in order to have a proper login experience. think about MFA, about password policies, about proper forgot-my-password. These are today a de-facto standard, and the developers would need to code that too. Take a look at Okta Platform for example. They provide both white labelling (meaning you can use them as an authentication service API), or you can use them as a user interface to provide your customers. Their pricing is active monthly users, so it could work pretty well even for small startups.

For the second point, I didn't think to put the hashing password section at all, just because I really believe developers have no business writing that code themselves. So I prefer to cut down on subjects, but have each subject explicitly defined in terms of pros cons. Although I agree we will have to refactor it to be more wiki like (vs one long document).

Copy link
Contributor

@cottsak cottsak Mar 9, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You loose points with me for using the non-word "Architected" 😛: http://developer.okta.com/product/

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah. well, where I come from LGTM is also a verb, so....

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@itaifrenkel okta looks interesting! Is it a hosted platform entirely or middleware as well?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the second point, I didn't think to put the hashing password section at all, just because I really believe developers have no business writing that code themselves. So I prefer to cut down on subjects, but have each subject explicitly defined in terms of pros cons. Although I agree we will have to refactor it to be more wiki like (vs one long document).

Developers may not need to implement all of the authentication logic themselves - that's what packages and hosted platforms are for. However, they need to take responsibility for it still! And if their framework/package/platform is hashing passwords badly (MD5, SHA1, etc - anything except bcrypt/PBKDF2/scrypt) then they need to intervene. Most middleware will allow overriding of only parts of the system (ie. the password hashing) so that it's straightforward to change what you don't agree with. Go with the hosted platform if it meets the guidance. But the guidance should remain absolute - that's what I'm trying to add here: the guidance.


However, if you decide to develop your own password implementation, try doing it according to the [OWASP authentication guidelines](https://www.owasp.org/index.php/Authentication_Cheat_Sheet) .
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 with the higher-level link

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this "if you feel like it" tone: try doing it

This is security advice. It's supposed to be imperative. I would use the simpler wording use the rather than try doing it according to the.


* If your database was breached and published it's much worse when your customers' passwords are included and easily cracked - folks reuse passwords. [It's true](http://mashable.com/2017/02/28/passwords-reuse-study-keeper-security). Therefore, always use a well known hashing algorithm to store customers passwords in your database: bcrypt, PBKDF2 or scrypt with a work factor that takes [about 1 second for the password hash](http://security.stackexchange.com/a/3993/69959). Do not use MD5, SHA1 or other hashes that are *not specifically designed for passwords*. Passwords stored like this are cracked in seconds usually.
Copy link
Contributor

@cottsak cottsak Mar 9, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're going to keep this paragraph please replace well known hashing algorithm to store customers passwords in your database with hashing function *specifically designed for password storage*

The emphasis is really important.



### Physical Security

* Configure laptops to sleep after (at most) 5 minutes you are away from your desk, and require a password to re-open it. Ask employees to lock their laptops manually when they leave their desks, for example using [hot corners on macOS](https://support.apple.com/kb/PH18796), or by pressing logo key + L on Windows.
Expand Down Expand Up @@ -249,7 +250,7 @@ At this point you should already have automated testing, and (at least semi-) au

There are a number of Identity as a Service vendors that supply login and customer's password management services. If such a vendor is SOC2 Compliant they probably do a better job than you saving the customer's password in your database.

They also provide self service and apis to provision and de-provision users. Although, large customers might want integration with their own Identity management solution.
They also provide self service and apis to provision and de-provision users, enforce password policies, and recover lost passwords. Although, large customers might want integration with their own Identity management solution.

### Sensitive Data Leaks

Expand Down