hey I'm planning to use this authentication method on my app.
1) browser sends creds
2) server sends an AES encrypted session, which has the username
3) browser stores it in the local storage
4) the session has a creation date so it can be expired after some time
5) the encrypted session sent with each request with the app not the browser
How I see this: (might be wrong)
- CSRF can't use it
- with JWT, CSRF sends the refresh token each time and get the server to respond, while this won't get a response since no session is sent with the request
- also it's stateless, so scales horizontally easily
Is this secure?
How is this compared to JWT?
40 Replies
Why are you reimplementing your own version of JWTs?
Auth is one of the few things you really shouldn't fuck around with much if you don't have really good reason
And using local storage for auth is almost always a code smell
I thought JWT is kinda bloated-ish. I want it to be more simple.
yh ik this is a very sensitive spot to miss around with.
oh, I though when I encrypt it, it't not gonna be an issue.
also jsut thought of adding the date it was crated so it can be expired.
and also it's fun to do tbh
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
but it's not cookie-based
I use Local storage
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
yes, I want to see if it's really secure or better than JWT
I don't study web security but I love implement my version of auth, kinda...
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
how is this compared to JWT?
in terms of security
or other aspects that I might not know
@venego what I'd recommend if you really want to learn the internals of Authentication is to just use next-auth and run your debugger to see what runs under the hood
I've written countless versions of our own custom authentication but it has never been worth the effort.
thank you I'll try that
this made me feel that I'm wasting my time LOL. though It's what I needed to hear I guess
Wouldn't say wasted, every line written is an extra line of experience 😉
please don't
why?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
well,
1) it's encrypted
2) if I have XSS, that's the last thing I would worry about
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
oh,
last thing = reading local storage
you don't get it, I'm signing the session
it doesn't have to be sensitive, it's enough to be encrypted by my private/public(doesn't matter none of them is shared) key
an attacker can only send the session as is, but XSS has more power than that he'll be controlling all what you see in your page, so It won't matter.
could even lead you to download some malware
or log your keystrokes
or screenshot everything
or submit forms
so the session is useless at that point. form an XSS-attacker's point of view
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
ok ok ,
1) I use time to terminate the session, I don't need state for that
2) state won't matter, if it's long enough
3) I just mentioned that the attacker doesn't need the session to do all of that
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
why you need the session while you could just generate the click events or call functions that already do that?
true, but when a legit site tells you, "download our desktop app" I'm sure many people will fall for it
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
true, and the session token is being used by the front-end logic to send those requests and include the session with them. then the attacker just have to use that logic
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
consider the JS injected by the attacker as your front-end new functionality
how? it doesn't matter where the session is
if he could execute your function. your function would send the request, and the browser will include the cookie. simple
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
that's not how XSS works
go read about it
basically if you have XSS on your site, you're done, the user i mean
but it's easy to protect against tho
just filter the user inputs
I mean.... you could do that, but it's the longest route
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
just answered you before you ask 🙂
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
can also be done on the victim's browser
own device is not the best idea tho, from an attacker's pov
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
anyhow my method is not unsecure
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
sure, yh depends on the way the site is set up
not at all, AES can be brute forced, but compared to the currently available methods I think this one is solid
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
not only your opinion but it's a fact
just a false positive
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
yes totally, I think it's the browser's job to analyse the extension's behaviour. though that might make your browser really slow.
this was a nice conversation thank you
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View