I'm writing a Ruby application that will need to handle a user's enterprise password. I'd like to minimize the time the password is in memory to reduce the likelihood of the password being exposed.
In a native language, I would directly erase the data. In C#, I would use the SecureString class. In Java, I'd use char[]. But the best that I can find for Ruby is an old feature request that seems dead.
What is the standard for securely storing and erasing passwords from memory in Ruby? Is there a class that does this? A coding pattern similar to the char[] of Java?
A ruby issue exists for 5 years now (5741), regarding secure erasure of secrets from memory. That issue contains also some links which explain, why it is a good thing to erase passwords from memory. Lately MacOs did have an issue with FileVault2, because the password was stored within memory.
One possible solution shown within issue 5741 is:
pass = ""
$stdin.sysread(256, pass) # assuming a line-buffered terminal
io = StringIO.new("\0" * pass.bytesize)
io.read(pass.bytesize, pass)
It seems to work with ruby 2.3.1p112, but I can't promise it.
Related
everyone. I'm learning Laravel and I'm in the start of my journey. I was learning about encryption and decryption in Laravel today and then this thought came into my mind. Could be a stupid one but I want to know my answers.
Let's say I make a database which stores sensitive information about users and I encrypt all the data before storing into the database, let's just say using the Encrypt class of Laravel. Now my questions:
If someone steals that database and luckily finds out that this information was encrypted using techniques provided by Laravel or any other technique. Can't that person descript that all data using the same decryption technique that was used to encrypt it. If this can be done, then what's the point of doing this encryption?
If that can be done then how can we make sure that our data is actually encrypted and is safe even if someone steals it?
Thank you guys!
I encrypted my data and then decrypted it and want my answer that how that encrypted data is even safe.
You might want to read up on the basics of encryption.
The common approach is that the technique by which you encrypt should be as open as possible - because the more people look at the algorithm, the less likely there might be bugs.
However, even if the algorithm is public, the key is not. Only people who have the key can decrypt properly encrypted data. This is true of the AES algorithm Laravel uses too.
The mathematics are complicated, but essentially the length of the key determines the amount of computer resources required to break the encryption.
THe real-world example is that everyone knows how door locks work. There are millions of locks that all work in the same way - but only people who have a key can open the door.
So, if an attacker steals your database, they cannot read your content unless they also have the key, as long as the key length is sufficient.
If someone steals that database and luckily finds out that this information was encrypted using techniques provided by Laravel or any other technique. Can't that person descript that all data using the same decryption technique that was used to encrypt it. If this can be done, then what's the point of doing this encryption?
If someone steals that database they will still need a decryption key to decrypt (thats why strong passwords are recommended) so even if they bruteforce it will become almost impossible to decrypt.
The way you’re asking if encrypt and decrypt is easy then i think you’re asking some encryption like base64.
With AES bruteforcing their way in becomes difficult. In laravel encrypt or crypt class it uses AES-256-CBC which is pretty good at that.
Then there is Hash library they are one way encryption techniques which uses bcrypt it can only be verified and not decrypt you have to run all combinations for lines everytime to brute force. Unlike md5 which gives same encryted string every time.
This question already has an answer here:
Secure erasing of password from memory in Ruby
(1 answer)
Closed 2 years ago.
I have a use case where I need to dispose of some data the very moment I don't need it anymore, for security reasons.
I am writing a server in Ruby that deals with logins and passwords. I use BCrypt to store passwords in my database. My server receives the password, makes a bcrypt hash out of it, and then doesn't use the original password anymore.
I know of a kind of cyberattacks that involves stealing data right from RAM, and I am concerned that an attacker might steal a user's password in raw string form in the period of time that the password is still in memory. I am not sure if simply using password_in_string_form = nil would be enough.
I want to nullify the variable that holds the user's password the moment I am done with it. By nullify I mean something akin to using /dev/null to fill something with zeroes. The end goal is irreversible destruction of data.
I am not sure if simply using password_in_string_form = nil would be enough.
No, it would not be enough. The object might or might not be garbage collected immediately, and even if it was, that does not cause the contents to be erased from memory.
However, unless they have been frozen, Ruby strings are mutable. Thus, as long as you do not freeze the password string, you can replace its contents with zeroes, or random characters, or whatever before you let go of it. In particular, this should work, subject a few provisos, covered later:
(0 ... password_in_string_form.length).each do |i|
password_in_string_form[i] = ' '
end
But care needs to be exercised, for this approach, which may seem more idomatic, does not work:
# SURPRISE! This does not reliably remove the password from memory!
password_in_string_form.replace(' ' * password_in_string_form.length)
Rather than updating the target string's contents in-place, replace() releases the contents to Ruby's internal allocator (which does not modify them), and chooses a strategy for the new contents based on details of the replacement.
The difference in effect between those two approaches should be a big warning flag for you, however. Ruby is a pretty high-level language. It gives you a lot of leverage, but at the cost of control over fine details, such as whether and how long data are retained in memory.
And that brings me to the provisos. Here are the main ones:
As you handle the password string, you must take care to avoid making copies of it or of any part of it, or else to capture all the copies and trash them, too. That will take some discipline and attention to detail, because it is very easy to make such copies.
Trashing the password string itself may not be enough to achieve your objective. You also need to trash any other copies of password in memory, such as from upstream of isolating the password string. If yours is a web application, for instance, that would include the contents of the HTTP request in which the password was delivered to your application, and probably more strings derived from it than just the isolated password string. Similar applies to other kinds of applications.
passwords may not be the only thing you need to protect. If an adversary is in a position where they can steal passwords from the host machine's memory, then they are also in position to steal the sensitive data that users access after logging in.
For these and other reasons, if the security requirements for your server dictate that in-memory copies of user passwords be destroyed as soon as they are no longer needed, then (pure) Ruby may not be an appropriate implementation language.
On the other hand, if an adversary obtains sufficient access to scrape passwords from memory / swap, then it's probably game over already. At minimum, they will have access to everything your application can access. That doesn't make the passwords altogether moot, but you should take it into consideration in your evaluation of how much effort to devote to this issue.
This is not possible in Ruby.
You will have to write some code specific to each implementation (Opal, TruffleRuby, JRuby, Rubinius, MRuby, YARV, etc.) to ensure that. Depending on the implementation, it may not even be possible to do inside of the managed memory of the implementation at all, without having a separate piece of memory that you manage yourself.
I.e. you will probably need to have some tiny piece of native code that manages its own tiny piece of native memory and injects it into your Ruby program.
I am Developing an onpremise solution for a client without any control and internet connection on the machine.
The solution is to be monetized based on number of allowed requests(REST API calls) for a bought license. So currently we store the request count in an encrypted file on the file system itself. But this solution is not perfect as the file can be copied somewhere and then replaced when the requests quota is over. Also if the file is deleted then there's manual intervention needed from support.
I'm looking for a solution to store the state/data in binary and update it runtime (consider usage count that updates in binary itself)
Looking for a better approach.
Also binary should start from the previous stored State
Is there a way to do it?
P.S. I know writing to binary won't solve the issue but I think it'll increase the difficulty by increasing number of permutation and combinations for places where the state can be stored and since it's not a common knowledge that you can change the executable that would be the last place to look for the state if someone's trying to mess with the system (security by obscurity)
Is there a way to do it?
No.
(At least no official, portable way. Of course you can modify a binary and change e.g. the data or BSS segment, but this is hard, OS-dependent and does not solve your problem as it has the same problem like an external file: You can just keep the original executable and start over with that one. Some things simply cannot be solved technically.)
If your rest API is within your control and is the part that you are monetizing surely this is the point at which you would be filtering the licensed perhaps some kind of certificate authentication or key to the API and then you can keep then count on the API side that you can control and then it wont matter if it is in a flat file or a DB etc, because you control it.
Here is a solution to what you are trying to do (not to writing to the executable which) that will defeat casual copying of files.
A possible approach is to regularly write the request count and the current system time to file. This file does not even have to be encrypted - you just need to generate a hash of the data (eg using SHA2) and sign it with a private key then append to the file.
Then when you (re)start the service read and verify the file using your public key and check that it has not been too long since the time that was written to the file. Note that some initial file will have to be written on installation and your service will need to be running continually - only allowing for brief restarts. You also would probably verify that the time is not in the future as this would indicate an attempt to circumvent the system.
Of course this approach has problems such as the client fiddling with the system time or even debugging your code to find the private key and probably others. Hopefully these are hard enough to act as a deterrent. Also if the service or system is shut down for an extended period of time then some sort of manual intervention would be required.
There are many operating system and programs that hash passwords for authentication.
Even though they can encrypt the password in many different ways and save it
why do they save the hash of them?
Is the only reason to that question that encrypting them may cause in breaking and decrypting them or there are other reasons?
Thanks for answering in advance
User credentials (≈passwords) are among the most valuable assets stored in an application. They are a prime target for attackers, and as a developer, you want to protect them the best you can.
The principle of defense in depth (and common sense) indicates that the more layers of protection you can put around something, the more secure it will be. So as you also mentioned, the purpose of hashing passwords is that even if there is a breach, an attacker still can't get hold of actual user credentials.
The problem with encryption is always key management. If passwords were stored encrypted, they would need to be decrypted (or the received password encrypted with the same key) to be able to verify a password. For this, the application would need to have access to the key. But that negates the purpose of encryption, an attacker would also have access to the key in case of a breach. (Public key cryptography could make it somewhat more difficult, but essentially the same problem of key management would still persist.)
So in short, only storing salted hashes with an algorithm that is slow enough to prevent brute-force attacks (like PBKDF2 or Bcrypt) is both the simplest and the most secure. (Also note that plain salted hashes are not good enough anymore.)
Think of the need: You define your new password, and then every time you log-in the entered password is hashed and checked against the stored value. This is the simplest and most secure policy to handle this (since no one will be able to re-construct your password from the stored value). Moreover, imagine that you use the same password in several systems. If Windows would enable (regardless how hard it would be) to re-construct your password from what is stored in a Windows system, there would be (quite many) people that would blame Microsoft for security breach on other system (which could derivate into legal actions).
To summarize, simplicity and commercially logical approach.
Well, actually it's for security reason.
Hash functions are usually not revertibles, so even if someone finds out the hashes it would be really difficult for him to find which password generated that hash value.
Obviously you can try with a dictionary attack or a brute force one, trying to find out the password which generated the hash but it could take a very long time.
Consider that you have a Database with user and their passowrd, take note that a lot of people use the very same password everywhere.
Now immagine if a cracker manages to crack into your DB and finds all the password written clearly. That would be a disaster.
I am creating a Ruby On Rails website, and for one part it needs to be dynamic so that (sorta) trusted users can make parts of the website work differently. For this, I need a scripting language. In a sort of similar project in ASP.Net, I wrote my own scripting language/DSL. I can not use that source code(written at work) though, and I don't want to make another scripting language if I don't have to.
So, what choices do I have? The scripting must be locked down and not be able to crash my server or anything. I'd really like if I could use Ruby as the scripting language, but it's not strictly necessary. Also, this scripting part will be called on almost every request for the website, sometimes more than once. So, speed is a factor.
I looked at the RubyLuaBridge but it is Alpha status and seems dead.
What choices for a scripting language do I have in a Ruby project?
Also, I will have full control over where this project is deployed(root access), so there are no real limits..
There's also Rufus-lua though it's at version 0.1.0...
What about JRuby? You can use java implementation of many scripting language, such as javascript, scheme etc
Well, since it hasn't been suggested yet, there's Locking Ruby In The Safe as described by the Pickaxe book. This allows you to use Ruby as the language without significant slowdown AFAIK.
This technique is intended to allow safe sandboxing of untrusted Ruby code and bug fixes and discussions are directed toward keeping it that way, but infinite loops and some other things still allow malicious users to peg the CPU. (e.g. this discussion maybe.)
What I don't know is how you return data that is inherently safe to use from outside the safe thread. A singleton object (for instance) can mimic whatever class and then do something dangerous when any method is called in the returning thread. I'm still googling around about it. (The Ruby Programming Language says that level 4 "Prevents metaprogramming methods" which would allow you to safely verify the class of a returned object, which I suppose would make results safe to use.)
Barring that, it might not be hard (*snrk*) to implement a Lisp-1 with dynamic scope since you already have a garbage collector.