-
Notifications
You must be signed in to change notification settings - Fork 292
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.
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
move OWASP up, and a more broader link. prefer auth as a service though #29
Conversation
@cottsak Could you please review this PR ? |
@cottsak I think this PR is ready too. WDYT? |
security.md
Outdated
### 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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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/
There was a problem hiding this comment.
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....
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
security.md
Outdated
|
||
If you can afford it, use a [third party authentication service](#customer-users-management) to handle password storage, password management and password recovery. | ||
|
||
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) . |
There was a problem hiding this comment.
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
security.md
Outdated
|
||
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) . | ||
|
||
* 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. |
There was a problem hiding this comment.
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.
security.md
Outdated
|
||
If you can afford it, use a [third party authentication service](#customer-users-management) to handle password storage, password management and password recovery. | ||
|
||
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) . |
There was a problem hiding this comment.
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
.
No description provided.