I have a REST API made with Django Rest Framework. This API has an endpoint for creating new users. When creating a new user, I obviously need to provide some sort of password. What I am concerned about is how to communicate that password data from the client to the create user endpoint in the API via JSON. Do I send the password in plain text? Should I encrypt client side and then send? SSL/HTTPS? TL;DR: How do I safely do something like this: POST to myapi.com/create-user with_data {'password':'my password'}
Sending in plain text over HTTPS would be just as secure as any other web account creation you've done from the browser.
Although you don't actually need to require the user provide a password- you could have them provide an email and you dynamically create a temporary password and email it to them.
Related
I have setup an web-based API to allow a remote app to GET/POST data. Every API call is authenticated with a User ID and Password that is encrypted with a secret key known only to the remote app and the website. This authentication not only ensures that the user can access the API, but also allows me to implement security features based on the user's profile (i.e. User A can see items A & B, but not item C).
I would like my server-side website pages to be able to call the same API methods remotely via AJAX calls, but, something just doesn't seem right about storing encrypted passwords in the code, and, my website implements a "Login As" feature, which will not allow me to set the encrypted password, since the passwords are not stored in plain text.
What is a good way to implement API security for both remote and "local" calls that doesn't require encrypting the user's password?
You should not be storing usernames and passwords in server side code. Sooner or later someone will lay eyes on your code and your data will be vulnerable.
But you should also not be storing secrets (key) in client side code. You should not assume your client can be trusted to keep that secret.
Giving user A access to item A and B, but not C is called authorization and depends on you knowing who calls your API (authentication).
You should probably look into a authentication protocol like OpenID Connect and an authorization protocol like OAuth 2.0.
Also see my answer to this question.
I am developing hybrid mobile Application using phonegap(jquery mobile framework) and jersey rest java webservice.
How to do login and logout using mysql and rest webservice and maintain session of perticular user on every page like traditional webapplication(get username on every page).
i am totally stuck.can anyone provide sample example or any solution.
you can do in below way.
create session table contains column [id, token, userid, loggedintime]
on login call a rest like /rest/user/login?username=uname&password=pwd
which return a token to user. maintain that token at client side. you may use cookie or sessionstorage whichever supported by mobile device.
now create one Filter with path /* so each request pass through it, and in filter check that the users token is valid or not, if not than redirect to login. you can explicitly pass that token to server in queryparam or pathparam.
on logout delete entry from session table, and redirect user to login page again.
there are many way to do this thing but this is a simpler way.
It's simple, you store the username and password in your client and send them with every request. (On the server side you can have an (username, password) -> (identity, permissions) in-memory cache which can make things faster.) You need a secure connection: HTTPS. Without that you won't do REST auth.
Login is simple you show a prompt to the user, in which she can give the username and password, so you can store them in the memory of the client. By logout you can simply close the client (by browsers navigate away), or remove the username and password from the memory of it. (It is not secure to permanently store the username and password without proper encryption on the client side.)
I am now developing web service, but i want person who are authenticated have the right to use the web service. Now I have two methods, one is use username and password in every service, the other is first use username and password to login and get token, then visit other services just by token. Now I want to know which is better? Suppose I use https, it is secure to pass username and password. But my mentor told usually we use token. So can any compare these two methods detaily from security,performance or any other aspects?Thanks very much!
If you are using SOAP, you can implement soap header authentication.
Or Basic in http header
Implement the system in the following way.
The User should send an Encrypted Format password and UserID in the first request.
The Password authentication logic can be unique to you but make sure that the password is not exposed in the SOAP message as plain text.
Next at your service side, implement a service handler which maintains a list of authenticated IP addresses.
Whenever a new IP address tries to contact your service, you validate its credentials and then if authenticated, you add the IP to your safe IP List.
In case the Authentication fails you reject the request.
In case of Multiple services, implement a common Service Handler for the same. and keep the IP list as a static variable.
Other than this You can look into Web Service Security:
Oracle Doc
Wiki Page
and so on...
We have a central RESTful webservices application that exposes data to many different clients (parsers, web applications, touch applications, etc). The clients have different means for authenticating users, some LDAP, others not. Regardless, the RESTful application leaves the authentication of the end-user to the client, and simply authenticates the client making the request. The client will have a username and password in LDAP, along with a list of acceptable IP addresses from which the client can access the RESTful application.
Here is the tricky part: the RESTful application must audit every request with the end-user's username. Furthermore, in certain circumstances (depending on the client) the RESTful application will need the end-user's username and password for accessing a third-party application. So, every request from the client will have authentication credentials for the client itself and the end-user accessing the client.
Here comes the question. Would it be best to put the client's credentials in Basic Auth, and pass the end-user's credentials via an encrypted SALT request parameter? Or, should the client put both sets of credentials in the Basic Auth (i.e. system~username:systempwd~userpwd) and parse them out into two sets of tokens that are then authenticated. Or, another solution that is better than either of these two?
This sounds pretty much like OAuth2's "Resource Owner Password Credentials Grant" - see https://www.rfc-editor.org/rfc/rfc6749#section-4.3. You pass application/client credentials in the Authorization header and client information in the body encoded using x-www-url-encoded. Do that once at the beginning of the session and then depend on a bearer token in the authorization header after that. All of that is described in the RFC. Remember to use SSL/TLS to encrypt the credentials.
I'm writing a web app in Django that is interfacing with the Read it Later List API (http://readitlaterlist.com/api/docs/). However, all of the API calls require sending the username and password with each request. In order to do this, it seems that I need to store the user's password in plain text in my database. Am I missing something or is that the only approach possible in this case? Is there some way to store an encrypted password in my database, but yet be able to send a decrypted version of it when making the API call? If not, then are there any best practices that I should be following to safe-guard the user's password?
I'm pretty sure that this can't be the only service requiring sending password in plain-text. I'm interested in knowing how developers deal with these sort of services in general. I'm new to web development, so any help or pointers is appreciated.
do your users have to log into your website to use it? if you also are making use of a password authentication scheme, you could piggy back on top of that. Use the login password for your site as a cipherkey in a symmetric key cipher to encrypt the api password. then you need only store a hash of the users password (to your own site) and an encrypted password for the remote api.
Never save password in plain text. You can encrypt and decrypt the password but the problem is that the key you use to do the encryption and decryption will generally be accessible to anyone who has gained access to your server so it's not secure.
An alternative is to ask them to enter their password and save it in an encrypted cookie, or session variable or something else that will expire when they have logged out of your app. This has the drawback of them having to enter their password every time they user your app.