101–110 of 133 posts
Earlier quoted context omitted.
not true for all customers - I needed to send them nothing of the kind (in the US)
This was dedicated servers (root servers they call them) - and I'm from Europe.
they also don't ask business customers (might not be true for all countries) if they supply certain details about their business.
Earlier quoted context omitted.
What if attacker infects unencrypted part used for booting? Do you have protection against that? It's relatively easy on Linux, where /boot is usually not encrypted.
The trick is putting all important data in the encrypted part. The unencrypted part must be reconstructable in an automated manner. If you are paranoid and you assume that all unplanned reboots are attacks, then you can reconstruct the unencrypted part every time. Tools like Chef make this relatively easy.
Earlier quoted context omitted.
They are a provider of hosted dedicated servers, colo and virtual machines (with or without server management services), based in Germany.
They're really inexpensive, which explains their niche popularity...
If I were a mean dude who hacked into some prominent site, the first thing I would do is submit a link to HN that points to a malicious "article" and laugh as malware gets thrust into thousands of computers.
Earlier quoted context omitted.
So "yes" – what would you do if you had, say, several hundred (or several thousand) servers?
If I have that many servers then I can assume I have a large budget for security, right? I would make a password entering automation system. Ensure that that system is dead-simple and secured to death. It must run no other services, firewalled to death even from the intranet, physically secured in a cage, and must be off most of the time. It is only to be turned on when booting a system, and turning it on not only re…
Properly hard problem, as you've pointed out.
Earlier quoted context omitted.
https://www.pcisecuritystandards.org/pdfs/pci_dss_glossary_v... seems to list Blowfish as an approved standard as far as the PCI standards group is concerned.
Thanks for that link. I think that means blowfish is approved as a standard encryption algorithm, but that doesn't mean it is approved as a standard way to store passwords. From http://security.stackexchange.com/questions/4781/do-any-secu... , I gather this: bcrypt is neither a NIST or FIPs standard, but PBKDF2 is. > For any business required to comply with U.S. NIST or FIPS standards, bcrypt is not a valid option. C…
The info in the mail regarding the safety of credit card info contradicts with the linked FAQ. FAQ: Bank details are encrypted (two-way) in the database. However, it cannot be excluded that the attacker/s have also been able to obtain access to the key. Mail: With credit cards, only the last three digits of the card number, the card type and the expiry date are saved in our systems. All other card data is saved solel…
Earlier quoted context omitted.
Thanks for that link. I think that means blowfish is approved as a standard encryption algorithm, but that doesn't mean it is approved as a standard way to store passwords. From http://security.stackexchange.com/questions/4781/do-any-secu... , I gather this: bcrypt is neither a NIST or FIPs standard, but PBKDF2 is. > For any business required to comply with U.S. NIST or FIPS standards, bcrypt is not a valid option. C…
But it is also likewise plausible to say that you're using a newer technology that's understood by experts in the industry to be even better than those certified some time ago.
The difference is that one way your lawyers won't even need to make an argument and the other way they might have to make an argument.
Earlier quoted context omitted.
The trick is putting all important data in the encrypted part. The unencrypted part must be reconstructable in an automated manner. If you are paranoid and you assume that all unplanned reboots are attacks, then you can reconstruct the unencrypted part every time. Tools like Chef make this relatively easy.
Wow, do you actually reconstruct /boot on every unplanned reboot, yourself?
Earlier quoted context omitted.
The trick is putting all important data in the encrypted part. The unencrypted part must be reconstructable in an automated manner. If you are paranoid and you assume that all unplanned reboots are attacks, then you can reconstruct the unencrypted part every time. Tools like Chef make this relatively easy.
The kernel lives on /boot, and could be subverted to lie about its uptime to convince you that there was no unplanned reboot. This is the same methodology I use, and I think about these attacks a lot. There is no good/cheap way to verify a remote execution environment right now with commodity hardware. :/