I'm weighing the pros and cons of using "Authentication from Scratch" (as implemented in this Railscast) vs. using Devise.
I'm using a custom datastore, so using Devise isn't as simple as just following the README. It would require writing a custom ORM adaptor, which is far from trivial.
Given all this, the Railscast Auth from scratch seems much easier to implement.
So how secure is it?
Update: I should have pointed out that I'm using Parse.com as my datastore. This means they take care of hashing passwords and constraining uniqueness of usernames.
They both work by using bcrypt to generate a salted hash of the password, the only difference is that devise (by default) uses a higher cost for the hash (i.e. it would take more cpu cycles to brute force it), but of course you could easily add that to the railscast code, so roughly equivalent in that respect.
The railscast version does seem to be vulnerable to timing attacks as just doing == won't give you a constant time compare operation. In a nutshell a timing attack works because a password where the hash was completely wrong would take less time for == to reject than a password where first half of the bytes were correct (and so == had to consider more bytes before bailing). It may seem that any such difference would be erased by noise from variations in network latency and so on but people have mounted real attacks to recover keys using these approaches.
You could obviously borrow the secure compare bit from devise though, but it does go to show that there are non obvious issues involved.
Obviously devise gives you a lot more than just authentication!
That screencast uses the bcrypt-ruby library, which is a Ruby implementation of bcrypt, which is based on the Blowfish cipher. The benefit of bcrypt is that it's computationally expensive to crack a password generated by this system, and that the cost of generating these passwords can be increased as required in order to make it more secure, at the expense of the computation time it would take to generate time.
For more information, check out the BCrypt::Password RDoc.
Related
Let's say I'm building a Facebook clone in Rails
Currently my routes are pretty standard, like
/group/1/post/3
I'd love to make some synthetic ID's using the same numbering scheme that sites like Facebook use. There seem to be two general types of routes
# Only numbers
/group/10101830214008379/post/159476674458072
# Hash / Hex
/group/da295c4b/post/815fe818
Outside of aesthetics -
What are some advantages/disadvantages to using either approach?
Is there a good industry standard or best practice for generating synthetic ids for concepts like users, groups, posts, etc..
What's the best way in Ruby/Rails to generate each of these IDs? I know of SecureRandom.hex but that seems to generate a long hash.
Thanks!
What are some advantages/disadvantages to using either approach?
Using sequential numbers
Advantages: Easy to implement
Disadvantages: Possible vector for attack. See this video for a high-level overview.
Using random numbers
Advantages: Solves the problems outlined in the video re: sequential record attacks
Disadvantages: Since there's only 10 bits of entropy, ID's would have to be much longer if your app grows.
Base 64 (use this instead of hex)
Advantages: 64 bits of entropy means an ID 5 chars long would have 64^5 possible permutations. This allows for comparatively much shorter URLs. Use SecureRandom.urlsafe_base64 for this.
Disadvantages: None, really.
Is there a good industry standard or best practice for generating synthetic ids for concepts like users, groups, posts, etc..
To my knowledge, no. Anything sufficiently random and of sufficient length should be fine. Within your model, you'd want to check if an ID is taken first so you don't have duplicates, but outside of that there's little to worry about.
What's the best way in Ruby/Rails to generate each of these IDs? I know of SecureRandom.hex but that seems to generate a long hash.
Like I said above, I recommend using SecureRandom.urlsafe_base64
What are some advantages/disadvantages to using either approach?
I think that the main advantage is that you can generate a new entity (e.g. a post) without having to rely on a sequential id generation (from the database). This is especially useful for highly concurrent or distributed systems, where you want to be able to create new entries without having to a) do the creation in a sequence or b) without running into conflicts.
Is there a good industry standard or best practice for generating synthetic ids for concepts like users, groups, posts, etc..
UUID is one widely used standard for this.
What's the best way in Ruby/Rails to generate each of these IDs? I know of SecureRandom.hex but that seems to generate a long hash.
SecureRandom.uuid
As a more human friendly and nicer alternative to uuids you could use SecureRandom.urlsafe_base64, which has a higher probability to generate non-unique values though.
Because Spring deprecated the old interface
org.springframework.security.crypto.password.PasswordEncoder;
I looked for alternatives that work with
org.springframework.security.authentication.encoding.PasswordEncoder;
My search points me to: https://stackoverflow.com/a/18678325
I tested bcrypt and I was interested how it works.
The explanation at https://stackoverflow.com/a/6833165 points me to one question.
If $2a$10$ZaDBCZaI59IMdKuBiRdubuMa2h/itIYIwqLHpS1q245ISD90xsjkW contains all information about the type of encoding and the salt and so on, and this is stored in my database why is it save?
If someone has this "hash" he can easily decrypt it with brute force.
Within my previous project I used a SHA encode with a system wide secret salt. In this scenario the hash stole from the database can't easily be decrypted.
So why is bcrypt preferred to a SHA with system wide salt?
2 points:
Bcrypt is designed to resist brute force attacks by having a configurable complexity that makes the process arbitrarily slow. Refer to wikipedia for more details
Using the same hash for all passwords, as your existing system does, may be vulnerable to differential attacks, since each password in the database is known to contain a shared component.
Rails vulnerabilities such as CVE-2013-0155 and CVE-2013-0156 might allow a user to run arbitrary code, constructed from an untrusted source (XML/YAML parameters).
Does using $SAFE=4 (say) prevent such exploits or not? If yes, do Rails devs use such security level? If no, why?
Thanks
Tainted Objects and Protected Operations
Basically, $SAFE levels boil down to protecting an application from tainted data, but the devil is in the details. There's a whole chapter in Programming Ruby that addresses the various levels, and it's worth your time to read it over.
Rails Apps Generally Need Tainted Data
Generally speaking, the average Rails application invites tainted input. The params hash is tainted by definition, and most of your user interactions rely on tainted data. Granted that you can sanitize input or use framework features to prevent mass-assignment vulnerabilities, in most cases your application will still need to interact with user-supplied data to be truly useful.
Security Trade-Offs and Other Considerations
It may or may not be possible to run a Rails application usefully when $SAFE = 4. Quite frankly, I've never seen anyone do it with production code "in the wild." Even if you can, you will likely have to jump through so many hoops to untaint user-supplied data, instantiate ActiveRecord objects, and perform filesystem writes (e.g. logging or file uploads) that it may not be worth the security trade-offs.
You may be better served by using a lower $SAFE level and relying on other security best-practices to achieve your goals. It really just depends on what you're trying to accomplish. As with all security controls, your mileage will definitely vary.
When your whole Rails has $SAFE set to 4, nothing can happen to you. Thus said, your app is crippled to deliver static views only. At least that's my experience from some time ago.
Why should we not store the passwords or keys for encryption in source code for an iPhone App?
Is there any possibility for people to reverse engineer code and find the stored keys? or if the hard code values are stored in a location which is easily accessible?
If you store keys in source code, yes they can be reverse engineered. You can make this even harder by making the key "generated" through a generator function but this is still an extra level of obfuscation. A really motivated attacker can get through that. Another drawback of this approach is that the same key will work on all instances of your application, unless the generator function generates a key deriving from some hardware constants.
Again, you have to do an analysis of how secure you want your application to be and how much effort you want to put into security. Security is always a trade off. It is not worthwhile to spend a lot of effort on security, when the probability or cost of an attack are extremely unlikely.
A more secure approach would be to create a random key and then store it in a secure storage on the device. I am not terribly familiar with the iOS Api and if such functionality is offered. On Windows there is something called DPAPI that provides this, for example.
Anything that gets into users' hands is accessible. Obfuscation of keys does part of the work, but doesn't eliminate the problem completely.
Hi i would like to know best encryption technique for text file encryption and ecryption.
My Scenario:
I have software having two type of users Administartor and Operators. Our requirement is to encrypt text file when Administrator enter data using GUI and save it. That encrypted file would be input for Operator and they just need to select it and use that file. Here file should be automatically decrypt data for further calculation when Operator select those files.
Please help me which encryption/ decryption technique should i use?
A golden rule when doing crypto is to understand that cryptography as a whole it is very difficult.
There are a multitude of different approaches/algorithms to choose from, and no single algorithm/method can be said to be the best one. It all depends on your needs and possibilities to affect application distribution etc.
An example of a potentially problematic situation is that in your scenario the decryption "key" needs to be distributed with the application(s) and might make it insecure. This is generally referred to as the "Key Distribution" problem.
A good place to start reading about crypto is http://en.wikipedia.org/wiki/Cryptography.
As for ready made stuff for Delphi there are a few good packages available:
DEC v5.2 - http://blog.digivendo.com/2008/11/delphi-encryption-compendium-dec-52-for-d2009-released/
DCPCrypt - http://www.cityinthesky.co.uk/cryptography.html
Torry's pages also has a long list of components:
http://www.torry.net/pages.php?id=519
http://www.torry.net/pages.php?id=312
I strongly recommend you use some of the existing implementations and not start to do your own, since creating a secure working crypto algo is very very difficult.
When moving an encryptet message from place/appliction to another, one of the problems you have to consider is where to store the encryption/decryption keys.
As i se your scenario, it seems like it is build in your applications. If so remember to use al sorts of tricks to hide it: Password strings should be split in several bits and onlys appended in a protected memoryspace, that has to be marked as non-pageable (else password could be seen in the pagefile).
The same rules for the content that is unencrypted (the text-file). It's best that it never is saved (even temporaly) unencrypted to disk. If it is saved, the overwrite the date with garbage after use, before deleting it.
Another approch (specialy if you already use compression components), is that the (text) file, can be compressed using a password.
Truthfully, there is no "best" technique. It basically depends on the sensitivity of the data you're trying to protect and the number of people who might access this data. What might be "best" for me might be pure overkill for your project.
In your case, you could use any dual-key encryption method. Or asymmetric key. Basically, the administrator has one key and the operator has the other. The administrator can then encrypt files, but he won't be able to decrypt them again, unless he has an operator key. The operator can decrypt the file and -if need be- encrypt a file that only an administrator can access. (Asymmetrical keys encrypt in both ways.)
There are several solutions that make use of these asymmetrical keys. The one that would be best is the one that you could add to your project in the easiest way while still offering enough protection for your needs.
Building your own asymmetrical key algorithm is possible too, if you're a real Math Wizard. The calculations are complex and involve extremely high prime numbers in most solutions. As K. Sandell said, find a good, existing solution that matches your needs in the best way.