I have an app which allows connections to multiple servers. At the moment I'm storing all connection details except the password using chrome.storage.sync.
Is it possible to store username/password combinations using the standard built-in password manager ?
Is it possible to store username/password combinations using the standard built-in password manager?
In short, no. There is no API to work with password storage of Chrome.
How to do authentication in a Chrome extension anyway? Here's an old question on this topic.
What changed since then is that Chrome has now a dedicated API for OAuth, chrome.identity, which provides a secure way of logging onto web services.
However, if you're looking to make something like a local password manager, then you cannot really protect against a malicious user. All storage you can access, and all encryption/decryption functions, are available for a user to inspect.
A server component that handles a certain decryption step is a good measure, but not always applicable.
Edit: as suggested by Vloz, a Native Client module that handles crypto functions is a good step to obfuscate data.
Related
I am building flutter mobile app that is intensively using firebase services and firestore.
in app start, the app communicates with firestore to retrieve some basic keys and paramaters that app uses in different services, like APIs Keys, IDs, .. etc.
would like to understand if this approach is secure enough? or there is a possibility that communication (firestore query) to be hacked somehow and the keys are stolen?
Note: I am using simple firebase rule that allow read and write if user is signed in using Firebase Authentication
I can indeed hardcode these keys in the app code, however I prefered this database approach to give myself the chance to change these keys if it is changed by the services providers for any reason.
any answers or links are much apprecaited.
You should assume that any value used inside your client-side application can be found by a malicious user and used for their own purposes.
Once someone has those keys, they can call the APIs that require them differently than what your own application code does, unless you use some other means to prevent this such as Firebase's security rules and App Check.
When using security rules, the best way to prevent somebody from doing something different from your application's use-cases is to encode those use-cases in the security rules too. So instead of just requiring someone to be signed in, expand your rules to validate that only the operations that your own code requires are allowed. Use-case by use-case lock it down, until your cod and rules cover the same set of use-cases.
Also see:
Is it safe to expose Firebase apiKey to the public?
google FireStore security hack from web console
I couldn't find information on how other people solve this, so maybe you can help me out.
What I have
Multiple Services with REST APIs, that are secured using OpenID Connect. Connections between the Services work fine.
Now I have multiple developers, who sometimes need to write and execute local scripts (Python, R, Bash etc.) for quick analysis and testing.
What I want
I want to enable the developers to use the services as easy as possible, but still respecting security concerns.
What I tried
I defined the script itself as a client. Therefore I created a public client in my OIDC product, which is called somewhat like 'developer-scripts'. Using a library which handles the oauth dance, I can then execute the script connecting as aforesaid client. First time, the browser pops up and requests the user to authenticate and therefore authorize the client to use the REST API on behalf of the user. After that, the tokens are cached and I can easily continue working on that script.
This simplified drawing tries to summarize, what I just described
That works perfectly fine and regarding security I'm glad that credentials are not saved on the local computers as it was before with e.g. Basic Authentication. Furthermore, I'm able to control the access to different services on a user level.
Other ideas, which didn't convince me:
every web service also has an public client which can then be used as a client by the scripts (so the scripts aren't defined as clients anymore)
token generation is done somewhere else and the developer just adds the generated access/refresh token to the script
My problem
What concerns me about my current solution is the definition of that client. In the described case it would be either a generic client used by all developers for all scripts, or a new client for every developer who want's to write a local script. The latter seems to be a lot of overhead, the former may be a security problem?
So finally I'm asking the question: Are there any known best practices for my described use case?
EDIT:
I found a small article by [Martin Fowler](https://martinfowler.com/articles/command-line-google.html), he is basically explaining, how he is receiving a token to use for a local script. But in his case, he's using it for one certain use case, and not as a general public client. So unfortunately it doesn't really contribute to my answer.
I want to keep things as simple as possible and I don't want a complicated security mechanism. Basically I need for a user an ID and an e-mail address and I really don't want to bother about other things. Also, I was a minimum overhead in terms of security (if there is anoter provider who can do it for me, that's even better).
What is the simplest way to do this? I was thinking about incorporating LiveID or OpenID by I don't know what are the advantages/disadvantages.
I am working with the Azure SDK.
If you use the Windows Azure Access Control Service, you can basically outsource all identity management. Take a look at the Windows Azure Platform Training Kit - there's a lab called "Introduction to the AppFabric Access Control Service 2.0" that will get you up and running quickly. Currently, you can choose any combination of the following identity providers:
WS-Federation
Facebook
Windows Live ID
Google
Yahoo!
"Simple" for whom?
The simplest strategy for you would probably be to use ASP.NET's standard SQL-based authentication provider. You just run a script against your database to set up all the tables, and then you use ASP.NET's built-in utility methods to authenticate. Give your user-specific tables a foreign key reference to that user's ID, and you're good to go. We've done this, and never had any trouble with it. It's a tried and well-used system, so you know you won't be introducing any security invulnerabilities by hacking your own solution together. (see SqlMembershipProvider vs a custom solutions)
If you want something simple for the user, then an OpenId solution would be my pick. Set up something like StackOverflow has, where you can let users choose an account from a number of trusted providers to allow them to log in. From the user's perspective, it's really nice not to have to remember one more username and password for one more site.
I am currently writing the backend for a service which has 3 clients: browser, android native and iphone native. I am having a little trouble with coming up with an authentication system since I don't know what can really be done on the clients.
I am using django + twisted for the backend.
Basically, I am going to be writing RestfulAPIs to open up for the clients on both phones to call.
Now the real question is, how should I come up with an authentication system?
I have thought about using sessionids, this works very well with the browser and I can use django's integrated app for that.
However, I don't know if it's possible for both the iphone and android to obtain a unique sessionid on the handset. Should I write an API call to distribute unique sessionids?
if that's the case, is it possible for me to still use django's authentication system since a lot of the stuff here are customized? ( I am not even using a rdbms - I am sticking with mongodb, so I was on the verge of dropping django's authentication app ftm).
I have looked at foursquare's API and their basic auth method requires you to pass in user:password in every http request header. That adds 1 additional authentication each call which can kind of seem excessive.
Please provide any kind of advise that you could give.
You might look at digitally signed RESTful requests, such as what is done with Amazon S3.
I'm building a web application that will have access to PeopleSoft's database via jdbc.
Is it possible that I can use PeopleSoft's id/password for my custom application, so users accessing my website will not have to have another username/password?
Peoplesoft stores user details in the table PSOPRDEFN.
You will be able to verify the username against: PSOPRDEFN.OPRID.
The password field is: OPERPSWD.
Unfortunately the encryption function used for this field: hash() is available only from within peoplecode.
If you want to use a single sign on you should be able to do so by customizing the USERMAINT.gbl component perhaps in the saveprechange peoplecode, to save the password in a second field of your choice with an encryption algorithm that you can implement from JDBC as well.
If you want to reuse PeopleSoft security, you'd need to connect at a higher level than JDBC straight into the database. You could look at a component interface (codeable in Java) or send a SOAP message into PeopleSofts Integration Gateway - both methods would authenticate you against peopleSoft using its own security mechanisms.
The old way was to customize psuser.c to your needs and recompile as a new dll, used it your program, assuming you're on a Microsoft platform. As mentioned above, you could have a peoplesoft developer create a component interface ( or use the one that is delivered ). You can export wrapper Java or C/C++ code from a CI, a template. This code can then be used in an external program to call the CI. one way or the other, you have to interface with peopletools to call their decrypt for passwords.
Depending on how dynamic your business is, whether you add lots of employees each day, you could export psoprdefn using app messaging to another database. On the send, you could encrypt passwords however you like. But as you can surmise, this would not be real-time.
One thing I remember doing long ago was have a peoplesoft tech person develop a page the sole functionality of which was to call my java class and which obtained user/pswds as needed. Once I had them, I was good to go.
You can use the psjoa.jar , in that way you can signon via app.server using the same users and passwords in the psoprdefn table.
PeopleSoft has an LDAP integration ability but it has to be configured. If you are accessing via a Java wrapper around a component interface, a special account can be set up in PeopleSoft with access only to the underlying component, but the login/password would have to be passed into the component interface. This can be encrypted or sent over https.
PeopleSoft also has what it calls "row level" security - the ability to partition data sets so that for example your code could only access employee data within a specific business unit or accounting info for a particular line of business. This is all controlled within the PeopleSoft online security application.