5 ms·

As a real practical question out of curiosity: how would you design their system differently so unauthorized people having only your hard drives couldn't get an

by imrehg 15y ago

As a real practical question out of curiosity: how would you design their system differently so unauthorized people having only your hard drives couldn't get any data at all?

forgotAgain 15y ago
If the hardware is in hand then I don't see any practical way to protect the information. The only way that works is to not store the information in cloud servers.
- jonah 15y ago
  The only way that works is to not store the information in cloud servers. Where would your servers be safe? Colo? No. In your basement? No? In another country? Possibly, depends. At HavenCo? Maybe.
  - forgotAgain 15y ago
    I was talking from a user's perspective. As a user your data is safer on your local machine than on a cloud server run by who knows who.
pavel_lishin 15y ago
You could always hash the e-mails, although this would make resetting your password impossible. How much data do Facebook's OAuth tokens contain? By looking at one, can you tell that it's linked to Pavel Lishin's account?
- discover 15y ago
  Would splitting the data in half work? I mean literally cutting the data sent into two pieces and each piece entering a different database server in a different country. Then, when requested, pulling both pieces and sending them to users who patch them together with client side script...?
  - pbh 15y ago
    There has been some academic work on this (CIDR'05), but I'm not sure if it has been used in practice. http://ilpubs.stanford.edu/659/ http://ilpubs.stanford.edu/659/
    - pavel_lishin 15y ago
      Thanks, printed it off, will try to read on the train.
      - InnocentB 15y ago
        Sounds like a good use case for Instapaper :P
        protomyth 15y ago
        Might not want the FBI to know he read the article if they come back for a "followup visit"
  - pavel_lishin 15y ago
    So, basically a RAID array? You'd have to have a fair amount of redundancy, to make sure that if your Dystopiastan server gets taken down, your servers in Freedomia and Libertania have enough data to continue serving your users. (And yet you can't have so much redundancy that a single country could rebuild your database if they take enough servers.) Not to mention, latency issues would be a problem.
- ynniv 15y ago
  Yes, OAuth tokens contain the Facebook id of the user. It is unlikely that this would matter since session tokens (required for most permissions) expire after an hour (no reason to store those) and sessionless tokens are per-application not per-user. However, obtaining the application credentials for Instapaper would allow you to limited access to a user account on behalf of Instapaper. Since the credentials for doing this are per-application, Instapaper would likely store your Facebook id in their database. Given a Facebook id, you can easily see the account name by visiting https://graph.facebook.com/$id https://graph.facebook.com/$id.
- danielsoneg 15y ago
  >You could always hash the e-mails, although this would make resetting your password impossible. Not really - everywhere I've gone has asked me for my email to send me my password. Same principle as with passwords: enter your email, we hash it, if it matches a hashed email in the DB, we send a 'reset' email to the address you entered.
kijinbear 15y ago
Full-disk encryption. You enter the key whenever the system needs to be rebooted. I know at least one company that does this with all of their US-hosted servers.
- boucher 15y ago
  And not servers hosted in other countries? I'd be very curious to hear the thought process behind that decision.
  - kragen 15y ago
    Perhaps all their employees live in the US, so they consider it not worth the trouble to fly someone to Indonesia whenever a server in Jakarta needs rebooting.
    - nske 15y ago
      It's not necessary that they have physical access in order to do that, though.
- esrauch 15y ago
  This would only be protection against thieves that steal your harddrives, if the US government had your drives they can legally compel you to divulge your password.
  - danssig 15y ago
    There are systems you can use to defeat this. One password decrypts the drive, another wipes it.
    - deleted 15y ago
      [deleted]
    - esrauch 15y ago
      If there was a court order for the decryption keys for your drive and you gave them a key that destroyed it, you would almost certainly be found guilty of deliberately destroying evidence.
rosser 15y ago
On my collocated server, I use encrypted LVM for all of my filesystems (except /boot, of course). On my next hardware upgrade cycle, I'm going to install a USB gyroscope (inside the chassis, using one of the front USB headers) and write a daemon that will issue a `umount -lfa && halt -n` if the box is ever moved. Note that this isn't simply to keep prying eyes off my data; I live near an overdue earthquake fault line. When it does finally give, I should have a (slightly) better chance of the machine coming through intact.
- rcthompson 15y ago
  Shouldn't you throw in a `sync` before halting?
  - Nick_C 15y ago
    If you do that, I would change && to ; on the basis you want the halt no matter whether the umount succeeds or not.

