5 ms·

If you have any kind of staging/testing server I'd highly recommend using your production backups to populate that on a regular basis. That way you test your ne

If you have any kind of staging/testing server I'd highly recommend using your production backups to populate that on a regular basis. That way you test your new code releases with real data, and you know that your backups work.

wmoxam 18y ago
This is what I do. Using Amazon's EC2+EBS makes it dead simple. Every time we test a release I setup a staging env (from scratch) and restore the latest EBS snapshot. That way I'm testing both the database backup and that I've kept all of the server images up to date as well. It doesn't take much time either (about 30 minutes) and is done weekly.
tptacek 18y ago
Quick cherry bomb to lob into this conversation: populating insecure test servers with sensitive production data is a classic web app company security failure. It probably doesn't matter for you, but be cognizant of it.
- Tangurena 18y ago
  I agree. One of our big financial clients has an automated tool to scrub such data, but then they have social security numbers as well as lots of other juicy financial data. So they're worried about all sorts of stuff that most of us never ponder as a business risk. One of the santizing steps is to replace all passwords with a set value, such as six/seven of a letter (like "A") or a number (eg, "111111"). Another sanitizing step is to scramble names and addresses. Usually the first letter gets preserved, and the rest gets replaced with a hash (say, MD5 it, and then base64 it and truncate it to length, that way it preserves max lengths and typical size of words). example: John Doe, 1313 Mockingbird Lane might get munged into Jiqw Dyh, 1313 Masdfasdfas Lfds We just have username/password/address/phone, so all we do is set all passwords to a default value (all emails, if any, get set to mine), and munge up telephone numbers. Later this year I'll cobble up a better sanitizer. Our parent company has to worry about GLBA compliance, but our little apps don't "collect" enough information to worry about GLBA at this time.
  - timf 18y ago
    > replace all passwords with a set value They're storing passwords directly and not hashes? Wish I could ask you which company so I could avoid them...
    - timf 18y ago
      Downvote all you want but I would seriously like to know. http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...
      - Tangurena 18y ago
        I guess I wasn't clear enough. The "user" tables get updated so that the password used to log in will be "111111" or such, and that means all the salts and hashes will be the same value.
        timf 18y ago
        Oh OK, sorry for the tangent.
    - inerte 18y ago
      Who said they're storing passwords in plain text? They could be paranoid enough to remove hashed passwords. If you know what makes the hash you can reproduce. If it's a database with financial information, I can see crackers devoting time to do this, making their rainbow tables and botnets or whatever to guess the passwords.
    - sho 18y ago
      I don't understand this obsession about only storing hashes, as if that's the primary critical issue with site security. There are plenty of reasons to store the plaintext, and in a well secured database I really don't think it is much of an issue. Or as I heard someone say once, "If you can break into my database, and show me how, I will quite literally give you a million dollars". Off the top of my head, here's a couple of very good reasons to store plaintext: - password recoverability: if the user knows they can recover the password, they're more likely to use a more complex one - flexibility with authentication: to use something like HTTP Digest Auth, you need the plaintext to be able to hash it with a one-time nonce And like many will no doubt point out, hashing it isn't all THAT secure anyway. If it's not a very strong hash, or there's enough information to reset it somehow, they can get what they want anyway. Not to mention that if your database has been cracked they probably have everything they want anyway - why even bother logging in? I just don't get it. Sure, defence in depth is the best strategy and everyone should practise it whereever possible. But whether the password is stored hashed or not is not the lynchpin security issue many make it out to be, IMO.

wmoxam 18y ago

This is what I do. Using Amazon's EC2+EBS makes it dead simple. Every time we test a release I setup a staging env (from scratch) and restore the latest EBS snapshot. That way I'm testing both the database backup and that I've kept all of the server images up to date as well. It doesn't take much time either (about 30 minutes) and is done weekly.

tptacek 18y ago

Quick cherry bomb to lob into this conversation: populating insecure test servers with sensitive production data is a classic web app company security failure. It probably doesn't matter for you, but be cognizant of it.

Tangurena 18y ago
I agree. One of our big financial clients has an automated tool to scrub such data, but then they have social security numbers as well as lots of other juicy financial data. So they're worried about all sorts of stuff that most of us never ponder as a business risk. One of the santizing steps is to replace all passwords with a set value, such as six/seven of a letter (like "A") or a number (eg, "111111"). Another sanitizing step is to scramble names and addresses. Usually the first letter gets preserved, and the rest gets replaced with a hash (say, MD5 it, and then base64 it and truncate it to length, that way it preserves max lengths and typical size of words). example: John Doe, 1313 Mockingbird Lane might get munged into Jiqw Dyh, 1313 Masdfasdfas Lfds We just have username/password/address/phone, so all we do is set all passwords to a default value (all emails, if any, get set to mine), and munge up telephone numbers. Later this year I'll cobble up a better sanitizer. Our parent company has to worry about GLBA compliance, but our little apps don't "collect" enough information to worry about GLBA at this time.
- timf 18y ago
  > replace all passwords with a set value They're storing passwords directly and not hashes? Wish I could ask you which company so I could avoid them...
  - timf 18y ago
    Downvote all you want but I would seriously like to know. http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...
    - Tangurena 18y ago
      I guess I wasn't clear enough. The "user" tables get updated so that the password used to log in will be "111111" or such, and that means all the salts and hashes will be the same value.
      - timf 18y ago
        Oh OK, sorry for the tangent.
  - inerte 18y ago
    Who said they're storing passwords in plain text? They could be paranoid enough to remove hashed passwords. If you know what makes the hash you can reproduce. If it's a database with financial information, I can see crackers devoting time to do this, making their rainbow tables and botnets or whatever to guess the passwords.
  - sho 18y ago
    I don't understand this obsession about only storing hashes, as if that's the primary critical issue with site security. There are plenty of reasons to store the plaintext, and in a well secured database I really don't think it is much of an issue. Or as I heard someone say once, "If you can break into my database, and show me how, I will quite literally give you a million dollars". Off the top of my head, here's a couple of very good reasons to store plaintext: - password recoverability: if the user knows they can recover the password, they're more likely to use a more complex one - flexibility with authentication: to use something like HTTP Digest Auth, you need the plaintext to be able to hash it with a one-time nonce And like many will no doubt point out, hashing it isn't all THAT secure anyway. If it's not a very strong hash, or there's enough information to reset it somehow, they can get what they want anyway. Not to mention that if your database has been cracked they probably have everything they want anyway - why even bother logging in? I just don't get it. Sure, defence in depth is the best strategy and everyone should practise it whereever possible. But whether the password is stored hashed or not is not the lynchpin security issue many make it out to be, IMO.