We are using Ncipher/Thales HSM to store keys.
The Operator card used for this is protected via passphrase.
We are using PKCS11Interop to communicate with the HSM and the PIN needs to be provided to communicate with HSM.
What is the industry practice to store such security pins / pass phrases for an unattended process?
We need to install our application in multiple boxes , how do we maintain security of the pin.
We used two different practices to store PIN data and becoming attended or unattended is not different. You have to store PIN Data in protected environment, SQL Server or MainFrame systems that access is safeguarded and highly controlled.
Not only environments but data format is important, you can not store clear PIN data but in encrypted forms. You have to use HSM for encryption-decryption too.
Store PIN Data encrypted under LMK form.
First encrypt clear PIN data with "Encrypt a Clear PIN" command(BA) and store output data. To verify PIN , you have to call "Decrypt an Encrypted PIN" command(NG). If you want to use those commands you have to enable "Clear PIN" commands in Thales HSM so its is highly vulnerable to insider attacks. If an insider who have access to PIN data and HSM, can easily get PIN values.
Offset Method.
You do not store sensitive information that can be used to generate clear PIN but data that can be used for verification purposes only. You store Offset, Decimalisation Table, PIN Validation Data for verification of data that comes from customer(PIN is sent to central servers under ZPK or TPK encrypted from ATM). You can not generate customer PIN from those data so it is more secure. You can use PIN Verification Commands(DA,EA)
Related
I want to lock my app with a 6 digit pin. When the user creates a new pin the hash of this pin is saved in flutter secure storage. A pin is proofed by getting the hashed pin from the secure storage and comparing them. Would this be secure?
import 'package:flutter_secure_storage/flutter_secure_storage.dart';
import 'package:steel_crypt/steel_crypt.dart';
//Saves the hash of the pin in FlutterSecureStorage
Future<void> createPin(String pin) async {
const secureStorage = FlutterSecureStorage();
//Hash the pin and save the hash
var hasher = HashCrypt(algo: HashAlgo.Sha_256);
String hashedPin = hasher.hash(inp: pin);
await secureStorage.write(key: "hashedPin", value: hashedPin)
return;
}
//Check if the given pin is correct
Future<bool> checkPin(String pin) async {
const secureStorage = FlutterSecureStorage();
var hashedPin = await secureStorage.read(key: "hashedPin")
var hasher = HashCrypt(algo: HashAlgo.Sha_256);
return hasher.check(plain: pin, hashed: hashedPin);
}
Disclaimer: I am not a certified security expert, but based on what I do know about it, I'd say it's quite secure.
I did the exact same thing on another app of mine, and here is the reasoning/logic when determining that it was secure enough for my use case:
Flutter secure storage uses methods channels to Android's KeyStore and iOS's Keychain - those are operating system APIs provided by Apple & Google to us developers, and are made specifically for storing sensitive data.
When those APIs encrypt and decrypt values, only the operating system (not even our own apps) have access to the decryption keys and/or salts. Meaning no apps, not even our own could decrypt without the help of the operating system, who governs who should have access to decrypt something for a given app.
Like your approach, I was also storing the pin as a one way hash only (and not the actual pin, the truly sensitive data) and using flutter secure storage (hence OS provided encryption) also means that the data is encrypted at rest.
Future checks on pin input were also one way hashed, and compared to the securely stored value.
That said, it's all software running on an environment you don't control, so could it be hacked? Yes. But I'd trust the Apple and Googles data security engineer's abilities to harden against attacks far more than mine.
Well, the description of secure storage changes with consideration for
the platform.
If the platform is Android, then flutter_secure_storage stores data in
encryptedSharedPreference, which are shared preferences that encrypt
keys and values. It handles AES encryption to generate a secret key
encrypted with RSA and stored in KeyStore.
For the iOS platform, flutter_secure_storage uses the KeyChain which
is an iOS-specific secure storage used to store and access
cryptographic keys only in your app.
In the case of the web, flutter_secure_storage uses the Web
Cryptography (Web Crypto) API.
As wrote above, it depends, i trust on this package on my projects and never got any trouble, since it's made for it.
I strongly believe that the big Companies that use flutter make their own solution.
Of course you could do some research and develop your own encryption, but that will cost some time, if you want to study some alternatives to FlutterSecureStorage:
SQFlite with SQLCipher support
Sembast
Hive
Drift
Otherwise, i strongly recommend you to stick with this package.
I have created a suite of two different Flutter apps that share a single firestore database.
The first app generates a QR code that would then be scanned and verified by a user of the second app. The QR code information is a string that contains some information I don't want users to see by simply scanning the QR code with their camera app.
I want to encrypt the string in the first app before encoding it into a QR code, and decrypt the string in the second app after the QR code has been scanned, but that means I would need to have the encryption key accessible in both apps.
Would I have to hardcode this key into the apps or transmit the key through the database? How can I achieve this in the most secure way possible?
You can use almost any mechanism you want to transmit the keys, but the one thing you shouldn't do is transmit it through the same database as where you store the encrypted data - as that would put that data at risk if the database is compromised.
So mail them, text them, write them on a piece of paper and mail it, or you can organize an in-person meeting/party where you exchange them (h/t to Little Brother). It doesn't really matter how, as long as it's a different mechanism than you used to store/exchange the actual data that is encrypted with those keys.
You can hard-code them in the apps too, but what the keeps anyone from downloading that app too and using it? Or is that precisely what you want, in which case 👍
currently developing a new feature on my Web App i'm having a question:
I encrypted some data because i dont want it public in the blockchain but i have some concern about this, ideally the encrypt/decrypt password should be the privatekey of the keeper connected user but since we don't have access to this info in Waves Keeper, what would be the best practice ?
How can we encrypt/decrypt data in a decentralized manner with Waves Keeper?
im currently using a password predefined by me as an environment variable on the server side but this is far from ideal and definitelly centralized aside of having several downside.
Of course there is few backup options like:
1) Simply avoid put any non public data in the blockchain
2) Add an encrypt/decrypt field in the App requiring user to enter his password everytime
Both would work but are just getting around the problem and not ideal, would like to know if there is any good solution first :)
There are two methods in Waves Keeper API to encrypt/decrypt data. You can find details on the github.
https://github.com/wavesplatform/waveskeeper
I have a web application in which registered users enter data in a few forms and then, when they log in at a later stage, they see forms populated with their data. Data is stored on Postgresql server of the same hosting provider of the web server.
I'd like to encrypted data stored on Postgresql to prevent them to be read by the hosting provider.
I don't think this is possible to do, because whenever is the encryption key kept, if the webserver has to access it in order to serve pages to users, then it can use it to decrypt data to read them. Anyway I preferred to ask just to be sure I'm not missing something.
You could encrypt every piece of data put into the database, but for most applications it would be impractical - slow and extremely inconvenient.
Much better option would be to use dm-crypt encrypted block device for PostgreSQL data directory. It would be transparent for a database, so all features would work fine.
But you'd have to save encryption key somewhere in the database server filesystem or your server won't start with no interaction. So malicious hosting provider can still access all your data. Even if you don't store the key in the filesystem and type it yourself while mounting a data volume, then the key would have to reside in server memory, so malicious hosting provider can still read it.
There's not much you can do - you have to trust your hosting provider somewhat. You can only make a malicious one's live a little bit harder.
I'm storing some healthcare data on a mobile phone and I'd like to know what the best system of encryption is, to keep the data secure. It's basically a bunch of model objects, that I'm serializing and storing using NSKeyedArchiver / the equivalent on Blackberry (the name eludes me for now)
Any tips? I don't want to make up security protocols as I go along, but one of the other threads suggested the following approach.
Generate a public / private key pair
Store the public key
Encrypt the private key with a hash of the user's password.
Use the public key to encrypt the byte stream.
Decrypt the pvt key, keep it in memory, whenever the user logs in, and decrypt the stored data as needed.
Is there a more standard way of doing this?
Thanks,
Teja.
Edit: I appreciate it that you're trying to help me, but the things currently being discussed are business level discussions, on which I have no control of. So rephrasing my question, if you ignore that it's healthcare data, but some confidential data, say a password, how would you go about doing it?
There might be an easier way for secure data storage. With iOS 4.0 apple introduced system provided encryption of application documents. This means that the OS is responsible for doing all the encryption and decyryption in a fairly transparent way.
Applications that work with sensitive user data can now take advantage of the built-in encryption available on some devices to protect that data. When your application designates a particular file as protected, the system stores that file on-disk in an encrypted format. While the device is locked, the contents of the file are inaccessible to both your application and to any potential intruders. However, when the device is unlocked by the user, a decryption key is created to allow your application to access the file.
So only when your app is active, the files can be read back in unencrypted format. But the nice thing is that they are always encrypted on disk. So even if someone jailbreaks the device, or backs it up, the retrieved files are worthless.
This was probably introduced to conform to some specific data security standard that is required. I can't find that anywhere though.
For more info see the iOS 4.0 release notes.
http://en.wikipedia.org/wiki/HIPAA
Make sure you read and understand this!
edit: Sorry, didn't even bother to check to see where the OP is from, but even if they aren't from the USA there are still some good practices to follow in HIPAA.
HIPPA is a business practice and total system level privacy/security regulation. As such, an app can't comply by itself on random hardware for a random user. You need to determine how your app fits into a client health care provider's total regulatory compliance process before you can determine what algorithm might be found to comply with that process.
My best advice would be, don't store sensitive data in the user's mobile phone.
If that is not an option for you, then some kind of public/private key encryption, such as one you described, would be the next best option.