I am currently using expressjs with node.js as my rest server for my website. Currently users can login on to my website and start some actions through ui. They want to automate this stuff and I am looking for ways to achieve that. Some of the ways I can think is:
Create a new request which can take login creds as part of reuest parameters and execute the desired the actions. My users would have to save their password as pain text for automations which doesn't seem OK to me.
login using ssh similar to how bitbucket/github takes our public ssh key and lets up do codepush with out writing the password everytime. How do I implement this kind of setup. My users want to execute everytime they deploy in test machine. So they will put my script in server restart script.
If I have to adda new ssh based authentication, are there any npm modules which can help me with implementation?
I am using mean.io boiler plate code and login is currently is based on default login protocol of theirs, where in I save the hashed password and compare that during login.
I think dealing with public-private key pairs is probably more trouble than it is worth. Perhaps you can go with a third option:
Allow users to generate API keys from your web interface. The keys will be "long" randomly generated strings (GitHub uses a 40 character long hexadecimal string for its keys). They can be used for making API requests in place of a password in a username-password pair. For additional security, allow users to limit a key's usage to a certain IP (range).
Also, make sure your application is being served over HTTPS if it is not already.
Example flow:
User tim generates a random API key on your site (aisjd8auasdjsd80j43j).
tim wants to make a request to your API. In the request, tim sets an authorization header:
GET /api/v1/list-all HTTP/1.1
Host: example.com
X-API-Auth: tim:aisjd8auasdjsd80j43j
...
Your API verifies the X-API-Auth header, checking if tim owns the given API key.
Your API returns the requested information on sucess.
Also, it may be worth using using HTTP basic authentication instead of the custom X-API-Auth header, as I did in the above example. I believe it would be slightly easier in command line tools like curl to make HTTP basic authentication requests, rather than setting a custom header.
Related
GOAL : I am creating a mobile app that needs to hit an AWS server and I want to make sure only my app can hit the server.
CONSTRAINTS : I never want the user to have to login to the app. If my research is correct, I believe this eliminates the use of tokens (such as JWT). I think this eliminates the use of tokens because I would have no way of refreshing the token in the user's app.
PROPOSED SOLUTION : Encrypt a key (a string) in the app (let's say the string is "allow") using bcrypt in the mobile app. Use a HTTPS POST request to hit my server with the encrypted key "allow" embedded in the body. In my server logic I would read the contents of the HTTPS POST body, decrypt the string, and allow further logic to be done in the server if the decrypted string = "allow".
QUESTION Does my proposed solution make sense? If not, could I get guidance to what I should do?
I believe this is possible because I read here that the the body of a HTTPS POST is encrypted. Therefore I think placing a bcrypt encrypted key in the body should be an extra layer of security to my server.
Is this for an API? Instead of adding a key value to the POST body, add it to a header value. It will be encrypted over https. If ONLY your mobile app will be using it then you can probably even use the "User-Agent" header.
Whatever header you choose, you would then evaluate it on the server just like you mentioned.
However, do note that someone could figure out how it works. It will only prevent most people from trying to figure it out.
I'm not convinced about the bcrypt key. If you are using https it will be encrypted anyway.
I've started a project to scrape my work's employee website to scrape the user's (in this case, mine) schedule and munge the data onto a google calendar. I've decided to go with Perl with LWP.
The problem is this, when trying to set up SSL negotiations I don't know what do put for the 'realm'.
For example: (http://www.sciencemedianetwork.org/wiki/Form_submission_with_LWP,_https,_and_authentication)
# ...
my $ua = new LWP::UserAgent;
$ua->protocols_allowed( [ 'http','https'] );
$ua->credentials('some.server:443',**'realm'**,'username','password');
# ...
I've looked at everything my browser can tell me and at a wireshark packet capture trying to find anything but to no avail. I assume that second argument to credentials() isn't optional.
Where do I find the 'realm' I'm supposed to use?
The credentials are for the HTTP authentication protocol (RFC 2617) (Wikipedia).
The server can challenge the client to authenticate itself. This response contains a string called “realm” which tells the client for what authentication is required. This allows the same server under the same domain to request authentication for different things, e.g. in a content management system where there might be an “user password” and an “administrator password”, which would be two different realms.
In a browser, this realm would be displayed alongside the username and password box which allows the user to type in the correct password.
To discover the realm, navigate to a page which requires authentication and look for the WWW-Authenticate header.
Note that HTTP authentication has become quite uncommon, with session cookies being used more often. To deal with such an authentication scheme, make sure that your LWP::UserAgent has an attached cookie storage, and then navigate through the login form before visiting your actual target page. Using WWW::Mechanize tends to make this a lot easier.
I'm in the process of using the facebook javascript sdk to provide user login functionality for a website.
What I'd like to do is simply take the logged in user's unique facebook id and then put/fetch data to/from a mysql database using the id to determine what data is available to said user.
However I don't really feel like this is very secure. Whilst I'm not storing anything sensitive like credit-card details etc, I'd obviously prefer it to be as secure as practically possible.
My fear is that with javascript being what is it, someone could fake the facebook id and just pull whatever they wanted.
I'm aware that the php sdk would provide a solid solution to this problem, but i like the javascript one mainly because it's easy to use and I have the basis of it set up (I admit it, I'm lazy).
So, my questions are:
Would this set up be as insecure as I feel it might be?
Is there anything I can do to improve the security of such a system, other than switching to the php sdk?
Thanks!
Facebook Ids are pretty hard to make up (at most a user will only know their own). Depending on what you store in the database (which will not be anything that the user cannot get on their own, unless you ask for extended permissions)
If you are worried about a user trying to get information from the database, add an access token or signed request to each row and us that and facebook id to get data. That will greatly increase security.
EDIT
There are few occasions where you get a signed request from a user:
* A signed_request is passed to Apps on Facebook.com when they are loaded into the Facebook environment
* A signed_request is passed to any app that has registered an Deauthorized Callback in the Developer App whenever a given user removes the app using the App Dashboard
* A signed_request is passed to apps that use the Registration Plugin whenever a user successfully registers with their app
Signed requests will contain a user id only if the use has accepted permissions though, and are not passed again if the user enters the application, and accepts permissions (meaning that the signed request would not contain the ID). Because of this saving an access token may be a better idea. Here is more on the signed request
Also the signed request is in the url (param = "signed_request"). I always parse it through c# but I am sure you can at least get one through javascript
It's pretty easy to spoof the origin using curl. I'd imagine Facebook has another mecanism in place to make this possible. If you inspect their code, it appears that they generate an iframe and pass requests through. If I had to guess, they have setup the requests to only be made from the Facebook domain, and ensure that the iframe can only be embedded in a page that has a white listed domain.
Consider the URL:
https://foo:password#example.com
Does the username/password portion in the above example qualify as a "URL parameter", as defined in this question?
When you put the username and password in front of the host, this data is not sent that way to the server. It is instead transformed to a request header depending on the authentication schema used. Most of the time this is going to be Basic Auth which I describe below. A similar (but significantly less often used) authentication scheme is Digest Auth which nowadays provides comparable security features.
With Basic Auth, the HTTP request from the question will look something like this:
GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk
The hash like string you see there is created by the browser like this: base64_encode(username + ":" + password).
To outsiders of the HTTPS transfer, this information is hidden (as everything else on the HTTP level). You should take care of logging on the client and all intermediate servers though. The username will normally be shown in server logs, but the password won't. This is not guaranteed though. When you call that URL on the client with e.g. curl, the username and password will be clearly visible on the process list and might turn up in the bash history file.
When you send passwords in a GET request as e.g. http://example.com/login.php?username=me&password=secure the username and password will always turn up in server logs of your webserver, application server, caches, ... unless you specifically configure your servers to not log it. This only applies to servers being able to read the unencrypted http data, like your application server or any middleboxes such as loadbalancers, CDNs, proxies, etc. though.
Basic auth is standardized and implemented by browsers by showing this little username/password popup you might have seen already. When you put the username/password into an HTML form sent via GET or POST, you have to implement all the login/logout logic yourself (which might be an advantage and allows you to more control over the login/logout flow for the added "cost" of having to implement this securely again). But you should never transfer usernames and passwords by GET parameters. If you have to, use POST instead. The prevents the logging of this data by default.
When implementing an authentication mechanism with a user/password entry form and a subsequent cookie-based session as it is commonly used today, you have to make sure that the password is either transported with POST requests or one of the standardized authentication schemes above only.
Concluding I could say, that transfering data that way over HTTPS is likely safe, as long as you take care that the password does not turn up in unexpected places. But that advice applies to every transfer of any password in any way.
I am using a new service to pull xml data from a server.
The service provides two methods of logging in, one via a url query:
http://<server>/login.asp?username=<User Name>&password=<Password>
and the server returns a cookie valid for 7 days. This means instead of logging in for every query (and making my script less efficient), I only need to login once a week.
I have just realised that I can't do this since the script is not run from a web browser but from a cron script on the server. Is there a way to store cookies on my server, or do I have to go for the second method:
Token
The token is the username, passwork
and usergroup encrypted using the DES
algorithm with a key and a timestamp.
The token can be generated by any
application using the DES algorithm
with the appropriate key or the secure
call below can be used: the token is
contained in the body of the returned
page and is valid for one hour
I know nothing of this method. Can you point me in the right direction? Thanks.
Ed
Is there a way to store cookies on my
server?
Yes. Here's how:
curl -c cookies.txt http://<server>/login.asp?username=<User Name>&password=<Password>
That will write them in netscape format to cookies.txt.
Noah
If you have access to the actual login script, you could instead always include some sort of unique id only you know..
Even better would be to use some HMAC-(MD5/SHA1) scheme like OpenAuth does. If you're lazy, just include something like '?key=somethingonlyyouknow' to every url you access, bypassing username + password. User + password scheme 'should' only really be used by humans, not by machines.
If all that fails, change your script to store the cookie. If you use 'curl' you can specify cookies should be stored, and in which file that should be.