Working on a funny/new api/service (will be a public one) and I'm only now realizing how important good security is but especially:

The amount of time that goes into securing an api/application is too goddamn high, I'm spending about 90 percent of my time on writing security checks 😅

Very much fun but the damn.

What kind of checks are we talking about? I'd like to learn those things :)

@gitpush

- authentication (of course) - is a requester logged in at all?
- authorization: may a requester access a location and request certain data? (or post new data etc)
- request data validation: we expect stuff (maybe a string of x characters long without unicode), are we getting that or something else?
- rate limiting: how often/fast is someone trying to access a resource? If it exceeds a certain limit, they're banned for an x amount of time.
- someone tries to login: is it a single try? Is the given data correct? Is it a brute force attempt? Etc.

Is that a little more cleae? :)

Auth0.com thank me later

Sounds like you want to put some authentication middleware in there

@windlessuser Would this mean user passwords would be stored on a server which is not under my control?

Apart from that, what's wrong with using my own library for this?

Last but not least, would this allow people to login through google/facebook etc? Because that's an 'over my dead body' scenario :)

@gruff I've written my own library over the years (testing and improving it along the way, what would be wrong with that?

@linuxxx nothing mate I have my own library that sits in the request pipeline and authenticates everything using client certificates. Nice and secure, it’s what I meant in .net core it’s called middleware for stuff that affects request/responses as they go in an out. I have another library that implements as2 as well

@gruff Good haha, people keep telling me that I really need to use other services/libraries but as far as I've tested, my own library is quite secure (I'm one of those fuckers who pentests the living shit out of his own applications/libraries).

I do the authentication part a little different but it works nonetheless.

@linuxxx haha and you know your library inside out, it does what it is supposed to instead of a million things it doesn’t need to. All in all ends up less complex and easier to maintain and you don’t have to wait on other people for a trivial bug. I get ya ;)

@linuxxx great I have missing stuff in the list I'll try implementing them then I'll come back for part two 😀

@gruff I use DotNet core, can you suggest best practices for security.

I do use policies (Authorization attribute)
I also use JWT
I also add validation attributes for dto in my API

But that's pretty much it only.

What else do you recommend?

The first rule of rolling your own auth: don’t roll your own auth. There are so many great open source solutions to choose from... permission checks should go on top of a solid auth.

@620hun I'd agree if you were talking about crypto because that's difficult as hell.

But we're talking about authentication here and you're apparently assuming that I don't know what I'm talking about?

As long as you test your custom solution to death and follow best practices, I'd say that's alright.

@gitpush heya, other things that can be good ideas are
* same-origin cors policy
* LocalRedirect over Redirect
* use hsts
* ensure query parameters cant be modified
* store tokens in browser local storage and not cookies
* pkbdf2 for password hashing and other strong cryptography
* encode and never trust user input
* read up on OWASP best practices and possibly configure in the web server
* put a proxy like Nginx or caddy in front of kestrel

You could easily create middleware that
* performs rate limiting
* rejects ips with to many failed logins

@620hun rolling your own auth really isn’t that hard and the first rule is really never store passwords when rolling your own auth

@gruff Well, that wouldn't be possible as I'd have to store them somewhere 😬 (bcrypt hashed though!)

@linuxxx yeah that’s what i was getting at, hashes are fine and if you can hash client side with a salt then the users password never has to leave there computer and means people can’t use rainbow tables

@gruff Right now I've got:

- cors: only the server, you don't need any other resources.
- hsts: the first thing I'll setup when I put this fucker live.
- explain please? :)
- that's up to the users, I'm solely devving an api.
- Bcrypt with a high enough difficulty level.
- define encode? And don't worry about the trusting part, I've got a library which checks everything and gives a fuck you when the requirements aren't met.
- Yup. I regularly read those :)
- what's kestrel?

I've written a library for rate limiting in an endpoint basis which I've tested and works well. (can easily configure it through a config file)

An account is entirely locked when brute forced, gotta look into a better solution as you could simply lock any account this way and as long as you keep changing ip's, you could technically brute force to infinity.

@gruff I'm solely developing an api which anyone can use in any way, I'm not writing a front end or whatsoever :)

@linuxxx sorry some of that was directed to @gitpush kestrel is part of .net core

The not modifying query parameters in based on this owasp guidance https://owasp.org/index.php/...

Regarding encoding it’s to mitigate XSS see here https://owasp.org/index.php/..._Prevention_Cheat_Sheet

