What is the best practice for securely storing authentication credentials in a web extension? e.g. The user enters their username and password, and the extension saves these credentials in order to authenticate to an API in the future.
Currently, I have been using the sync storage, but was wondering if this has the same level of protection as saved passwords in the browser (for example, getting encrypted with a master password)?
Or, is there a method to store/retrieve the login details in the browser's password storage (but, obviously not being able to retrieve any other passwords)?
Do any of the answers above change if storing an API token, rather than full login credentials?
Related
I am building a Flutter For Web Application that needs to store the credentials in a secure way, to allow the user to automatically login, how can i achive this?
In typical web applications (whether flutter_web or not), it is not wise to actually store the user's password in the browser in a cookie or in html storage. One technique some use is to have a persistent cookie that stores the username and a temporary authentication token of some kind that is encrypted with a private key. The authentication token is temporary but exists on the user record in the database and can be used during the time it is allowed to be valid in place of the user's password. This way the user's credentials aren't persisted in the web browser - only the username and the token in an encrypted, persistent cookie.
From what appears to be in the dev preview of Flutter web is that it produces web applications, and I am assuming that standard web development techniques for user security for any and all web applications should be used.
You can use this package
Seems to me it supports both web and android
https://pub.dev/packages/password_credential
I'm looking for detailed insight into how does sites like mint.com and sigfig.com (etc.) secure credential information. Millions of people trust not just their login information to the primary site, but also their FINANCIAL sites, and not just one but often MANY financial sites.
This is a question at the architecture level. The sites obviously employ penetration testing, active monitoring etc. And they must be doing strong encryption such as:
https://crackstation.net/hashing-security.htm
If a small business/web site wanted to be as secure as possible storing this information, how would they go about it?
So you want to store user's passwords to external sites securely...
You can't use hashing here, because you need to know the plaintext value and send it to the external site to login.
Ideally you'd use something like OAUTH here instead, but not every site supports OAUTH.
Here's what I would do:
Encrypt the external.com credentials with a key derived from my password for you.com (I need to be logged in to you.com for you to grab data from external.com)
I create an account with you.com with a username and password and login
You hash my you.com password and store in the db
Each time I login, you generate a key derived from my plaintext password, which you keep in server-side session while I'm logged in
I add credentials for external.com
You encrypt these credentials with my you.com key and store in the db
You decrypt my external.com credentials with my you.com key and then login to external.com on my behalf
An even better approach would be to add a second server that only stores the external credentials and connects to the external sites and returns authentication details (like a session cookie).
I have a chrome extension which allows users to exclusively login with google and no other provider.
In my (node + couchdb) backend I need to construct a user account from the auth Response provided by google's oauth2 api. I was thinking about using a hash of the id_token as a password after verifying the token using the tokeninfo api
I realize that the id_token changes from time to time. In that case I was hoping to update the user's password automatically.
Here is the flow I had in mind:
1) User signs in on the front-end and gets an id_token from google
2) Id token is sent to the server and verified using the tokeninfo api
3) If verified, a user account is created with a password being the hash of the id_token.
Do you see any security holes with this flow? If so, what are the alternatives?
It is probably annoying to change user passwords all the time, and this ties your authentication too much to google. What if you want to implement password logins in the future, etc.
I would recommend to use something like proxy authentication instead.
http://docs.couchdb.org/en/latest/api/server/authn.html#api-auth-proxy
make sure to set
[couch_httpd_auth]
proxy_use_secret = true
in the config.
On a side note: if you sync the couchdb password with external secrets like in the question, you should sign the password with a hashed secret that you control completely.
I run a service that integrates with a few other cloud platforms via their apis. In order to do this, we have to store the login credentials for OTHER sites in our database. Obviously security is a bit of a risk here.
So far, we have been storing the passwords using AES encryption and a salted version of the user's password(for our site) as the cipher. When a user requests something from the api, they must input their password. The password checked for validity against the sha hash that we store, and once confirmed, is used to decrypt the password.
The problem is, we would like to start offering a service that retrieves data from the apis we interact with at scheduled intervals(outside the scope of synchronous user requests.). If we do this, our current security structure will no longer be viable.
My question is, are there any ways to allow for this type of api interaction without storing recoverable versions the passwords in our database? If not, what are my options for securely storing passwords?
we would like to start offering a service that retrieves data from the apis we interact with at scheduled intervals(outside the scope of synchronous user requests.).
This is what the OAuth protocol is designed for. The OAuth 2.0 code grant gives a client application an access token and a refresh token. The refresh token allows the application to get an access token even when the user is not there to authorize the request.
I'm working on a web application which involves connecting to Gmail on behalf of a user to check for new messages. Is there a way to securely store the user's credentials so that they can still be recovered for the login, or is there some way to obtain a token for Gmail to use in connections?
EDIT: The application is meant to be used mostly with mobile users, so they won't be logging into the site frequently. Thus, storing information in a cookie isn't viable.
If you logged into GMail's web interface it gives you a token in the form of a cookie. If yYou could use that token and the web interface then you could access their email without storing their credentials. Of course that isn't IMAP access, and it expires (as a good token should).
Alternatively you could encrypt their credentials with a value you store as a cookie on their computer. Then when they access your site you can check their mail without ever storing the encrypted credentials with the key to decrypt it.
Neither is an ideal solution, but hopefully they get you moving in the right direction.