I need to create a desktop application via C++ that could store previous successful connections to show it for user next time. What is the best practice to store such login data? Is it acceptable to store it in the encrypted form inside some file or DB? If yes, what type of encryption is the best for such purpose?
the main problem of storing login data is, that you have to retrieve it and you want retrieve it without user input some password. so the password is decodeable by design and the only protection of the password is security through obscurity. so it does not really matter how you encode the password since Joe Badguy can retrieve it in any case. just do not save it in plain text or some "encryption" like XOR. also maybe do not name the parameter "password=" to make detection a bit more difficult.
Related
I am using SQLCipher in a c++ project. It has multiple users and each one has to have their own database credentials. Can SQLCipher do this for me? If yes, please leave a sample code. If no, please share your opinions of how to do it.
No, you cannot. It looks like SQLCipher uses a key derivation function to turn your password into a key that is applied per page of the SQLite database.
What you can do instead is the usual trick to enable multi-party encryption:
Encrypt the database with a completely random key k;
Store tuples of (user, encrypt(k, user_key)) in a file next to the database.
user_key can in turn be generated from a password using a key derivation function.
Let's say I want to pass information to the user that includes the user's unique id. Then, I want to use that id for CRUD operations. Is it a viable, or even recommended, option to store a cryptographic hash of that data, which would remain static using something like SHA-2 and then verify that what the user passed to me was what I sent them? Or, should I never send them the information in the first place and just look up the information from a table?
My issue now is that I am using AWS Cognito and using the sub as the unique identifier. So, I do not want to 'trust' the end user with sending me that sub after cognito provides them with it.
I want to implement a "fast login".
I'm developing an enterprise software where a lot of users work in the same organization with the same data in the same computer and I want to be able to know who did what and when. Right now they have to log out and log in and load the data has to be loaded into the store all over again.
What I want is for them to be able to, without logging out, click on a user, from the organization, insert his password and the user is switched while preserving the store.
Any idea how I can accomplish this?
I'm using ember-simple-auth v1.1.0 and ember v2.10.2
The simpliest solution would be disabling page reload when user logs out. As far as I know, it's a reload causes data loss from store, not a logging out by itself. To do this, you need to overwrite sessionInvalidated method in your application route. For example,
sessionInvalidated() {
this.transitionTo('/login');
},
But remember - you lower security with this method: if someone will log out and leave webpage with app open, other person will have a possibility to extract data (if they have enough technical background to at least install ember inspector).
Other solution will require heavy research. I think it should be possible to implement custom authenticator which would allow to authenticate new user without logging out previous, by simply replacing tokens in store. But I don't know how hard it will be to implement and what obstacles you can meet. You will need to read ember-simple-auth's sources a lot, that's for sure.
I was actually able to solve it by simply using authenticate() with another user but never calling invalidateSession() which is the function that calls sessionInvalidated() that looks like this:
sessionInvalidated() {
if (!testing) {
if (this.get('_isFastBoot')) {
this.transitionTo(Configuration.baseURL);
} else {
window.location.replace(Configuration.baseURL);
}
}
}
So by not calling sessionInvalidated() the user isn't redirected or the page refreshed and the new user is able to keep using the store without switching pages.
I'm using AWS S3 in my C++ app to upload and download files. I've included the access key and secret in my code but I'm worried someone could read them from the binary. Is there any standard technique for obfuscating them?
Update: I'm not running this app on a PC, it's actually on an embedded device so I'm not worried about users reading the key and secret from a file or RAM (accessing the device is a lot harder). What I'm worried about is someone binwalking our update file and pulling the key and secret from the binary.
Storing a secret in computer is not an easy task. One thing you could do is encrypt the key using a password and store the encrypted data in a file. Then when user enters a password you can decrypt the encrypted data using the password and retrieve the key - which you can use.
But this approach will not work for scenarios where the software needs to run without user intervention.
It is better not keeping keys in code. Input when needed.
If kept in code, do not keep the key in simple string. Keep it in some pattern, and generate the key by some algorithm when needed.
I'm building a server-side application which requires the data the be stored encrypted in the database. When a client accesses the data, it also has to be transferred encrypted. The clients each has a unique login.
My original idea to do this, is to store the data encrypted with a symmetric-algorithm like AES. So when a client wants to access the data the encrypted data is transferred to the client, while the key is encrypted with the public key from the client.
Is this a secure way to do store and transfer the data or is there a better solution to this problem?
Update: If following Søren's suggestion to keep a copy of the AES key encrypted using each client's public key, wouldn't that include the key to be stored somewhere in order to add additional clients or could that be generated in any way?
First you should start by defining some security properties you want to provide, for example:
Is it ok to give different users access to the same secret key? Aka if File1 is AES encrypted with key K, is it a problem if user Alice and user Bob both are given K.
How do I revoke users from the system? (It turns out Bob from scenario 1 is actually a Chinese spy working for our company, how do I securely kick him out of the system).
Does the encrypted data that is saved in the database need to be searched? (This problem is well researched and hard to solve!)
How much (if any) and what plaintext data will be placed into the database to help organize it? Databases expect data to have unique keys associated with them. You need to make sure these keys don't leak information, but are useful enough to retrieve the data later.
How often should secret keys be changed? If you are storing files and multiple users are allowed access to encrypted files, what happens when user X modifies a file? Does the secret key change? Should the new key be sent to all users?
What happens when 2 users modify the same data at the same time? Will the database be able to handle this without modification?
There are many others.
If the server is not trusted and must never see plaintext data, then here's a general overview of a possible solution.
Let the clients managed the crypto completely. Clients authenticate with the server and are allowed to store data into the database. It is the responsibility of the client to make sure the data is encrypted.
In this scenario, keys should be saved securely only on the clients computer. If they must be placed elsewhere, a "master key" could be created.
Secure from what? You need to define your goals more clearly.
The solution would protect the data during transfer, but from your description, the server would have full access to the data (since it'd need to store the AES key unencrypted). In other words, a hacker or burglar with access to the server would have full access to the data.
If secure transmission is what you want, use an SSL / TLS wrapper around the database connection. This is a standard solution from all major vendors.
To secure the data server side, the server should not have the AES key. If the number of clients were limited, the server could store a copy of the AES key for every client, each copy of the key already encrypted with the public key of each client, such that the server never sees the plain text data nor any unencrypted AES keys.
That is indeed the common approach, e.g. also used by NTFS file encryption.