#login credentials in req Headers or request body?

1 messages · Page 1 of 1 (latest)

real bloom
#

Hello! I'd like to know what is best way to pass user credentials from client to server to authenticate user? in custom headers like

"username": "[email protected]"

or in request body and why ?

errant shellBOT
#

<@&1004656351647117403> please have a look, thanks.

errant shellBOT
#

While you are waiting for getting help, here are some tips to improve your experience:

Code is much easier to read if posted with syntax highlighting and proper formatting.

If your code is long, or you have multiple files to share, consider posting it on sites like https://pastebin.com/ and share the link instead, that is easier to browse for helpers.

If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.

Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.

restive tiger
#

Use the authentication header

leaden tiger
wintry flicker
#

Then you need to somehow split the auth and the payload, and probably in two separate places

leaden tiger
wintry flicker
#

Yes

jolly karma
#

Using the Authorization header (or headers in general) is definitely the way to go here. Usually, if using the Authorization header, you'd encode your authentication data with Base64 and write "Basic: yourB64String" to the header.

There are a few reasons why this is preferable over the body. One of them was already mentioned by Seraphim, but also consider GET requests which do not have a body. To pass authentication information in a GET request, you have no choice but to use the headers.

restive tiger
leaden tiger
#

I suggest to send custom headers : username and password in header

#

Do the encoding in server and send it back to client

restive tiger
#

But you'll lose out on the secure storage that authentication header gives you

restive tiger
leaden tiger
#

In authorization header

#

I see this insecure

#

The client side may be controlled by anybody

restive tiger
#

How is using a custom header anymore secure?

#

How is it insecure? You won't use SSL?

leaden tiger
#

I do but even with ssl the client side (frontend app) can be vulnerable

restive tiger
#

How can it be vulnerable?

leaden tiger
#

The source code can be visualized

restive tiger
#

Yes but the source code doesnt contain anything sensitive

leaden tiger
#

If we speak about basic auth, then yes , the code must have bas64 encoding mecanism to user credentials

#

The attacker can see how the authorization is done

restive tiger
#

??

#

Your Microsoft, discord, everything is done the same way

#

All those use the same mechanism for auth

leaden tiger
#

I dnt think so

restive tiger
#

???

leaden tiger
#

Basic auth has become the weakest mecanism

restive tiger
#

They are using basic Auth for everything

#

Except for exchange online

#

You're misunderstanding basic Auth

#

You can send the username/password in plaintext, it's not the header that is the problem

leaden tiger
#

Sure. it must be customized not the ordinary basic auth

restive tiger
#

SSL is what encrypts the data

#

Not the header itself

leaden tiger
#

Yeah I know but there are other considerations

#

I suggest you to read the rfc description

restive tiger
#

But I don't understand how using a custom header fixes it

leaden tiger
#

By using custom header you secure the encoding

restive tiger
#

You're not though

leaden tiger
#

And you dnt show it to attacker

restive tiger
#

The attacker will see all your headers

#

Unless you use SSL

leaden tiger
#

I agree for ssl

restive tiger
#

That's all you need

leaden tiger
#

I not talk about the flow between server and client!

leaden tiger
restive tiger
#

Then the end users has a bigger problem with the security of their device

leaden tiger
#

Yeah but thts possible

restive tiger
#

Yes but it's not your problem

leaden tiger
#

I know but I can minimze the risks

#

So why not?

restive tiger
#

If an attacker has compromised a user's device, you can also assume the user is already authenticated and will make malicious changes on the users profile

#

Like they're not trying to steal the password because they already have access to the service

#

What if their device has a keylogger? You can't do anything, not your problem

#

What if their screen is being recorded? You can't do anything, their password has been captured

#

Your encryption should only be concerned about the data leaving the users device because that can be attacked by anybody over a network (doesn't even have to be the users network, the packet could get hacked on route at one of the hop destinations)

#

SSL will fix all of that

leaden tiger
#

Dude I said I want to minimize risks

#

I know I cannot avoid risks at all

restive tiger
#

The point I'm making is that, using a custom header won't change anything

#

The value of a header can contain anything, you don't have to put "Basic base64" you can just do "mycoolencryption"

#

But devices by default store the authentication header in secure storage

#

You won't get that from a normal header

cyan oxide
# 
   passwords, it SHOULD NOT be used (without enhancements such as HTTPS
   [RFC2818]) to protect sensitive or valuable information.
errant shellBOT
cyan oxide
#

Doesn't it literally say do not use this unless you have HTTPS

#

which you should have regardless

real bloom
#

Hello guys! thank you for your participations

#

I've came to a decision, Oauth is better, recommended and very reliable

#

basic auth is just to learn or do internal security

#

As for credentials, its better for me to pass them in headers as they can be read easily in Spring filters unlike post body in json or else

#

I suggest to read the discussion in this thread

restive tiger
#

@real bloom you've misunderstood

#

You still need to do basic Auth (or similar) via the authentication header

#

Then you'll get your oAuth token

#

Which is sent in the authentication header as a bearer token

#

I'm saying authentication but the actual key is Authorization

#

I'm getting you confused to that scrum master guy now tho 😂

restive tiger
#

I just noticed that discord uses the request body to send credentials!

#

Request URL: https://discord.com/api/v9/auth/login

#

Plaintext in the JSON, not even base64 encoded, protected by nothing but SSL

real bloom
#

that way its authentication process is hybrid or customized

restive tiger
#

Yes the RFC is talking about when you're being phished

#

But yes the articles are all correct but you still need to at least once in the process send the username/password to the server to generate a JWT

real bloom
#

ofc !

restive tiger
#

The point is to not send the credentials repeatingly

#

But your OP question was asking how to do that

#

I was already under the assumption it was to do with the initial login 😔

real bloom
#

my question is not about mecanisms

#

its: what is more appreciated way to pass credentials

#

now as I'm using spring security, I'm in charge to build custom filters to replace basicAuthFilter for custom token, otp etc..

restive tiger
#

I'm still gonna say the header because the auth header in web browsers is stored in a secure storage

#

So before the request is made, a hacker cannot just try extract the password

#

Since it's already stored safely

real bloom
#

thats great and as it for native app

#

I guess it will more secured

restive tiger
#

That you won't need to worry about

#

You'll most likely be sending the password straight to the server once they press login

#

But before any communication happens, SSL will encrypt the network

#

So when the app does send the request, it will first encrypt the entire data before transmitting it over the network

#

So if a guy is standing next to your router and waiting for the data to be sent, he'll just see encrypted data that he cannot decipher without the servers private key

#

And these keys are generated randomly for each session

#

Using something like Diffie Hellman