by imrehg 15y ago

As a real practical question out of curiosity: how would you design their system differently so unauthorized people having only your hard drives couldn't get any data at all?

forgotAgain 15y ago

If the hardware is in hand then I don't see any practical way to protect the information. The only way that works is to not store the information in cloud servers.

jonah 15y ago
The only way that works is to not store the information in cloud servers. Where would your servers be safe? Colo? No. In your basement? No? In another country? Possibly, depends. At HavenCo? Maybe.
- forgotAgain 15y ago
  I was talking from a user's perspective. As a user your data is safer on your local machine than on a cloud server run by who knows who.

pavel_lishin 15y ago

You could always hash the e-mails, although this would make resetting your password impossible. How much data do Facebook's OAuth tokens contain? By looking at one, can you tell that it's linked to Pavel Lishin's account?

discover 15y ago
Would splitting the data in half work? I mean literally cutting the data sent into two pieces and each piece entering a different database server in a different country. Then, when requested, pulling both pieces and sending them to users who patch them together with client side script...?
- pbh 15y ago
  There has been some academic work on this (CIDR'05), but I'm not sure if it has been used in practice. http://ilpubs.stanford.edu/659/ http://ilpubs.stanford.edu/659/
  - pavel_lishin 15y ago
    Thanks, printed it off, will try to read on the train.
    - InnocentB 15y ago
      Sounds like a good use case for Instapaper :P
      - protomyth 15y ago
        Might not want the FBI to know he read the article if they come back for a "followup visit"
- pavel_lishin 15y ago
  So, basically a RAID array? You'd have to have a fair amount of redundancy, to make sure that if your Dystopiastan server gets taken down, your servers in Freedomia and Libertania have enough data to continue serving your users. (And yet you can't have so much redundancy that a single country could rebuild your database if they take enough servers.) Not to mention, latency issues would be a problem.
ynniv 15y ago
Yes, OAuth tokens contain the Facebook id of the user. It is unlikely that this would matter since session tokens (required for most permissions) expire after an hour (no reason to store those) and sessionless tokens are per-application not per-user. However, obtaining the application credentials for Instapaper would allow you to limited access to a user account on behalf of Instapaper. Since the credentials for doing this are per-application, Instapaper would likely store your Facebook id in their database. Given a Facebook id, you can easily see the account name by visiting https://graph.facebook.com/$id https://graph.facebook.com/$id.
danielsoneg 15y ago
>You could always hash the e-mails, although this would make resetting your password impossible. Not really - everywhere I've gone has asked me for my email to send me my password. Same principle as with passwords: enter your email, we hash it, if it matches a hashed email in the DB, we send a 'reset' email to the address you entered.

kijinbear 15y ago

Full-disk encryption. You enter the key whenever the system needs to be rebooted. I know at least one company that does this with all of their US-hosted servers.

boucher 15y ago
And not servers hosted in other countries? I'd be very curious to hear the thought process behind that decision.
- kragen 15y ago
  Perhaps all their employees live in the US, so they consider it not worth the trouble to fly someone to Indonesia whenever a server in Jakarta needs rebooting.
  - nske 15y ago
    It's not necessary that they have physical access in order to do that, though.
esrauch 15y ago
This would only be protection against thieves that steal your harddrives, if the US government had your drives they can legally compel you to divulge your password.
- danssig 15y ago
  There are systems you can use to defeat this. One password decrypts the drive, another wipes it.
  - deleted 15y ago
    [deleted]
  - esrauch 15y ago
    If there was a court order for the decryption keys for your drive and you gave them a key that destroyed it, you would almost certainly be found guilty of deliberately destroying evidence.

rosser 15y ago

On my collocated server, I use encrypted LVM for all of my filesystems (except /boot, of course). On my next hardware upgrade cycle, I'm going to install a USB gyroscope (inside the chassis, using one of the front USB headers) and write a daemon that will issue a `umount -lfa && halt -n` if the box is ever moved. Note that this isn't simply to keep prying eyes off my data; I live near an overdue earthquake fault line. When it does finally give, I should have a (slightly) better chance of the machine coming through intact.

rcthompson 15y ago
Shouldn't you throw in a `sync` before halting?
- Nick_C 15y ago
  If you do that, I would change && to ; on the basis you want the halt no matter whether the umount succeeds or not.