 me here. I'm very excited to be here. And as I said, my name is Melissa Wanish and I'm the founder of Ruby Thursday, a tutorial site for junior Rails developers. And yes, that includes weekly, mostly weekly tutorials. And today I'm going to be talking about encryption pitfalls and workarounds. So just a little bit about me. I'm an actor, turned developer, so that's been fun putting the two back together for the tutorials. And I'm the mother of a really awesome 13-month-old little girl named Julia. Yay, programming moms. All right. So what are we talking about today? We're talking about how encryption works, a little definition there, some considerations when you're looking to encrypt your data, current tools that you may want to use. I'm going to narrow it down to two open source gems and talk about those. And then some challenges and workarounds for encryption at scale. And I will share a story with you about how I deployed it for a client. So first we're just going to talk about how encryption works, a little definition, how you can make it even stronger, and then look at some example code. So what is encryption anyway? Encryption is a modern form of cryptography that allows a user to hide information from others. So it's a code. Way back you would take symbols or other letters and replace them for the information you wanted to hide from others. Well, now we have super-duper computers that will make complex algorithms for us. And they'll take that plain text and make it into a ciphertext that you need a special key in order to decrypt it. So you can make this key even stronger by adding a salt to it, like you would a password. So it's a password on top of a password. Or you could use an initialization vector or nonce, a number used once. And that would be for an individual record. Say, like a first name, you would have an individual key just to unlock the first name. So let's walk through a little bit of an example using Ruby and modules from Ruby on Rails. So you have the salt. You can use the module secure random that makes this lovely key here, this salt. And the length is usually about 32 characters. And then you can have the key. Active support has a key generator. So you're putting that salt on top of it. And then you have active support. And this is creating an instance of it. And then you would use that to encrypt your data. So I'm encrypting my secret data. And you have all these lovely letters and numbers and characters. And that is what you would be saving to your database instead of the thing you wanted encrypted. All right. So there's considerations with this. And you're probably guessing a few of them as I'm talking about keys and storing long, you know, phrases. And so there's lots to consider. First, what you need to encrypt. All right. What personal information needs to be encrypted. The effects on search and uniqueness. Those become more difficult to implement. And then your speed and storage needs. A little hint. You're going to need more. All right. So first let's talk about what to encrypt. I'm sure most of you are aware of GDPR. You've gotten all these emails in your unbox saying all the terms of service have changed. And so this is directly from their site defining personal data as information relating to identified or identifiable people. And that includes their online identifier, which is their email address. So now if we're thinking about an email address as a personal identifier, we need to, you know, secure that. We need to encrypt it. But that's also what we generally use to log in our users. So more on that more. And one way you could do this is with a single key. All right. And that's for your whole app. All right. And you could see that could be a security risk because if somebody got that single key, they could unlock everything in your database. Or as I mentioned before, you could have a unique key for each record that not. And that is the most secure way to encrypt your data. So you have to think about this risk assessment. All right. What is it that you're actually, you know, trying to hide? And the maintainer of ATTR encrypted responded to someone on a GitHub issue complaining that they couldn't search with their gem. And he said, well, do you really need to query this data or do you need it to be really secure? And, you know, that's the case. Like, you know, if it's a bank account number, yeah, you'd want it to be really secure if it's, you know, their personal physical address. But maybe something as fluid and changeable as an email address, maybe you can take a little bit more risk with that. You still need to consider encrypting it. Speed and storage. Your needs will go up. You need more resources. It takes time to encrypt and decrypt. It's another process on top of what you're already doing. And your storage needs will go up. You're going to be saving more things and more columns in order to refer to that encrypted data. So we're going to talk about two tools that I narrowed down for today. You can go on to rubygems.org and look up encryption and you can see lots more solutions and, you know, maybe something that fits more into your use case. But for today, I'm just talking about ATTR encrypted and cryptkeeper. So ATTR encrypted is the gold standard. It is the most widely used by far and has lots and lots of options, maybe more options than what you need. But if you need that stamp of security, yes, we are the most secure. If you have a banking app, that's probably what you need. You want to go with ATTR encrypted. Now, for my client's case, which I'll tell you about more just coming up, we went with cryptkeeper. And the pluses are that it was a simpler integration, more simplified, and they have an option for search built in. But you may not want to use it. It didn't work for me right out of the box. And it's not as widely used. It's well maintained. But it's not ad security. It uses that single key for the entire app, as opposed to the not. So here's my story issues with scale. So in there, read me. Cryptkeeper has a solution for search because what my client needed is that their customers are companies. And the employees of those companies are the users of the site. And so when she started to sell to bigger companies with whole teams devoted to cyber security, they made the requirement that we encrypt the personal data. Now, we were only collecting first name, last name, and their email address. And you may think, well, why didn't you just use a username? You know, that we wouldn't need to encrypt. They could log in with that. It just wasn't a good solution for us as we were getting this information from all kinds of different companies. So I looked into encrypting with Cryptkeeper. And at first I used the search by plain text. And, of course, it worked great on staging. But then I put it to the app, and we had about 15,000 users at that time. Not a crazy amount. But it did make everything come to a complete stop when I tried to log in. And so I rolled it all back. And, you know, I could have thrown more resources at it, but I didn't think that was really the appropriate response. So, and they do have an option where you could scope it, but in logging in, that just doesn't work. So I reached out to the maintainers, and in big capital letters, they said, this is an unsanctioned workaround. And so Joshua Priddle gave me this code, unsanctioned, but it works for uniqueness and for search. And basically, we're creating a hash that would be unique that you could search for to associate with the user. And you could take that email, you'd use the hash, and then you rewrite find by email, which is the active record method. You're rewriting that, so it's a little tricky. But we're using that hash to find the user and then log them in. And that's what worked for us. So, you know, it's a, you know, a balancing act with the risk, but also trying to really protect your users. So I hope I haven't scared you off of encryption. I hope you get started to looking at it in this never ending story and journey of cyber security. So thank you guys so much. If you I'm an old school, I like email. So email me at Melissa at rubythursday.com. Thank you.