I am trying to implement user authentication process, and I have gone through enormous number of posts and totally agree that using HTTPS is probably best way to transfer username/password from client to server befor hashing.
Just out of curiosity, I want to know : how safe it is to send username/password from client to server using POST method along with enctype='application/x-www-form-urlencoded' as this also send form data in encoded form?
PS. I am using GWT for frontend and JAVA for backend.
Sending data by way of the body instead of url params is the way to go, but to ensure that is not sniffed out, you must use HTTPS. Otherwise it will be plaintext.
As to how safe? see here: https://security.stackexchange.com/questions/53596/how-safe-is-ssl
Related
First of all, I am sorry for my bad English.
I am writing an app with a backend, which I want to make safe. I am using HTTPS for the connection, but a lot of people say that this is not enough protection.
At the moment, my user credentials are sent to the server via JSON format as plain text, which isn't a good way, I guess. At the server, my password is hashed with a random salt and stored in the database.
If the login is successful, an authentication token is generated and sent to the client. The client is using it as a header.
Do I need to do more? I read something about digest access authentication. Should I implement this authentication method, or is there a better way to make my login safe? Or is this the right place to use this authentication method?
For an Angular 5 application, I am hitting a login web API with the credentials. I am sending the user credentials in request (POST) body. The credentials which I sent is clearly visible in browser form data. How can we hide the credentials while sending to API?
Form Data in Browser(image)
I think there's basically two ways to treat credentials in a secure way (and it's not angular dependant):
The whole connection is end-to-end encrypted, i.e. using https as transfer protocol, making use of SSL to encrypt the data. I think you would still see the value in your console, but no-one else should be able to detect.
You don't store / send the password itself, but an anonymized version of it. I.e., you would store the hash of a password in a database, and as of that, you would also hash the value entered in the password field and submit that one.
So, I would conclude it's less an issue in terms of your angular (frontend) design, but more of the overall (security) architecture of the application middleware.
This might seem like a strange question, but is it possible to detect and reject requests sent to my web server from outside my UI? For example if someone sent a post request to create a resource using the correct authorization token or session info from a tool such as Postman, could it be detected?
I want to prevent someone from using my application as some makeshift API.
Probably the best you can do is to just make sure (or come close to that) it's a human being by using a captcha service such as reCaptcha
I am using Backbone.js and it communicates with a stateless rest API. Some calls require authentication, through HTTP basic.
What I don't understand is, somehow I have to authenticate each request, how could I do this securely? My first thought was to have a cookie, store the username and password but this would be vulnerable?
Can this be done securely?
There are two themes to this question. One is about security and one seems to be about REST rules.
The way to do authentication securely, is to pass that data through an SSL connection. It's the only way to securely transfer data over the wire.
With regards to sending authentication using basic auth over each request (REST), not many people I know do this in reality.
There's always a big long discussion on how much security is enough security and it really depends on your application and what the purpose is. I know this isn't the definitive answer you might be looking for but I'll just give you my take and how I'm going about dealing with the issues you mention.
With RESTful apps, the story is one should authenticate each request but in real practice I find this is more a "guide" than a hard rule. Rare is the fully RESTful application that follows all the rules. I use an encrypted cookie to store the user session data with a standard authentication flow that happens once and expires in a week. Data transfers happen through SSL to prevent MITM attacks and a modified Backbone sync sends a CSRF token along with each POST, PUT, DELETE to prevent cross site request forgeries. Probably "good enough" for the social app that I am working on. Maybe not if you're doing bank wire transfers and stuff. Hope this sort of gives you a point of reference in judging what you might want to do.
Is https://github.com/fiznool/backbone.basicauth something you'd find useful?
This plugin enables access to remote resources which are protected by HTTP Basic Authentication through your Backbone Models and Collections.
How does it work?
A resource protected with HTTP Basic Authentication requires the following HTTP header to be set on every request:
Authorization: Basic
The access token is formed by taking the username and password, concatenating together with a : separator and encoding into Base64.
This plugin handles the Base64 encoding and automatically sets the Authorization header on every request which uses Backbone.sync.
We are implementing a single sign on mechanism in an enterprise environment, where the token is shared between applications using HTTP header. Now, in order to do the integration test, I need to write an application to simulate this.
Is there any way in ASP.NET where I can redirect to another web-page and pass a custom HTTP header in the process?
Thanks
You need to create a page on Site B that Site A redirects the user too that sets a cookie with the desired value.
for instance.
http://siteb.com/authenticate.aspx?authtoken=15128901428901428904jasklads&returnUrl=http://siteb.com/index.aspx
authenticate.aspx would set a cookie and then every request would receive authtoken.
The server could send the HTTP header to the client on a redirect, but the client would not send it back to the other remote server.
The ideal solution in this case would be to use a Cookie, or a QueryString variable. Cookies may suffer from cross-domain issues and become complicated if host names are different enough.
In any of these approaches, one must be careful not to create a security hole by trusting this information as it is user input coming back from the client (or some black hat).