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.

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

Merged
merged 9 commits into from
Mar 9, 2017

Conversation

itaifrenkel
Copy link

No description provided.

@itaifrenkel
Copy link
Author

@cottsak Could you please review this PR ?

@itaifrenkel
Copy link
Author

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

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.

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

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.
Copy link
Contributor

@cottsak cottsak Mar 9, 2017

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

@itaifrenkel itaifrenkel merged commit 6b37564 into master Mar 9, 2017
@itaifrenkel itaifrenkel deleted the link-to-idaas branch March 12, 2017 22:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants