There is lots of information on encrypting and decrypting connection strings available. However, we need help on which method to use for our situation. We have many tablet clients connecting to an Azure database. We need to protect the username and password in the connection string on all of the clients. We don't want to have to create a key for each client but rather have one key for all of them. Better yet, no key at all. What is the simplest approach to use? Thanks.
In order for you to be able to decrypt the connection string, you would need to distribute a certificate to your tablets along with your application, and depending on the target OS that may be cumbersome or outright impossible.
My suggestion would be to put a middle tier between your clients and your database. It could be as thin as you need (e.g. look at OData), but would effectively protect your access to the DB.
Alternatively, set up a properly restricted user, and distribute the connection string in clear text.
Related
I have a website that uses default asp.net security to authenticate users and a table with password hashes and salts. Is it possible to compare these against the hashed passwords from the haveibeenpwned.com database?
Not really.
You can't do this by hitting the database directly, because you need to have the plaintext string in order to get the right hash to perform the lookup.
But you could approach it a different way - by cracking your existing salted hashes, using the cracked corpora of the HIBP data from hashes.org. This is not generally advisable in most circumstances, though.
You could also set it up to check it in circumstances where you already have the plaintext in hand - whenever users sign up, log in and/or change their password, etc. A general blacklist of the top X well-known passwords is generally a good idea - but I don't recommend using the entire 512 million passwords as a blacklist for new password creation without significant additional UX guidance on how to create good passwords (with Diceware-style randomly generated passphrases, or randomly generated strings stored in a password manager, etc.)
I am creating a cocoa base core data application. I would like to protect the sqlite database, prevent to read it out of the application. How?
You could use cipher algorithms to encrypt the database and decrypt when you use it in your app. CommonCrypto or SecurityTransform may be your choice. Take a look at the Cryptographic Services Guide Apple Dev-Docs.
The needed credentials could be stored securely in the OS X keychain.
So the user could per app start/login decrypt the database and on leave or something, encrypt it.
Another way could be to hardcode the credentials (maybe not a good idea, depends on the security standard you want to use by your app) and do the en-/decrypt on the fly per read/write into the database, so that the database itself is not encrypted but the records in it are. That could be more fault tolerant if your app crashes.
So there is no "right" way to do the task, it depends on what you want to archive and how secure the data has to be.
But what ever you do, don't save any credentials in the NSUserDefaults, that is absolutely insecure.
That would be like to have a secured chest and the key for it lays right on the chest.
For the iOS side there is is the Project iMas-encrypted-core-data on github. It might help you on Cocoa, too.
Aim of the project is to:
Provides a Core Data store that encrypts all data that is persisted. Besides the initial setup, the usage is exactly the same as Core Data and can be used in existing projects that use Core Data.
Under the hood they use SQLCipher and wrap the coreData methods into sql. So you get an encrypted storage but can use coreData syntax for accessing. No need to know about SQL syntax.
The project looks rather promising. It is definitely worth a look.
My APNS server needs to manage multiple p12 certificates/passwords to send notifications.
I'm using a Mysql DB to store p12 binary data and passwords.
The password is currently plain text...and it is a security issue...
What is the best solution to store this password to be able to use it with a "decoded version" when trying to send the notification
2-way encryption is always tricky and there's always a trade-off at some point. I think that a reasonable solution might be to:
Store the passwords using a well-known encryption algorithm. DO NOT invent your own.
Store the decryption key in a file on your server. It does not have to be the same server where the database storing the passwords is located. Do not store the key in PHP. Of course, you must take the utmost precaution to protect the decryption file.
A few options / alternatives :
You could take this one step further and change the certificate and
all the encrypted keys in the DB every few hours. If someone is
trying to brute-force, this might buy you time before they realize
what you're doing
Use multiple decryption keys stored on different machines. If one machine is compromised and the DB stolen, without all the decryption keys, the db is worthless. Of course, if all your machines are compromised, you've got bigger problems.
In the past I've used a Singleton Pattern to load the connection string when the application starts via the global.asa file.
I have a project now where each user has a unique connection string to the database. I would like to load this connection string once. The issue is that the singleton pattern will not work for me since each user has there own connection string. Basically the connection string is created dynamically.
I do not want to store it is session. If anyway has a clever way of doing this in .NET let me know ?
Connections to the database are quite expensive, in terms of resources, and I personally would suggest that you reconsider your requirements of having one per user. Unless you can guarantee that the total number of users is going to be very small (say no more than 5-10).
Having said that, you can just store the connection in the User object that represents your user. Or have a global dictionary that maps user ids to connection strings.
If the only difference between the connection strings is the username/password, you could consider impersonating the client and using Windows authentication in SQL Server instead.
I've got an issue with WCF, streaming, and security that isn't the biggest deal but I wanted to get people's thoughts on how I could get around it.
I need to allow clients to upload files to a server, and I'm allowing this by using the transferMode="StreamedRequest" feature of the BasicHttpBinding. When they upload a file, I'd like to transactionally place this file in the file system and update the database with the metadata for the file (I'm actually using Sql Server 2008's FILESTREAM data type, that natively supports this). I'm using WCF Windows Authentication and delegating the Kerberos credentials to SQL Server for all my database authentication.
The problem is that, as the exception I get helpfully notes, "HTTP request streaming cannot be used in conjunction with HTTP authentication." So, for my upload file service, I can't pass the Windows authentication token along with my message call. Even if I weren't using SQL Server logins, I wouldn't even be able to identify my calling client by their Windows credentials.
I've worked around this temporarily by leaving the upload method unsecured, and having it dump the file to a temporary store and return a locator GUID. The client then makes a second call to a secure, non-streaming service, passing the GUID, which uploads the file from the temporary store to the database using Windows authentication.
Obviously, this isn't ideal. From a performance point of view, I'm doing an extra read/write to the disk. From a scalability point of view, there's (in principle, with a load balancer) no guarantee that I hit the same server with the two subsequent calls, meaning that the temporary file store needs to be on a shared location, meaning not a scalable design.
Can anybody think of a better way to deal with this situation? Like I said, it's not the biggest deal, since a) I really don't need to scale this thing out much, there aren't too many users, and b) it's not like these uploads/downloads are getting called a lot. But still, I'd like to know if I'm missing an obvious solution here.
Thanks,
Daniel