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.
Related
I am looking for advice and best practice in encrypting parts/whole logs in various formats (say JSON or CSV). I have 0 experience in encrypting anything.
(Disclaimer - I am using Nlog so if you have experience in that library, it would be great to get insight but I am also asking for general ideas/practices/processes.)
I want to encrypt and then decrypt parts of my logs, for example stack trace, user name and other minor things, while keeping other parts of logs untouched (they could be encrypted but there is no need). How to do that? Should I encrypt part of my logs, whole logs or whole files?
How common is it to encrypt logs? How should it be done? Using specific parts of a library to do the encryption or simply encrypting a string before passing it to the logger? How do you manage decrypting the logs after? Without encryption I can simply import my logs from JSON or CSV to Excel and do everything, but when parts of them are encrypted it complicates the process.
How do you organize the decryption process? Where/how do you decrypt? Is encrypting/decrypting resource intensive process, which might affect performance of a logging library?
Questions are rather basic but I am a novice programmer and I have not found answers on SO or other sites. Encrypting logs seems like an "odd thing".
Many thanks for all help.
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'm hoping to automate the downloading and installation of the free GeoIP databases and I want to know if there is any additional verification options avaliable given that MD5 is becoming more susceptible to pre-image attacks.
Additionaly the MD5 Sums are stored on the same server meaning any attacker breaking into that server will be able to upload potentially malicious database and have it be served without any client being the wiser.
GPG is a common verification tool, and it would be trivial to set up for most Linux users given their package managers already perform this sort of verification.
maxmind.com supports TLS SSL HTTPS on its download links (just add the 's' yourself), so be sure to keep your certificates accurate and libraries up to date and you should be as secure as is possible.
Even assuming their webserver gets hijacked, there's really no point in fretting about MD5 vs SHA vs GPG at that point as you would have no reasonable assurances or concept of the width and breadth of the attack. It might as well be an inside job intentionally perpetrated by the company themselves. maxmind makes no fitness guarantees against human or automated error, anyway, so take it under advisement.
For a free service (free database, free bandwidth, huge weekly updates) you can't exactly go begging for air-gapped fort knox rate security. TLS is already better than you'll need.
You are welcome to perform your own sanity-checking of a newly downloaded database against the previously downloaded database, to make sure any changes or corrections are nominally insignificant. Better still, you can use their GeoIP Update program or direct-download patches. This way, you are only downloading nominally insignificant updates to begin with, and can inspect them yourself before merging them into the database. And you'll be saving bandwidth for everyone.
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.
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.