Long time software architect, CTO Authress, creating application security plug-ins for any software application with Authress. Talk to me about security in microservices or service authorization.
A lot of this is very good advice. However I would add a couple of things:
DoS protection is best done using user identity rather than ip address. With cloud providers and potential DDoS attacks I would not rely as much on ip. Since most cloud providers can help with this, pull in one of those like WAF in AWS.
You don't need CSRF if you use SameSite=Strict and you really should be setting this to be true for all cookies. (This was missed when talking about cookies, and it is really easy to do.)
Passwords in 2021? really? Use WebAuthN and social logins and don't bother with trying to hash them. Even the bcrypt set up that was suggested here is now no longer the best practice, it's argon2, although at some point that will also be not the best solution either.
Data validation can and should actually be done before the controller handles the user input. The best way to do this is using an openapi specification verifier. We use api-scheme-validator it's awesome, and there are more complex ones available for different frameworks.
On the AuthZ side, you really need more than ACL lists, they don't provide comprehensive understanding of what your users are doing and who has access to what. It works for one service with simple permissions. But when you have lots of users which multiple services scaling up, you need more control and visibility than that. In those cases you need Authress to handle all the multitenant permissions cases.
I would never consider it a good practice to force anyone to use social sites if they want to use a webapp.
As an optional alternative, sure (personally I wouldn't offer FB login at all and I would never use sites that need it, but that's just me) but not as a full replacement.
Oh, so you want to browse my blog / shop in my store but first you must hand over your data to Facebook / Google. Because security.
Absolutely, password are deprecated. That's why nobody uses them anymore and the very few websites that use them are compromised 10 times a day.
Just gonna send an email link to an email address based solely on the existence of that email, which the user is going to access with a ... password. There, the bucket was kicked down the road a bit more.
Points:
passwords are acceptable. Not great or perfect, but acceptable. YOUR system needs to be secure, but you can't aim to protect people from themselves. There's no way to do that reliably that doesn't also deterr users from using your system. Sure, if you have a role system whereby a compromised account can be user to elevate access, then it stands to reason to aim higher - but that's not useful for end-user facing systems.
there are good systems of user/access management that you can reliably defer authentication and authorization to (Azure AD or even identity management systems like Okta). It's not necessarily because they are password-less but because authentication can be customized (eg: you can let the users decide what they want to login with: password, social, user management systems, magic links or simply default authentication to the use of given networks) and you can also restrict access based on chosen methods or disable certain methods in certain situations (eg: with Okta you can enable facebook login but say facebook has a breach -> then you can relegate facebook-enabled accounts to a different method).
"That's why nobody uses them anymore and the very few websites that use them are compromised 10 times a day" - What is your source for these facts, or are they just opinion?
Long time software architect, CTO Authress, creating application security plug-ins for any software application with Authress. Talk to me about security in microservices or service authorization.
That's because most companies are not security competent. Sure I would never hand my data over to Facebook, but Google has proven they don't know what do with it anyway. Realistically you must trust some repository for storing access credentials. Using federated login is much safer than using Lastpass, 1Password, etc... If you want a privacy first federated login, come talk to me in a couple of months, Authress will have that capability.
If you don't use a social login, the site you are using will most likely leak all your data. And sure for a blog you can argue nothing bad, but a site that I put my credit card in, I would never trust that site to handle my data correctly. It usually ends up like this: Hacked home cams used to livestream police raids in swatting attacks.
For credentials, sure. But social login doesn't come with simply credentials storage but with an agreement to allow monitoring online behaviour to the extent that a user needs to put in place a lot of serious safeguards to protect their data and prevent traces, doubly so if they have social media presence.
Without social media profile, some generic data can be leaked, but it's much easier to prevent it even with basic modern browser enhancements.
Password storages, I trust (so far) which is why I prefer the password storages + generated password rather than social login.
Unless you mean biometrics, I don't see how that goes. Social login means the password is handled by Facebook. But it's still a password just somewhere else, incidentally with a bigger footprint, a bigger target both for hacking and phishing. I have nothing against providing social login as an alternative, just not a replacement for user password (with 2fa, maybe).
If there's a breach on their side, you can't do much except remove that provider.
I did a fair bit of reading on CSRF. While we should always try and use SameSite attribute for cookies, it is not a fool-proof method for protecting against CSRF. CSRF token should still be used. The SameSite=Strict will only work for browsers that implement this feature. If a user uses a browser which does not support it, they can be vulnerable. Additionally there are ways to bypass this feature even for browsers supporting SameSite attribute.
It is important to note that this attribute should be implemented as an additional layer defense in depth concept. This attribute protects the user through the browsers supporting it, and it contains as well 2 ways to bypass it as mentioned in the following section. This attribute should not replace having a CSRF Token. Instead, it should co-exist with that token in order to protect the user in a more robust way.
Long time software architect, CTO Authress, creating application security plug-ins for any software application with Authress. Talk to me about security in microservices or service authorization.
If you are using REST APIs to secure content and not sending it back as part of a SSR. Then those bypasses don't apply. Since it isn't secure to send content back as part of page navigation anyway. CSRF can entirely be replaced by SameSite.
I would argue that many things you list are controversial.
First, not everybody is building secured services on cloud, and many developpers are building in enterprise private infrastructures.
For many of us:
exit social auth, but use openid connect on your validated provider (in enterprise there's a chance you have one if your are in medium or Big company). But the result is the same, decoupling the authentification stack from your code is better. You finally only need to validate a JWT.
exit authress, i think you are biased, because it's your product. Try to detach yourself when giving advices. This service, to be honest sounds like an horrible Idea. I prefer building my own IAM on top of an opensource one than using a service like that.
i appreciate your suggestions but here is my reverse suggestion for webauthn caniuse.com/?search=webauthn check it out, very incompatible on many browsers
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A lot of this is very good advice. However I would add a couple of things:
SameSite=Strict
and you really should be setting this to be true for all cookies. (This was missed when talking about cookies, and it is really easy to do.)bcrypt
set up that was suggested here is now no longer the best practice, it's argon2, although at some point that will also be not the best solution either.I would never consider it a good practice to force anyone to use social sites if they want to use a webapp.
As an optional alternative, sure (personally I wouldn't offer FB login at all and I would never use sites that need it, but that's just me) but not as a full replacement.
Oh, so you want to browse my blog / shop in my store but first you must hand over your data to Facebook / Google. Because security.
Totally agreed. A password-based auth might be old but still works great.
for sure, even if is just one of the steps to log... I really like it yet
Just email magic links in that case :). Passwords are deprecated.
Absolutely, password are deprecated. That's why nobody uses them anymore and the very few websites that use them are compromised 10 times a day.
Just gonna send an email link to an email address based solely on the existence of that email, which the user is going to access with a ... password. There, the bucket was kicked down the road a bit more.
Points:
"That's why nobody uses them anymore and the very few websites that use them are compromised 10 times a day" - What is your source for these facts, or are they just opinion?
sarcasm
Ok. Funny then but not helpful.
That's what the second part of the post was for. Unless you're looking for validation.
That's because most companies are not security competent. Sure I would never hand my data over to Facebook, but Google has proven they don't know what do with it anyway. Realistically you must trust some repository for storing access credentials. Using federated login is much safer than using Lastpass, 1Password, etc... If you want a privacy first federated login, come talk to me in a couple of months, Authress will have that capability.
If you don't use a social login, the site you are using will most likely leak all your data. And sure for a blog you can argue nothing bad, but a site that I put my credit card in, I would never trust that site to handle my data correctly. It usually ends up like this: Hacked home cams used to livestream police raids in swatting attacks.
For credentials, sure. But social login doesn't come with simply credentials storage but with an agreement to allow monitoring online behaviour to the extent that a user needs to put in place a lot of serious safeguards to protect their data and prevent traces, doubly so if they have social media presence.
Without social media profile, some generic data can be leaked, but it's much easier to prevent it even with basic modern browser enhancements.
Password storages, I trust (so far) which is why I prefer the password storages + generated password rather than social login.
I would go password less for 2021, people are just dumb with passwords.
Unless you mean biometrics, I don't see how that goes. Social login means the password is handled by Facebook. But it's still a password just somewhere else, incidentally with a bigger footprint, a bigger target both for hacking and phishing. I have nothing against providing social login as an alternative, just not a replacement for user password (with 2fa, maybe).
If there's a breach on their side, you can't do much except remove that provider.
Totally agreed.
I did a fair bit of reading on CSRF. While we should always try and use
SameSite
attribute for cookies, it is not a fool-proof method for protecting against CSRF. CSRF token should still be used. TheSameSite=Strict
will only work for browsers that implement this feature. If a user uses a browser which does not support it, they can be vulnerable. Additionally there are ways to bypass this feature even for browsers supportingSameSite
attribute.Quoting from CSRF sameSite:
If you are using REST APIs to secure content and not sending it back as part of a SSR. Then those bypasses don't apply. Since it isn't secure to send content back as part of page navigation anyway. CSRF can entirely be replaced by
SameSite
.I would argue that many things you list are controversial.
First, not everybody is building secured services on cloud, and many developpers are building in enterprise private infrastructures.
For many of us:
i appreciate your suggestions but here is my reverse suggestion for webauthn caniuse.com/?search=webauthn check it out, very incompatible on many browsers