ORK3
ORK3 copied to clipboard
Encrypt Personal Data
Encrypt mundane names, and other personal data.
I'm not sure there is a good way to do this that will actually give us real security instead of just theatre, but in the spirit of this bug, we might want to switch to HTTPS.
I'll see if I can brainstorm some sort of way to do this effectively still though. On Sep 27, 2014 12:06 PM, "amtgard" [email protected] wrote:
Encrypt mundane names, and other personal data.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73.
I was going to generate a private key on the server, and use it to encrypt and decrypt personal data.
On Sat, Sep 27, 2014 at 6:12 PM, Derric Atzrott [email protected] wrote:
I'm not sure there is a good way to do this that will actually give us real security instead of just theatre, but in the spirit of this bug, we might want to switch to HTTPS.
I'll see if I can brainstorm some sort of way to do this effectively still though. On Sep 27, 2014 12:06 PM, "amtgard" [email protected] wrote:
Encrypt mundane names, and other personal data.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57068883.
If an attacker has compromised your server wouldn't they just grab the data and the key though? It doesn't seem like you gain much.
For the record, I'm all about encrypting everything you can, I'm just not sure that this is likely to do any good against an attack.
Though I guess it may do something against a SQL injection attack assuming you don't keep the key in the database as well. On Sep 27, 2014 8:25 PM, "amtgard" [email protected] wrote:
I was going to generate a private key on the server, and use it to encrypt and decrypt personal data.
On Sat, Sep 27, 2014 at 6:12 PM, Derric Atzrott [email protected]
wrote:
I'm not sure there is a good way to do this that will actually give us real security instead of just theatre, but in the spirit of this bug, we might want to switch to HTTPS.
I'll see if I can brainstorm some sort of way to do this effectively still though. On Sep 27, 2014 12:06 PM, "amtgard" [email protected] wrote:
Encrypt mundane names, and other personal data.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57068883.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57070294.
About every two weeks, I run mysqldump on the database, gzip the output and then publish the data for general consumption. It is much easier to encrypt the data, publish it generally, then move a specific private key to a few individuals.
On Sun, Sep 28, 2014 at 1:45 AM, Derric Atzrott [email protected] wrote:
If an attacker has compromised your server wouldn't they just grab the data and the key though? It doesn't seem like you gain much.
For the record, I'm all about encrypting everything you can, I'm just not sure that this is likely to do any good against an attack.
Though I guess it may do something against a SQL injection attack assuming you don't keep the key in the database as well. On Sep 27, 2014 8:25 PM, "amtgard" [email protected] wrote:
I was going to generate a private key on the server, and use it to encrypt and decrypt personal data.
On Sat, Sep 27, 2014 at 6:12 PM, Derric Atzrott < [email protected]>
wrote:
I'm not sure there is a good way to do this that will actually give us real security instead of just theatre, but in the spirit of this bug, we might want to switch to HTTPS.
I'll see if I can brainstorm some sort of way to do this effectively still though. On Sep 27, 2014 12:06 PM, "amtgard" [email protected] wrote:
Encrypt mundane names, and other personal data.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57068883.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57070294.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57076873.
Now that does seem like a reasonable reason to encrypt the data. This would have my support.
Something to keep in mind if planning to use AES with Mycrypt in PHP is that Mcrypt doesn't support AES, but rather Rijndael which AES is based on. Rijndael-128 == AES-256. This is counter intuitive because in in AES the number after the dash refers to the keysize but in Rijndael it refers to the block size.
On Mon, Sep 29, 2014 at 7:57 AM, amtgard [email protected] wrote:
About every two weeks, I run mysqldump on the database, gzip the output and then publish the data for general consumption. It is much easier to encrypt the data, publish it generally, then move a specific private key to a few individuals.
On Sun, Sep 28, 2014 at 1:45 AM, Derric Atzrott [email protected]
wrote:
If an attacker has compromised your server wouldn't they just grab the data and the key though? It doesn't seem like you gain much.
For the record, I'm all about encrypting everything you can, I'm just not sure that this is likely to do any good against an attack.
Though I guess it may do something against a SQL injection attack assuming you don't keep the key in the database as well. On Sep 27, 2014 8:25 PM, "amtgard" [email protected] wrote:
I was going to generate a private key on the server, and use it to encrypt and decrypt personal data.
On Sat, Sep 27, 2014 at 6:12 PM, Derric Atzrott < [email protected]>
wrote:
I'm not sure there is a good way to do this that will actually give us real security instead of just theatre, but in the spirit of this bug, we might want to switch to HTTPS.
I'll see if I can brainstorm some sort of way to do this effectively still though. On Sep 27, 2014 12:06 PM, "amtgard" [email protected] wrote:
Encrypt mundane names, and other personal data.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57068883.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57070294.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57076873.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57150200.
I was going to use SHA 512 with a 2048 bit key. I have a little crypto library based on the openssl_* PHP functions that I use for this.
On Mon, Sep 29, 2014 at 8:46 AM, Derric Atzrott [email protected] wrote:
Now that does seem like a reasonable reason to encrypt the data. This would have my support.
Something to keep in mind if planning to use AES with Mycrypt in PHP is that Mcrypt doesn't support AES, but rather Rijndael which AES is based on. Rijndael-128 == AES-256. This is counter intuitive because in in AES the number after the dash refers to the keysize but in Rijndael it refers to the block size.
On Mon, Sep 29, 2014 at 7:57 AM, amtgard [email protected] wrote:
About every two weeks, I run mysqldump on the database, gzip the output and then publish the data for general consumption. It is much easier to encrypt the data, publish it generally, then move a specific private key to a few individuals.
On Sun, Sep 28, 2014 at 1:45 AM, Derric Atzrott < [email protected]>
wrote:
If an attacker has compromised your server wouldn't they just grab the data and the key though? It doesn't seem like you gain much.
For the record, I'm all about encrypting everything you can, I'm just not sure that this is likely to do any good against an attack.
Though I guess it may do something against a SQL injection attack assuming you don't keep the key in the database as well. On Sep 27, 2014 8:25 PM, "amtgard" [email protected] wrote:
I was going to generate a private key on the server, and use it to encrypt and decrypt personal data.
On Sat, Sep 27, 2014 at 6:12 PM, Derric Atzrott < [email protected]>
wrote:
I'm not sure there is a good way to do this that will actually give us real security instead of just theatre, but in the spirit of this bug, we might want to switch to HTTPS.
I'll see if I can brainstorm some sort of way to do this effectively still though. On Sep 27, 2014 12:06 PM, "amtgard" [email protected] wrote:
Encrypt mundane names, and other personal data.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57068883.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57070294.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57076873.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57150200.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57162535.
Sounds good to me (though isn't SHA512 a hashing algorithm? How do you plan to read the data within the application?).
On Mon, Sep 29, 2014 at 10:03 AM, amtgard [email protected] wrote:
I was going to use SHA 512 with a 2048 bit key. I have a little crypto library based on the openssl_* PHP functions that I use for this.
On Mon, Sep 29, 2014 at 8:46 AM, Derric Atzrott [email protected]
wrote:
Now that does seem like a reasonable reason to encrypt the data. This would have my support.
Something to keep in mind if planning to use AES with Mycrypt in PHP is that Mcrypt doesn't support AES, but rather Rijndael which AES is based on. Rijndael-128 == AES-256. This is counter intuitive because in in AES the number after the dash refers to the keysize but in Rijndael it refers to the block size.
On Mon, Sep 29, 2014 at 7:57 AM, amtgard [email protected] wrote:
About every two weeks, I run mysqldump on the database, gzip the output and then publish the data for general consumption. It is much easier to encrypt the data, publish it generally, then move a specific private key to a few individuals.
On Sun, Sep 28, 2014 at 1:45 AM, Derric Atzrott < [email protected]>
wrote:
If an attacker has compromised your server wouldn't they just grab the data and the key though? It doesn't seem like you gain much.
For the record, I'm all about encrypting everything you can, I'm just not sure that this is likely to do any good against an attack.
Though I guess it may do something against a SQL injection attack assuming you don't keep the key in the database as well. On Sep 27, 2014 8:25 PM, "amtgard" [email protected] wrote:
I was going to generate a private key on the server, and use it to encrypt and decrypt personal data.
On Sat, Sep 27, 2014 at 6:12 PM, Derric Atzrott < [email protected]>
wrote:
I'm not sure there is a good way to do this that will actually give us real security instead of just theatre, but in the spirit of this bug, we might want to switch to HTTPS.
I'll see if I can brainstorm some sort of way to do this effectively still though. On Sep 27, 2014 12:06 PM, "amtgard" [email protected] wrote:
Encrypt mundane names, and other personal data.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57068883.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57070294.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57076873.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57150200.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57162535.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57165011.
Yeah, sorry. That's just for generating the private key. I wrote a little crypto-helper library a couple years back, and now it's like a little black box "Here Be Crypto".
On Mon, Sep 29, 2014 at 9:07 AM, Derric Atzrott [email protected] wrote:
Sounds good to me (though isn't SHA512 a hashing algorithm? How do you plan to read the data within the application?).
On Mon, Sep 29, 2014 at 10:03 AM, amtgard [email protected] wrote:
I was going to use SHA 512 with a 2048 bit key. I have a little crypto library based on the openssl_* PHP functions that I use for this.
On Mon, Sep 29, 2014 at 8:46 AM, Derric Atzrott < [email protected]>
wrote:
Now that does seem like a reasonable reason to encrypt the data. This would have my support.
Something to keep in mind if planning to use AES with Mycrypt in PHP is that Mcrypt doesn't support AES, but rather Rijndael which AES is based on. Rijndael-128 == AES-256. This is counter intuitive because in in AES the number after the dash refers to the keysize but in Rijndael it refers to the block size.
On Mon, Sep 29, 2014 at 7:57 AM, amtgard [email protected] wrote:
About every two weeks, I run mysqldump on the database, gzip the output and then publish the data for general consumption. It is much easier to encrypt the data, publish it generally, then move a specific private key to a few individuals.
On Sun, Sep 28, 2014 at 1:45 AM, Derric Atzrott < [email protected]>
wrote:
If an attacker has compromised your server wouldn't they just grab the data and the key though? It doesn't seem like you gain much.
For the record, I'm all about encrypting everything you can, I'm just not sure that this is likely to do any good against an attack.
Though I guess it may do something against a SQL injection attack assuming you don't keep the key in the database as well. On Sep 27, 2014 8:25 PM, "amtgard" [email protected] wrote:
I was going to generate a private key on the server, and use it to encrypt and decrypt personal data.
On Sat, Sep 27, 2014 at 6:12 PM, Derric Atzrott < [email protected]>
wrote:
I'm not sure there is a good way to do this that will actually give us real security instead of just theatre, but in the spirit of this bug, we might want to switch to HTTPS.
I'll see if I can brainstorm some sort of way to do this effectively still though. On Sep 27, 2014 12:06 PM, "amtgard" [email protected]
wrote:
Encrypt mundane names, and other personal data.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73.
— Reply to this email directly or view it on GitHub < https://github.com/amtgard/ORK3/issues/73#issuecomment-57068883>.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57070294.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57076873.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57150200.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57162535.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57165011.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-57165607.
In progress. I have acquired an SSL cert. Once https is live, I will push all traffic to HTTPS.
Since we basically have to publish our private data to make backups useful, there's no point in encrypting that actual database.
So glad that HTTPS is going to be used for everything!
On Thu, Jun 11, 2015 at 5:11 PM, amtgard [email protected] wrote:
In progress. I have acquired an SSL cert. Once https is live, I will push all traffic to HTTPS.
Since we basically have to publish our private data to make backups useful, there's no point in encrypting that actual database.
— Reply to this email directly or view it on GitHub https://github.com/amtgard/ORK3/issues/73#issuecomment-111278509.