I am currently working on a service which requires users to pick a 4-digit password/pin, because it is a mobile service. I am encrypting those passwords with either 256 or 2048bit encryption and it will be hashed. The account is blocked after 4 wrong entries, and can only be entered by mobile phone. Would it be hard to crack those PINs? I am asking this because sensitive information is being stored. The database is connected to a web application, the application is loaded to the phone using twilio. The thing I am most scared for is that the database is being hacked via the web. What would be a good way to keep sensitive data secure?
If someone gets hold of the database, you would be pretty much screwed:
If you just encrypt the 4-digit passwords, an attacker can just build a table of the 10000 possible encrypted strings and can trivially decrypt the PINs.
If you use salt strings (and encrypt not PIN, but PIN+salt and store crypted(PIN+salt) alongside with salt), people have to make a per-password effort, but there are still only 10000 possibilities for each password (which is not very much).
Which means, yes, by all means you should keep the database off the web. (If the web application is only ever accessed through twilio, you can reject connections from any other IP range).
Since you're using twilio, just make sure that twilo only talks to your web service using a secure protocol and reject any requests that you aren't sure are coming from a trusted source (that is, twilo). No real need for a pin at all.
This is a huge webpage on how to setup ssl between your web server and twilo. It even has a php example.
http://www.twilio.com/docs/security
If you use PKCS#1 1.5 or 2.0 RSA encryption (view the standards) you will also encrypt a random padding. This means that in transit, the PIN's cannot be compared, as long as the padding is kept secret and is truly random (this is not a salt which should be made public).
As for the database, it would be a good idea to move it out of the normal operations as much as possible. Create a simple service that just checks the PIN after decryption, make sure you don't have buffer overruns etc. on that, and if possible, use a different machine and access rights than the production server. Really test this part well, as the interface is small, it should not be difficult.
If you and the phones are up to it, you might want to try ECC, but that's not for the meek. RSA encrypt normally uses a small public exponent (0x010001 is highly recommended) so it is faster than ECC for the phone. On the server (and during key creation) ECC is much faster. I would not recommend symmetric cryptography (AES/3DES) for this.
Oh, and include the public encryption key in the application (for implicit trust), don't send it over from the server. Keep the private key secret and inaccessible for anything other than the already mentioned service.
The interface you describe sounds secure to me. It's secure enough for ATMs!
Are the encrypted PINs easy to crack? Yes, there's only 10000 possible combinations and a rainbow table can be generated of all the possible encrypted values unless you salt. However that would require access to the encrypted PINs which means the attacker already has a copy of your database.
So really you need to ensure your database server is secure. There's a lot of variables that could make it insecure so it's a big question. Instead you could rely on third-party solutions like Amazon S3 or others and concentrate on coding instead of security. Let them do the hard work!
You should use good quality password salting technique to prevent against hacking passwords. Check the wikipedia article to know more about salting. Salt Article
Related
I've been learning about ways to keep databases for web applications more secure in School and one of the things mentioned was the encryption of data of the user's personal information. Now when I'm looking through examples of web systems I've noticed that it's normally just the password that is hashed, for obvious reasons, but should there be some sort of encryption when it comes storing a user's details such as their address? Is it safe to have these stored in plain text as long as you have measures in place to keep your database secure or should this be encrypted?
Sorry if this is the wrong place to ask but thought I would be able to get a good answer here
Yes, any Personally Identifiable Information (PII) should be encrypted in transit and at rest because it may be used for identity theft. There are recent instances of hackers getting into systems and stealing data that is then potentially sold on eg the Travelex data breach https://www.bbc.co.uk/news/business-51017852. Encrypting the data makes it valueless even if hackers do get into your network.
This is different to password hashing which is a one way mechanism to allow comparison of provided credentials against stored credentials without ever needing to convert the stored value to plaintext. PII data does normally need to be decrypted by the applications that use it.
I am creating a mobile app that uses Google App Engine (python) for the backend. Users sign in with Twitter on the app, and the auth token and secret are passed to the backend (over https) so that the server can authenticate with Twitter and also periodically sync friends and followers in a background task. Because they are used by the background thread, I want to store the information in the datastore so they can be retrieved and used later.
Right now, during development and testing, I just put these in the datastore in plain text. But I'd like to add a little more security by storing it encrypted and decrypting it when its needed. Thank you for any help!
For general account passwords, I use
security.generate_password_hash(raw_password, length=12)
based on how webapp2_extras stores the passwords. But this approach wouldn't allow me to retrieve the data. Is there anything similar that allows for encryption and decryption?
Normally for password storage you would use a unidirectional (One way) encryption technique so that no one can work out what the password is and then take the user supplied values and compare them to the stored values. This way you're never really storing the actual password and it's less likely to be stolen.
What you're looking for is a bidirectional encryption technique where by you provide the value and a key to create an encrypted value and can apply the key to the encrypted value to get the original.
You haven't stated which language you're using so I cannot provide a good example, however I suggest looking at techniques such as AES. Please keep in mind that if you choose an encryption technique with a short key it will be much easier to brute force. Any encryption that is bidirectional is at risk of easier brute force and once the key has been determined ALL passwords are at risk of being decrypted. Most languages have some form of support for AES and similar encryption techniques.
There are many techniques available, some much newer and more secure so do some research and see what you deem 'secure enough'.
Read more here: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
I am assuming the answer is that storing a password in a WEBSQL database on the client side, unencrypted is not safe, but i thought i would ask anyway, the reason I am asking, is I am trying to add a dropbox uploading tool to a web app, but i need the password in plain text in order to access the user's dropbox account, i surely could come up with some foobar way to hash the passwords client side, and unhash them when needed, but if I will be able to unhash them, anyone will be able to do so as well, does anyone have a work around if this is the case?
There is no such thing as 100% secure or safe. The goal of security is to be safe enough. You determine what is the risk, and what is the level of pain you are willing to go through and find the sweet spot.
If you have to get a plain text back from a cypher you have no choice but to use encryption not hashing. Of course you have to have the key somewhere, whether user entered or stored somewhere so the key is vulnerable.
Since this is on a client computer, it may be vulnerable to phishing attacks, social engineering attacks, trojan/keylogger/virus attacks, physical security risks, etc.
storing clear text is a bad idea, but other than that you have to decide what level of pain the users will suffer through.
PKI tokens are a good option if the cost is worth it. otherwise most languages have many various encryption algorithms that can be used effectively.
No, it's not safe to store plaintext passwords, period.
Assuming your users log into your web app with a password, why not use that password to encrypt their (salted) dropbox password? That's still less than satisfactory from a security standpoint, but it's better than nothing.
Using the words "foobar" and "dropbox" in the same paragraph is a clear signal that you're asking for trouble with a home-grown solution. You're asking your users to trust you with the security of their dropbox data, which means you're accepting an awful lot of liability. You're also asking your users to violate one of the fundamental laws of security: Never trust your security to a third party.
The best advice I can offer is to delegate all security-related tasks to an expert, and have that code audited by another expert.
In some project we have very that even our staff is not suppose to have access to. In theory, we have policies to ensure they don't. In practice, we are in Africa and policies don't mean a lot, no matter how strongly you enforce it.
I would like to know is there is a way to encrypt data in your database so:
each user password encrypt and decrypt its own data, and its own data only;
data is decrypted as late as possible in the process to ensure maximum security to the user. Ideally it would be on the client side I guess, but I'd love to hear that it's possible to do some crazy thing I don't know about on the server side.
data is still searchable. Is that even possible?
My first idea was: "if a customer want THAT level of protection, then give him its own hosting on a virtual machine and encrypt the hardrive, then all maintenance must be done with it's allowance".
I can't come up with a fancy strategy just how I've implemented this:
Keep in mind that you have to re-encrypt everything when the user changes his password. I'm using always the same encryption key but the key is encrypted using the user's plaintext password. So I just have to re-encrypt the key. The user's password is stored as a salted hash so nobody can decrypt the key and the data even if he sees the hash.
It works like this:
User enters his plaintext password
Create salted hash
Check if the generated hash matches the one in the database (authentication)
If yes, then decrypt the key for the data using his plaintext password
Decrypt stored data using the key
This won't give you 100% security but improves it.
Here are a few things I can think of:
You should encrypt data stored when it is stored in the and when you read it back. Use a solution that integrates at an RDBMS level rather than the data layer.
For the transport of data to and from the application, use HTTPS web services.
If you have a Desktop application, do not store any data and log files etc locally.
If it is a web app, make the app HTTPS as well.
Security is bound to make the app a little slower than using plain data, but that's the price you will pay.
It really depends on what and where (on the client or server) you are doing with the data.
For example, your application don't need to know the password itself to verify it during authentification. Best practice for this use case is to store only a cryptographic hash (e.g. sha1) of the password and a random salt. That is sufficient to verify it, but giving only the hash and salt, it would take a nearly infinte amount of time to figure out the plain password.
Encryption can be a soultion if you have to exchange data over unsecure channels. But keep in mind that in order to process the data you have to decrypt them. So if de- and encryption is done on the same machine, it's rather pointless. And if decryption is required it doesn't matter how late you are going to do it, because of the key must be given anyway.
You can use encryption to secure the communication between the server and the client, for example. You could even generate messages on the server that only the client will be able to read and vice versa using asynchronous encryption. So once the message was generated on the server and encrypted using the client's public key even the server isn't able to read the message anymore, because of the private key only the client knows is required for the decryption.
What you denfinetly can not solve by cryptography is, when you have data on the server, that the server should be able to read in order to process them but human users unrestricted with priveleages to this server shouldn't.
We have a requirement from customer that if someone gets access to the database, all data that includes personal information should be encrypted, so that when they do select calls, they shouldn't be able to see anything in clear text. Now this isn't any problem for Strings, but what about bytearrays? (that can potentially be quite huge (several 100mb))
When you do a select call, you get gibberish anyways. Is it possible for a hacker to somehow read the bytes and get the sensitive information without knowing how the structure of the object it is mapped against is?
Because if that is the case, then I guess we should encrypt those bytes, even if they can potentially be quite huge. (I am guessing adding encryption will make them even bigger)
This seems to be an approach that will give you little additional security for a large amount of effort, not to mention the extra headaches of debugging queries using encrypted data!
If protecting the data in the database is the goal, I recommend encrypting the database as a whole, and using authentication and access control to ensure data is provided only to your program and no unauthorized access. If the database falls into wrong hands, under this system, the evil scoundrels will have to figure out the username/password or other credentials use to authenticate a legitimate user to gain access. Typically this means either a brute force search, or reverse engineering your code (if the credentials are stored in your program - not such a good idea.)
If you encrypt all the data in the database on a row-by-row level, so that it comes to your program encrypted, it must still be decrypted by your program. The secret key can be found by reverse engineering your code.
So, I hope you see, encrypting each returned result set will be complex to implement, yet is no more secure than using readily available solutions (database file encryption and authentication/access control).
EDIT: I've written this with a local database in mind, since the OP talks about the attacker getting hold of the database. On the other hand, if you are using a remote database server, which is physically secure, a protocol with transport layer encryption, e.g. HTTPS will give you what you want. An attacker in the middle will not be able to make any sense of the data going between your program and the database. It's also transparent - your data access code does not need to change at all.
First of all, encryption won't normally increase size, except possibly to the next multiple of the encryption algorithm's block size (e.g., 128 bit boundary).
Second, yes, if the data is left in the clear, an attacker can probably make sense of at least quite a bit of it fairly quickly.
Third, the big problem with all of this (as with most cryptology) is key storage and distribution. At some point you have to decrypt the data, and (often) the easiest form of attack is to find a way to retrieve that key. Your two main choices are to require the user to enter a key, or to have some sort of protected storage (e.g., a smart card) to store the key, and use smartcard readers on the client computers.
Depending on the database you're using, it may be able to handle a lot of this for you. A fair number have some sort of row-level or even column-level encryption to help comply with privacy requirements (e.g. Sarbanes-Oxley in the US).