i am working in a startup company providing software services and recently we have set security standards for encryption. For hashing, the standards that were set was we should use SHA-512 or SHA-256.
For Java, We are considering using Bcrypt of Spring or Argon2. Actually reading their documentations, can't find any information if their underlying algorithms are using SHA-512 or SHA-256 or something else?
or are these both outdated algorithms for hashing and we should use something else?
Can anyone help me on this?
When you are referring to "security standards for encryption" I'm assuming that you are talking about storing passwords, so I'll write about using "SHA", "BCRYPT" and "ARGON2I" to secure passwords, I'll mention disadvantages and vantages between "SHA" and "BCRYPT/ARGON2I" algorithms.
None of the "SHA" algorithms are designed for hashing passwords, they are fast algorithms making them easy to compute.
For example: They are used for cryptocurrency encryption because they don't encrypt a single word or a short combination of characters, they encrypt a large file containing the currency making it hard to guess the hashed file.
In the other hand hashing methods like "BCRYPT" and "ARGON2I" are made for storing passwords, one of the key differences from "SHA" is that they are slow algorithms meaning that in order to hash a word it can take a full second if configured correctly (because of the cost of the hash).
This means that the time the attacker has to invest in hashing the word that is trying to compare is the same as the word that is hashed (in this example I'm giving 1sec per hash). This dramatically increase up the time that the attacker has to invest in order to match the hashes, making your stored files more secure.
If you want to hash passwords it's recommended to implement slow hashing algorithms, if you want to hash long files it's recommended to implement fast hashing algorithms.
Responding to your last question... Neither "BCRYPT" nor "ARGON2I" are outdated hashing methods. BCRYPT is more reliable in my opinion because of the time it has been on the market, it was released in 1999 and the developers that programmed it are updating it until nowadays. The same happens with "ARGON2I" but it's a newer algorithm (it was created on 2015) meaning that it isn't as tested as "BCRYPT", however it is said that "ARGON2I" is more secure than "BCRYPT" but vulnerabilities could be found forthcoming.
If you notice that I'm speaking about "ARGON2I" and not "ARGON2" is because there are various versions of the algorithm and "ARGON2I" is the one designed for hashing passwords.
These are the links from both slow algorithms Wikipedia and source code in GitHub.
Wikipedia of bcrypt
Wikipedia of argon2
GitHub of bcrypt
GitHub of argon2
Related
I am using the open source MobSF security framework to scan my Swift project's source code and its dependences for vulnerabilities. Most things look pretty good however I'm concerned that it is showing me that encryption algorithms (MD5, SHA1) in my dependencies are not sufficiently secure.
What would be standard practice for solving this? I made sure to pull the latest branches for most of these but they seem to insist on using outdated algos. I am reluctant to go in and have to change their source code only to have it wiped out each time I rebuild the Podfile.
First, it depends on why they're using these algorithms. For certain uses, there are no security problems with MD5 or SHA-1, and they may be necessary for compatibility with existing standards or backward compatibility.
As an example, PBKDF2 is perfectly secure using SHA-1 as its hash. It doesn't require a very strong hash function to maintain its own security. It's even secure using MD5. Switching to SHA-2 with PBKDF2 doesn't improve security, it's just "security hygiene," which is "avoid algorithms that have known problems even being in your code, even if they cause no problems in your particular use case." Security hygiene is a good practice, but it's not the same thing as security.
For other use cases, the security of the hash function is critical. If a framework is authenticating arbitrary messages using MD5, that's completely broken. Don't take this answer to suggest that algorithms don't matter. They do! But not in every use case. And if you want to decode credit card swipe transactions, you're probably going to need DES to be in your code, which is horribly broken, but you're still going to need it because that's how magnetic stripes are encrypted. It doesn't make your framework "insecure."
When you say "but they seem to insist on using outdated algos," I assume you mean you opened a PR and they rejected it, in which case I assume they have a good reason (such as backward compatibility when there is no actual security problem). If you haven't, then obviously the first step would be to open a PR.
That said, if you want to change this because you feel there is an actual security problem that they will not resolve, or purely for hygiene, then with CocoaPods you would fork the project, modify it, and point to your own version using the source attribute to the pod keyword.
Maintaining a cryptography framework myself, I often get bug reports that are simply wrong from developers using these scanners. Make sure that you know what the scanner is telling you and how to evaluate the findings. False positives are extremely common with these. These tools are useful, but you need to have some expertise to read their reports.
How to secure SWF files and Action script 3 code ?
mostly while communicating with server side program ?
Guide me which is most secure encoding encryption or normal way encryption ? :
I really don't know about these encryption stuffs and all correct me if am wrong.
Use a code obfuscator. There are several of them on the internet. The good ones cost money. If you have enough uberness, make your own.
Sockets are a tough nut to crack. Also you can use sha or other security protocols, but nothing is 100% safe. Nothing.
No such as thing as "most secure". It depends on your needs and nature of your application.
If you don't know about security in IT in general, then don't use Flash, a highly insecure language for whatever you seek to do. Else, expect to be intercepted and either make it not worth the "hacker"'s time to hack apart your stuff, or use lossy techniques.
I want to add that you avoid storing important information in the client side,so access tokens, secret passwords or other things that must remain secret one method to avoid this is to call a script on the server side. As mentioned in the other response you can use obfuscation but I noticed that is problematic if you have the project split in libraries.
I have a lot of short strings to decrypt in my app and decryption speed is critical.
Currently I am experimenting with RNCryptor but find its default settings a bit slow for my use case. Otherwise it is an awesome framework :-)
Encryption will be done only once and hence its performance is not important.
I am fine giving up protection for speed as I just want to have a very basic encryption in place.
Which RNCryptor settings would you recommend using to encrypt and decrypt in order to accomplish the fastest decryption performance? A short code sample would be great!
Again, I am fine with very basic encryption protection for the current use case.
The lion's share of time in RNCryptor are in the calls to PBKDF2. It iterates 20,000 times (10,000 for each key). While it may get a little faster in upcoming versions of RNCryptor, password-based encryption will always be slow. This is a security feature; it's slow on purpose. It's designed to be slow in a way that frustrates attackers while having acceptable impact on the most common use cases.
You can dramatically improve performance by using the key-based, rather than password-based, methods. The key-based methods have no injected slowdowns. This would be my recommended approach if possible. Generate two random 256-bits keys rather than using a password.
You can potentially set the number of PBKDF2 iterations to a smaller number (and that's necessary when dealing with JavaScript for instance), but the faster you make key generation, the worse your security is going to be.
There are a number of ways to modify the format to improve performance for your use case, but it's very easy to mess it up and significantly hurt security. As #Zaph notes, I would either do a lot of study or engage an expert before modifying any security framework.
There isn't much you can do, RNCryptor is not slow.
AES128 will be a little faster than AES256 -- or not depending on the platform.
There is a large cost in the setup so that is a place to possibly make things faster. One possibility is combining the strings.
If you could make all the strings a multiple of block size you could use one setup, ECB mode and the partial CCryptor functions. Note, ECB mode will degrade security especially on short strings. Setup with CCCryptorCreate()and decrypt with the short padded strings with CCCryptorUpdate().
Another thing to consider is TinyCrypt. "The first point of TinyCrypt is to both compress and encrypt your file VERY quickly." I rarely suggest other than AES and using non-mainstream cyphers is dodgy at best--but you stated you were willing to tradeoff security for speed.
I recently read about decompilation of iOS apps and I'm now really concerned about it. As stated in the following posts (#1 and #2) it is possible to decompile an iOS which is distributed to the App Store. This can be done with jailbreak and I think with copying the app from memory to hdd. With some tools it is possible to
read out strings (strings tools)
dump the header files
reverse engineer to assembly code
It seems NOT to be possible to reverse engineer to Cocoa code.
As security is a feature of the software I create, I want to prevent bad users from reconstructing my security functions (encryption with key or log in to websites). So I came up with the following questions:
Can someone reconstruct my saving and encryption or login methods with assembly? I mean can he understand what exactly is going on (what is saved to which path at which time, which key is used etc., with what credentials is a login to which website performed)? I have no assembly understanding it looks like the matrix for me...
How can I securly use NSStrings which cannot be read out with strings or read in assembly? I know one can do obfuscation of strings - but this is still not secure, isn't it?
This is a problem that people have been chasing for years, and any sufficiently-motivated person with skills will be able to find ways to find out whatever information you don't want them to find out, if that information is ever stored on a device.
Without jailbreaking, it's possible to disassemble apps by using the purchased or downloaded binary. This is static inspection and is facilitated with standard disassembly tools. Although you need to have a tool which is good enough to add symbols from the linker and understand method calls sufficiently to be able to tease out what's going on. If you want to get a feel for how this works, check out hopper, it's a really good disassembly/reverse-engineering tool.
Specifically to your secure log in question, you have a bigger problem if you have a motivated attacker: system-based man-in-the-middle attacks. In this case, the attacker can shim out the networking code used by your system and see anything which is sent via standard networking. Therefore, you can't depend on being able to send any form of unencrypted data into a "secure" pipe at the OS or library level and expect it not to be seen. At a minimum you'll need to encrypt before getting the data into the pipe (i.e. you can't depend on sending any plain text to standard SSL libraries). You can compile your own set of SSL libraries and link them directly in to your App, which means you don't get any system performance and security enhancements over time, but you can manually upgrade your SSL libraries as necessary. You could also create your own encryption, but that's fraught with potential issues, since motivated hackers might find it easier to attack your wire protocol at that point (publicly-tested protocols like SSL are usually more secure than what you can throw together yourself, unless you are a particularly gifted developer with years of security/encryption experience).
However, all of this assumes that your attacker is sufficiently motivated. If you remove the low-hanging fruit, you may be able to prevent a casual hacker from making a simple attempt at figuring out your system. Some things to avoid:
storing plain-text encryption keys for either side of the encryption
storing keys in specifically named resources (a file named serverkey.text or a key stored in a plist with a name which contains key are both classics)
avoid simple passwords wherever possible
But, most important is creating systems where the keys (if any) stored in the application themselves are useless without information the user has to enter themselves (directly, or indirectly through systems such as OAUTH). The server should not trust the client for any important operation without having had some interaction with a user who can be trusted.
Apple's Keychain provides a good place to store authentication tokens, such as the ones retrieved during an OAUTH sequence. The API is a bit hard to work with, but the system is solid.
In the end, the problem is that no matter what you do, you're just upping the ante on the amount of work that it takes to defeat your measures. The attacker gets to control all of the important parts of the equation, so they will eventually defeat anything on the device. You are going to need to decide how much effort to put into securing the client, vs securing the server and monitoring for abuse. Since the attacker holds all of the cards on the device, your better approach is going to be methods that can be implemented on the server to enhance your goals.
I was hoping to get a recommendation on the best way to store a database encryption key for HIPAA compliance as well as Amazon S3 file storage security. I have been searching stackoverflow and googling in general, but I just can't quite get a solid grasp whether what I'm specifically doing is sufficient. I don't want something I'm doing differently from prescribed methods to make my app insecure.
Currently, I have a Rails app that uses the gem attr_encrypted to encrypt sensitive patient identifying data in the database like name, ssn, address etc. I also store things like images of signatures and patient pictures in Amazon S3 uses server side encryption. I know I shouldn't hardcode the database encryption key in the application or in any file that might get verion controlled, but can I keep it in heroku's env config variables? How are those secured? How separate are they from the database (as in, if someone gets into heroku and steals a copy of the database, are the ENV variables vulnerable somehow as well?)? I currently keep my AWS keys in heroku env variables, is that safe? Also, what is the best pass phrase to use for the encryption? I am currently using 2 sentences from a random page in a book I have.
Please let me know if I'm being terribly naive with any of the procedures I've outlined, and I apologize in advance if I am asking naive questions. I'd like to be HIPAA compliant, but in addition I'd like piece of mind that I've gone beyond what HIPAA requires since from what I understand, HIPAA compliance does not always = actually secure.
Thanks everyone!
(This is more of a comment, but it was too long to be added as a comment):
#Eli: HIPAA doesn't actually mandate any specific technology. Which is good because it's a law and not as mutable as shifting technology.
#OP: Here is a whitepaper on building HIPAA-complaint apps on AWS. It should give you some good ideas. But Eli is correct in that you'll need to contact Heroku for their compliance information. Or you might just be better off migrating off of Heroku at this point. In my experience, it's a good prototyping platform, but it's easy (and expensive) to start bumping into it's limitations when dealing with production environments.
#FrederickCheung: Reading directly from /dev/random will block if there isn't enough entropy. It's generally recommended to use /dev/urandom or an actual crypto library if pseudo-random isn't good enough.