I develop REST API for some application and use token-auth. However I came up to one problem about storing tokens in database:
Store them using some safe hash function like bcrypt or sha3 and display them to user only once after generation - therefore those tokens would not be backwards readable and could not be displayed to the user in the future - impact on quality for the customers
Store them in plain-text - if database got compromited all tokens has to be regenerated - that's impact on quality for the customers as well
Encrypt them using user's password - impossible due to database may contain multiple users which have access to tokens.
I saw that a lot of services like Google, Github and Facebook that are able to display tokens on-demand without any special procedure needed. Do they store them in plain-text or ?
Related
So I have a restful API that is responsible for handling the licenses for my app, it records
User ID
User email
Username
license expiry date
Currently what happens is the user authenticate via a third party auth service (firebase) then the app takes the user ID from firebase auth response and get the license info without any authorization on the license API.
Essentially if you have a user ID you can get all the info mentioned above
My question: Is this a security flaw? or is this acceptable considering that it is very hard for a malicious user to obtain another user's ID and even if he obtains the ID the info is not really that useful
This is a data protection question, not a programming question and you watch it from the wrong perspective in the comments. Information security and data protection and totally different jobs with different mindset.
User ID - personal data
User email - personal data
Username - personal data
license expiry date - probably company secret
What do we protect here?
Some not that sensitive personal data like username and email, which can be guessed by checking the companies webpage or linkedin. The license expiry date is not that important I guess, maybe the company wants to keep it in secret, who knows, better to ask them. The user ID if it is used only here is not a big deal.
What happens when somebody gets the user ID?
They can watch the upper data 24/7 until you add proper authentication or change the User ID. It does not matter how they get it, let's assume they can. They can watch HTTP packets, or an employee sends it by accident to somebody, or they steal this part from the database or they get it from HTTP server logs when you throw out a faulty HDD, who cares?!
What would be the effect to your company?
If your customers don't care about it, then ok. If they would terminate the contract immediately and report the data protection incident to an authority, you will be sued, etc. then it is an issue...
What else can happen?
Do you have support? Can somebody use the User ID and the upper infos to trick your support into terminating the contract and sending back money to the bank account they give? If so then it is an issue either.
Risk assessment is about checking the probabilities, motivations, consequences, etc. of something like the upper and mitigate them if necessary with risk reducing protective measures. Such a thing can be for example encrypting and signing the User ID and the session expiration date before sending it to your API, if it is possible to send encrpyted signed JWT by FireBase.
If the only way to access the record is a randomly generated UUID, then it is reasonable to consider the UUID to be a "secret key" and knowing it the equivalent of an authentication token. The UIUD space is extremely sparse; they are not guessable any more than AES keys are guessable. So the data is as protected as the UUID. You of course should still use HTTPS to protect the URL in transit. I use these kinds of schemes regularly (where knowing the UUID or knowing the SHA of the data is the authentication).
Are there any packages, frameworks, or services to do client-side encryption of user data in Flutter, using firebase as a server?
I hope to build an app that handles some of a user's personal financial information and so I want no one else, including me, to be able to access it. Firebase allows a Dev to see the unencrypted database so I need to do the encryption on the client-side.
I think this will probably have to involve a client-side symmetric key used for encrypting and decrypting the user data.
My worry is how to store this key.
(1) Randomly generated key stored locally - doesn't allow the user to switch between devices and is lost if the device is lost
(2) Store it in a Google Drive - requires the user to have a Google account. (Advocated by this article from HackerMoon
(3) Generate it deterministically from a salted hash of the user's password (stored locally) - lost if the user forgets or changes their password.
(4) Allow the user to choose between a subset of the above
My question is similar to this one How to encrypt user data in Firebase but it covers situations were data is transferred between users and hence uses public key cryptography.
Questions:
What is the best way to encrypt user-data for a firebase db?
And if it is to use a symmetric key, what is the best way to generate and store this key so the user doesn't risk losing access to their data?
This one appeared to be the best solution for my case: flutter_secure_storage. It stores the data in an app specific container within the official key stores of iOS and Android
I am developing an app which uses several API services, the API requires that I provide username and password for API transactions, unfortunately no API token :-( in-order to automate I need to store username passwords somewhere, preferably database, I cannot use hashing because I need to send the username/password to authenticate and process API request, hence I am wondering how to go about it.
If I use Zend\Crypt to encrypt and store the password in database and decrypt whenever required, would this be enough for security? is there something else I must consider?
Looking for pointers.
PS: I am using ZendFramework2 with Doctrine/MySQL for the app.
Usually you would use a token mechanism (like OAuth). If that's not possible, one would use TLS/SSL client authentication.
However, if you rely on plain passwords (on the application-level, I still guess the username/password tupel is transmitted over a secure connection!) and you want to store them encrypted, you have to think of a meaningful mechanism to get an encryption key for your scenario. Just generating an encryption key and storing it on the same machine in plain does not provide more security.
Without more information on your scenario it is hard to make a suitable suggestion.
We are currently planning a facebook client for a custom embedded system where it is very time consuming for the user (because of the few available controls/buttons and no touchscreen) to enter his/her account details.
Ideally the user would only need to enter the details once and then they get stored and retreived from there until the user deletes them (or changes password). I've read up a bit on OAuth and the access tokens but as far as my understanding goes, the only way to achieve "configure once" functionality is by actually storing the username and password combination since the access tokens will expire (with the offline token being deprecated this year). Am I correct?
We'd rather not store the user details locally in our device because of security concerns but it seems like we have no choice?
Best Regards,
Ingmar
Normally you don´t need to store anything, as facebook handles everything. Only if you have to store user-specific additional data (or settings), you usually just store the Facebook ID only.
The apps that I build frequently have 'social media service' requirements; e.g.
Twitter
bit.ly
Facebook
For most of these services, I need to have an API key of some sort. I'm trying to work out the best way of including these API keys in the application binary. The desired level of security depends on the possible attacks that can be conducted by malicious attackers.
Twitter
I have an xAuth-enabled key and secret. Both need to be used by the iPhone app.
Fallout from attack
Malicious users could post twitter status updates masquerading as coming from my app. There is no twitter account to hijack and start posting status updates on.
bit.ly
I have a username, password and API key.
To login to the website and access analytics, the username and password are required.
To create links via the API, only the username and API key are required by my iPhone apps. The password will not be in the app in any form.
Fallout from attack
Malicious users could create links on my bit.ly account. They would need to do a separate attack to brute-force or otherwise gain the password to login to the account.
For both of those services, the potential for harm doesn't seem too great. But for other services, it could be much worse.
I can just define the API credentials as strings in the header or in-line in the code, but then it's vulnerable to someone using strings on the application to see what's in it.
I could then start doing silly concatenation / xor-ing in the code to recreate the API key in memory, and the attacker would have to do a bit more work to recover any keys in the binary. My concern with that is that I'm not a cryptographer and would create an embarrassingly weak form of obfuscation there.
What better suggestions do people have?
The attacker can just sniff your traffic and extract the secret from there. So any obfuscation is easily circumvented.
Even SSL won't help much, since you can intercept the networking API which receives the unencrypted data.
The secure way to solve this is create your own server, keep the secret stuff server side, and use your own server from your app, and the server then relays to the other webservice. This way the attacker never has access to the secret.
A good suggestion is not to worry about it. There are plenty of apps that store their API keys in plain text. The point is you need a lot of different bits of information to construct an access token.
As long as you're not storing username+password combos in plain text on the file system or transmitting them over the network without SSL/HTTPS etc then you're fine.