I think once an account is locked it should be reset only, possibly after some random delay maybe increasing exponentially each time the account is locked

@gruff That’s an axiom, not a rule.

@linuxxx Knowing something doesn’t mean that you aren’t prone to human error. I would never trust an auth written by a single person, even if they’re the biggest expert in the universe. Open source auth is solid because hundreds of eyes have looked over it.

Also, why reinvent the wheel when there’re people travelling in your vehicle?

@620hun oauth is not an authentication protocol and only authorises access to a resource on behalf of the owner so when using client side oauth a malicious site can reuse your access token to obtain authorisations as it assumes you are the resource owner because you haven’t been authenticated. The server side flow doesn’t have this issue and you can find out more here https://oauth.net/articles/...

@gruff
* same-origin cors policy: Is it required for a REST service?
* LocalRedirect over Redirect: Can you please give more info?
* use hsts: app.UseHsts(); any thing else?
* ensure query parameters cant be modified: How to do that?
* store tokens in browser local storage and not cookies: Done
* pkbdf2 for password hashing and other strong cryptography: I use UserManager to create users which by default hashes their password
* encode and never trust user input: even for a REST service? And If I'm not mistaken EF Core does ensure safety when querying
* read up on OWASP best practices and possibly configure in the web server: Thanks will do
* put a proxy like Nginx or caddy in front of kestrel: Already done

You could easily create middleware that
* performs rate limiting : I'm planning on doing that on nginx level, do you recommend also on service level?
* rejects ips with to many failed logins: Any recommended middle ware for that?

@620hun I never said that I wasn't prone to errors (or my work).

I personally have a hard time trusting someone/an application which does authentication through a third party, solely because then they give the data to another party and I've got no clue how that third party handles the data.

As for third party libraries, sure, could use those but I'd like to know how every line of code works in my projects and I don't have time to go through everything.

Why reinvent the wheel? Because that's an awesome way of learning!

Also, third parties often allow logging in through services like Facebook and Google and that's a big fat nope :)

@linuxxx that’s a very grim outlook on life. At some point you’re going to have to trust someone or an org with very sensitive data - like your bank. If you can trust your bank, then believe it or not, you can trust other folks like Facebook. Facebook more than anyone else has the greatest incentive to make sure your data stays safe. It’s is their lifeblood. The company will die if people cannot trust them. It really hurt them when things got really political after the US election. To that end they’ve beefed everything way up. You can’t even touch the groups api to even test without handing over a few legal documents. They also gave hundreds of paid - not voluntary like with oss - highly skilled cybersecurity folks steadily improving their platform against bad actors. What you are building now is nowhere close to that. Furthermore, in the spirit of good Engineering doctrine, you should only be writing code when its absolutely necessary. If someone has a solution for your problem, just drop it in and focus on your business logic.

@windlessuser Facebook trusted haha don’t make me laugh that is why uk mps want to grill Zuckerberg or their recent trial in the US. Besides we are talking about authentication and not authorisation which is provided by oauth the “If you need to be sure who a user is” it has to be built on top. Ever wondered why banks don’t use oauth? Every library is not necessarily a silver bullet and plugging in little black boxes of magic you have no idea what vulnerabilities you could be adding to your code

@windlessuser I'm sorry but the amount of shit that Facebook has pulled (and still pulling) is astonishing and next to that, does nobody remember the snowden leaks? The things he revealed is one of the reasons why I pretty much lost all trust in this company and don't want to have anything at all to do with them.

What I'm building is nowhere close to anything related to facebook? Thank god.

@gitpush * same-origin cors policy: No but a good idea if you know your clients and it is not open to the entire world

* LocalRedirect over Redirect: https://docs.microsoft.com/en-us/...

* use hsts: any thing else? Nope

* ensure query parameters cant be modified: You can sign them and verify them but is probably more relevant to a website. it is covered under OWASP

* encode and never trust user input: even for a REST service?

Most encoding should be done by .net core really but you should still perform sanity checks on user input add constraints to route parameters ect.

* performs rate limiting :

It would give you greater flexibility to make the limits dynamic if you needed it but at nginx is just as good

* rejects ips with to many failed logins: Any recommended middle ware for that?

Not that I can think of but I could probably create a gist showing how it is done.

@gruff What's the point of signing user input client side? The client can modify/influence a lot then. (jwt's are signed server side by the way)

@linuxxx I think the justification is so someone can’t change something like an order number and view one that isn’t there’s.

@gruff Well, I don't think I'll be able to do that with this project 😬

@gruff Thanks man much appreciated :)