I have developed a game for submission to the Apple Appstore. However, before submission, I am told that applications that contain encryption are not allowed. My game contains a XOR hash to secure the game assets so average users cannot easily extract them by opening the IPA file. Is a XOR hash considered encryption? Is a XOR hash allowed on the Apple Appstore?
iOS apps can use encryption.
A hash is not encryption, it is one-way and the original input can not be recovered.
Instead of an "XOR hash" consider a standard cryptographic hash such as SHA-512. Or does "XOR hash" mean some form of XOR encryption?
The flaw is that the encryption key must be in the app. Not a large flaw if it is hard-coded in the app code since the IPA can not be decrypted except by exection so the skill/effort is high.
Related
First, I'm working on a Master student's project, the project is a Web Bank System and apply encryption algorithms on this system.
The first algorithm which is a new encryption algorithm designed by the student who requested my help is to encrypt the sensitive data (Credit Cards information) on the database.
The second algorithm (which is a modified AES algorithm) is to encrypt the messages between the customer of the bank and the admin of the bank system using a web chat room.
Of course, there is no problem with the first algorithm because I can apply it to encrypt the Credit Card information submitted by the user and save it on the database.
But, the problem is that the professor that supervising on this student project insisted to secure the messages sent across the network by the admin and customer that they are using the web chat room and these messages must be secured using the second algorithm (modified AES).
As you all know, if I just code the second algorithm in Javascript to encrypt the messages on the browser client machine then send those encrypted messages to the server, that means this algorithm will be available to anyone who opens this webpage because we all know that Javascript is an open client source.
So, no more talking, I just want to ask that:
How to apply any encryption algorithm to secure the data transfer between client machine and server machine by using web application (for example web chat application) without to be this algorithm an open source to any client machine?
ADyson's comment contains the best solution to solve this problem practically, but it sounds like the professor has added constraints that prevent you from employing a practical solution.
It is not possible to execute an encryption algorithm on a client machine and at the same time keep the encryption algorithm a secret from the person and machine running the algorithm. They can always inspect the code.
As far as I am aware this is not possible, because the client will have to be able to both encrypt and decrypt messages; it logically requires the client understanding the encryption algorithm.
The strength of an encryption mechanism comes from the difficulty of reversing an encrypted message to plaintext without the key, even if one knows the algorithm.
If knowing an encryption algorithm allows someone to decipher a message without the key, then the algorithm is weak.
I am using encryptByKey() for SSN and Account Number encryption in Yii2. The problem is that it generates different encrypted data for the same Account Number when I try to re-generate it.
I can't match it in the database like the following:
Customers::findOne(['account_number'=> Yii::$app->getSecurity()->encryptByKey($account_number, "someKeyHere")]);
Is there any encryption method available to generate same encrypted data every time I encrypt it?
Thanks,
Generally, that's the way encryption is supposed to work. It is sometimes called "ciphertext indistinguishability." Yielding the same ciphertext every time a given plaintext is encrypted undermines security by allowing attackers to analyze collections of ciphertext for patterns.
In this case, it looks like you only store one instance of the encrypted account number; you could argue that because the "message" is never repeated, cipher text indistinguishability is moot. That could lead you to justify the use of ECB mode (if your API offered it) or a HMAC (message authentication code, offered by the hashData() method) to compute a lookup key. If an attacker gets access to your database, there will only be one instance of each key, and nothing is revealed.
However, this is still insecure if an attacker can provide account numbers that your system encrypts. For example, an attacker could pose a legitimate user and provide a SSN during registration. If they choose a duplicate number, and then look in the database, their maliciously chosen encrypted value will match a legitimate record. Or, if the system rejects their account number because it is a duplicate, the attacker will know that it is a number in use by a legitimate user. This is called an oracle attack.
If you use an HMAC (or ECB mode encryption), you would have to design your application very carefully to prevent chosen plaintext and oracle attacks. And, candidly, if you are now encountering these ideas for the first time, there are probably many other gaps in your knowledge that will lead to easily exploited vulnerabilities in your application.
I am developing a web based application that will be employed by numerous third party organisations
in numerous countries around the world.
The browser based client will feed sensitive data into a shared back end database.
All organisations in all countries will Read/Write data into the same database.
I wish to encrypt the data entered within the browser so that its safe while in transit
to the back end database. e.g. client side encryption.
I also wish to encrypt the data while at rest in my database.
This application will be developed using Java, Javascript (REACT.js), and Scala.
The backend database will be MongoDB.
I cannot find a good Key Management example/description e.g. how a key is properly generated,
distributed, stored, replaced, deleted, and recovered during its life time.
I have the following choices/decisions to make:-
Flavour of encryption, e.g TripleDES, RSA, Blowfish, Twofish, AES etc..
Key(s) Symmetric/Asymmetric and its/thier length
How should I securely distribute the keys to my clients.
How to keep my keys safe on my back end servers.
If keys should have a lifecycle of generated, distributed, stored, replaced, deleted.
How do I decrypt data that was encrypted with Key0 when I am now using Key1, or Key2?
How should I store my multiple keys for my multiple clients to enable me to encrypt/decrypt
each clients data.
Use HTTPS with certificate pinning to secure the data in transit.
Use AES for encryption. Do not use TripleDES, RSA, Blowfish or Twofish in new work.
Use an HSM.
Encrypt the data with a long-life key that is not distributed, encrypt that key with short life keys that can be changed as needed.
Considering the scope of the project get a cryptographic domain expert to design the security and vet the code.
I know that encrypted passwords can be stored in the web.config or hashed and salted passwords can be stored in a database, but is it possible to store passwords in something like a keystore?
Would a keystore even be a good idea to store 'service account' passwords that are needed by an application?
The closest analogue to a Java keystore in .NET/Windows world is DPAPI (http://en.wikipedia.org/wiki/Data_Protection_API). It stores encrypted values in the Windows registry, with the encryption key derived from system or user account level secrets.
It is in fairly wide use, though a paper was released at the 2010 Black Hat DC Conference detailing a crack against it (Google Docs).
Prior to that paper (and if MS fixes it at some point) I would highly recommend DPAPI for exactly what you are describing.
At this point, using DPAPI is probably (and unfortunately) the best option. A mitigating factor is that the crack is highly technical, difficult to execute, and requires quite a bit of OS access to pull off. A breach of a DPAPI key is most likely to be pulled off by a trusted insider with access to the system, as opposed to an external attacker.
So I would like to modify a PHP / MySQL application in order to store credit card but not cvv and bank account info securely. PCI DSS require 1024 RSA/DSA. A small number of users will be given private key in order to decrypt the batch file of account info for submission to payment processors monthly. I'm unclear if it is possible to have a system that would allow the users who have signed in with normal 8 digit passwords to modify their own account info securely. It seems that this is not possible, and the encryption should be one-way (ie each user -> admins; never allowing user to decrypt their own info again), with account info never exposed back to users even over SSL connections. Or is there a proper and easy way to do this that I'm unaware of that is PCI DSS compliant?
PCI DSS does not require 1024 bit RSA to encrypt. Older versions of the specification mentioned AES and 3DES by name, but I believe newer versions just specify strong encryption. Most people are using AES 256.
Encrypting data at-rest with an asymmetric algorithm doesn't really work. Symmetric algorithms work best. This allows the application to access the card data when it needs to. This doesn't mean you have to show the data to the user ever again, it just means the data is there when you need to get to it. If you're storing credit card authorization information, you'll usually need the card number for settlement. (It really depends on the features your processor has. Some of the small-business level processors store the card for you, but this is infeasible for large scale processors like Paymentech and FDMS.)
The problem is that you will have to rotate your encryption keys periodically. This is usually what screws everyone up. If you roll your own encryption, you need to make sure that you can specify n number of keys that are accessible for as long as there is data encrypted with those keys. At any point in time, only one of those keys should be used for encryption. Unless you have a deep understanding of crypto and key management in terms of PCI, you might want to go with a commercial offering. Yes, these are expensive, but you have to determine the best course with a build or buy decision making process.
Ingrian (now SafeNet) has a decent offering for a network HSM. It will manage the keys for you and do the cryptographic operations. It may also be possible to use their DB level encryption integration so that you don't have to change your application at all. (Though DB level encryption is dubiously secure in my opinion.)
This is a very deep subject; I've done a lot with PCI and suggest you hire someone to guide you through doing it properly. You'll spend a lot of money on false starts and redoing work, so get an auditor involved early to at least asses what you need and tell you how to implement the security properly.
You may have an easier time if you differentiate between data storage, access, and transmission.
Storage requires strong reversible encryption; the data is not useful unless you can retrieve it.
Access requires a user or process to authenticate itself before it is permitted to decrypt the data. Here's an example of a mechanism that would accomplish this:
Store the data with a secret key that is never directly exposed to any user. Of course, you'll need to store that key somewhere, and you must be able to retrieve it.
When each user chooses a password, use the password to encrypt a personal copy of the private key for that user. (Note: even though you're encrypting each copy of the key, security issues may arise from maintaining multiple copies of the same information.)
Do not store the user's password. Instead, hash it according to standard best practices (with salt, etc.) and store the hash.
When a user provides a password to log in, hash it and compare to your stored value. If they match, use the (plainitext) password to decrypt the key, which is then used to decrypt the actual data.
Transmit the data through a secure connection, such as SSL. It's reasonable (perhaps required) to allow users to access (and modify) their own data, as long as you continue to follow best practices.
Comments:
An 8-digit password implies a key space of 108 ~ 227 = 27 bits, which by today's standards is fairly terrible. If you can't encourage longer (or alphanumeric) passwords, you may want to consider additional layers.
One advantage to the multiple-layer strategy (user provides a password that is used to encrypt the "actual" key) is that you can change the encryption key transparently to the user, thereby satisfying any key-rotation requirements..
The standard admonition whenever you're designing a security solution is to remember that DIY security, even when following standards, is risky at best. You're almost always better off using an off-the-shelf package by a reputable vendor, or at least having a trained, certified security professional audit both your strategy and your implementation.
Good luck!