I have two questions regarding security issues.
Intro: I'm developing a command line client that communicates with server (ready product, don't have an impact on code of the server) with Curl. Server requires authentication: username and password (plain text). All requests are made with HTTPS.
I believe using HTTP cookie is a good solution: client will authenticate only once and for another request a cookie can be used.
Firstly: Authentication implementation. Is it safe to store user password in regular python variable? I mean can it be read by a third side during script runtime? (there can be many users on same machine, on the same OS account, every single one has a username and a password [for client - server authorisation] that should remain secret)
Secondly: Would you have some hints about cookie storing? Encrypted file or something like that?
I am using Python 2.6.
Your assumption is correct. As long as the users do not have access to one another’s home directories, there is no need in further hiding the cookie. Your design is secure. Also, since you are developing a CL tool, you could simply use a netrc-like configuration file (it could be .netrc itself) containing the authentication information and forget about cookie management.
EDIT many users have access to one account:
I would consider changing that. However, playing within your constraints, I would suggest you create a log-in and log-out mechanism that generates and returns an authentication token valid for one session only.
appname login
The CLI would prompt from a username and a password. If the latter are valid, the server replies with an alphanumeric sequence valid for one session. The client would save it in a temporary file and use it for subsequent uses.
appname use
And finally,
appname logout
which would invalidate the token and remove the file.
Related
I'm going to use FastAPI Users for my application. I saw that it generates JWT tokens to perform verification processes in the application. For example, in order to verify user email address or to request password change. Is it a good idea in terms of security?
JWT is state-less authentication and is so useful if you use backend with multiple frontends (mobile app, website UI and ...)
Its security is also Depends on your implementation.
If you use different secret key than default fast-api tutorial (I saw it on some projects!) and use rational expiration date, its secure enough to handle big projects.
consider you should logout every login sessions of specific user, which is logged-out from one client if you have multiple clients. which means you should implement some kind of black-list JWT.
About verifications, I recommend using two factor verification. I usually use security code send to email or SMS code. It's more secure if you consider this scenario:
A user is logged-in on a device and JWT token is not expired. another user using same device in office and can change password without any second factor security layer. If you have code send to the mobile, its more secure and no one can access it easily!
How can a proxy username & password be passed to boto3 without using environment variables?
There is a similar stack question, however the question & answer focus on the url/port specification. I am sitting behind a corporate proxy and need to also specify user credentials; but I am not allowed to put my login credentials in an environment variable.
I will have to read the username/password into memory, but once I have them where in boto3 do they get inputed?
Thank you in advance for your consideration and response.
Proxy configuration for boto3 is described here.
Passing username and password is not documented, however if you look at the underlying code (httpsession.py), it will extract username and password from a URL like https://username:password#example.com:443, and insert a Proxy-Authorization header using basic auth.
If that works with your company, you should be OK. However, some proxies require a different authorization method, and this will fail.
In that case will need to discuss your company's exact proxy mechanism with your IT group. They may suggest work-arounds, such as running your own proxy to handle authentication. Or they may permit you to use a cloud development tool that avoids the use of proxies.
I mention this because your deployment environment -- whether cloud or a local data center -- probably doesn't use an authenticating proxy. Which means that code written with the expectation of such a proxy won't work in a production deployment.
What exactly is the 'secret' parameter of Pyramid's pyramid.authentication.AuthTktAuthenticationPolicy function? The documentation says that it's "(a string) used for auth_tkt cookie signing. Required." The tutorial says that it's "is a string representing an encryption key used by the 'authentication ticket' machinery represented by this policy".
What is auth_tkt cookie signing? What is this 'authentication ticket' machinery? Is this secret supposed to be something I store as a hash in a database or something? I'm really confused.
A tkt auth cookie is a secure hash of several pieces of information, including the username and optionally a timestamp, but not the user password. Once authenticated, you give such a cookie to the user, and every time the user returns you just extract the username again and know it's the same user.
To keep this cookie secure, you need to have a server-side secret, however. Only a server in possession of that secret can create these cookies; if an attacker ever got hold of it he could generate authentication cookies for arbitrary users without ever needing to know the passwords of these users.
The secret parameter for the policy is that server-side secret; it's like a master password for your server. If you run more than one process for your site (and with WSGI, you usually do), you need to make it consistent across your processes, to make sure each process can verify the cookies. You can specify it in your configuration file, in your source code, or in your database; it depends on how much flexibility you need, your security policies, and whether or not you need to share the secret with other systems.
You can share the secret with other systems in your domain that also need to authenticate your users, using the same standard. Apache has a mod_auth_tkt module for example, Plone uses the same standard, and by sharing the secret you can provide a single sign-on for your users across disparate web applications.
Note that changing the secret means existing sessions become invalid, and users would have to re-authenticate.
In any case, existing cookies can have a limited life-span; the embedded timestamp limits how long it will be accepted as valid, if you configure the timeout parameter on the policy. It's good policy to set a timeout, combined with a reissue time; any user that re-visits your application within the timeout will be re-issued a new cookie with a new timestamp to keep their session fresh. That way your session cookies automatically expire if your users do not return, and their cookie cannot be reused by an attacker at a later time. The reissue parameter lets you control how quickly a new token is issued; revisit your server within reissue seconds would not produce a new token.
The secret parameter as far as I remember is just a string used as a salt for the creation of the cookie. You can put whatever you want. Having it in your config file should be more than enough. Saving it in the database might be overkill though if you want to invalidate anything created, I guess changing the secret will invalidate all cookies and session create before that change.
Is there a way in Python/Django to get the username of the currently logged-in Windows user, from an app that is not running locally?
UPDATE: sorry, to clarify, by this I mean the Windows username of the user viewing the web page, not the user running the server.
I've tried both:
current_user = os.environ.get("USERNAME")
current_user_getpass = getpass.getuser()
But I think they're returning the name of the user running the server.
Thanks!
FURTHER UPDATE: I don't care greatly about security. It really doesn't matter if users spoof a username. What does matter is convenience. I just need a way to get the username without users having to fiddle around with passwords or install client-side software. Any ideas?
Three ways, none of which work.
Use the Ident (AUTH) protocol. It's technically cross-platform.
...except there are exactly zero Ident servers for Windows that are able to return the real user name instead of a static string.
Edit: Apparently Retina Scan Identd can do this. (Awesome.)
Require HTTP NTLM or Negotiate authentication. You get more than a mere username check,
...except NTLM is insecure, only Internet Exploder and Firefox support it, and they only use it inside the LAN (intranet) by default. Negotiate is able to use the more secure Kerberos, but it (obviously) requires Kerberos on both server and clients. If the Windows PCs are in a domain, good. If not...
If you control all client machines, you can use simple SSL client-certificate authentication. Works in all modern browsers.
...but every user needs their own certificate. Creating an internal-use CA and issuing certificates is simple; getting them installed and working in client machines - not so.
I am attempting to utilize Google App Engine as an Authentication Server for a mobile application that runs on android natively. User names and passwords will be stored in GAE and my goal is to be able to both store and verify credentials from the mobile application using GAE. Is this possible? I've looked into OAuth and JSON, but I don't think I have the proper setup for that.
Also, if I'm going about this the wrong way, please point me to the proper path.
If you are interested in having a more API-like implementation in your GAE instance, I would definitely look more into OAuth. But if you are only interested in validating credentials for this one mobile application then you need not go that far.
Fortunately you can call your GAE instance over SSL, that means that you can offload all the business of handshaking and encryption. Then I would simply use either http-basic authentication, or simply send user-id and encrypted password as parameters in the request.
On the iPhone there is a KeyChain for password storing, maybe there is an Android counterpart? Anyway, make sure to store passwords encrypted on the device and in the GAE-datastore. Send the encrypted password when validating credentials. You should never know your user's clear text passwords. That would provide a level of obscurity which I think is enough (definitely so when sent over SSL).
Then you can simply return whether the account credentials are verified or not.
If by "storign credentials" you mean storing username and password, then I imagine you are going about this the wrong way. Whether you are talking about OAuth or OpenID, the idea is that you never see or have access to the password (and perhaps not username either) of the delegated authentication mechanism. Instead you receive an authentication or authorization token to do your work (and in the case of OpeniD, some meta information about the person like first / last name and e-mail address).
By the way, have you considered a 3rd party, such as Janrain?