Comment Non-paternity events (Score 2) 61
I wonder how they will track non-paternity. People with random fathers pop up everywhere in studies like this, at a rate of something like 10-15%.
Comment Tape is still king (Score 2) 326
Any company that I've ever worked for that had money to spend did tape backups and stored them in a vault offsite. Tapes get verified as they're written, and don't have parts that fail like hard drives do. They have a 30-year shelf life, and you'll always be able to find a way to read them in the future. Go to ebay, buy a used LTO3 or LTO4 drive, (400GB and 800GB uncompressed, respectively). Tapes are about $25/ea for LTO3. Then put a backup somewhere safe.
Comment Re:Been there, done that (Score 1) 1034
Pretty sure that rock and roll didn't make guys unable to get laid.
Comment Gnupg (Score 1) 198
Open source? Check. Multi-user? Check. Secure? Only as secure as the box it's on, and the boxes that people use to access it, just like everything else. Linux based? Check.
Gnupg and a flat text file.
Comment As a FreeBSD desktop user (Score 1) 487
I moved from Linux to FreeBSD on the desktop something like 10 years ago. The same arguments apply as used to apply in the Linux vs. Windows debate. FreeBSD is more secure than Linux (but is that because it's less of a target?) Linux has better Flash support (with its attendant security holes.) FreeBSD has the ports system and ZFS though, and the system is cleaner, better integrated, easier to maintain, and I simply like it better. Use whatever OS you want for whatever you use it for. For me FreeBSD beats Linux any day.
Comment Already have this in ZFS (Score 1) 189
You can already do this with ZFS. It's called L2ARC.
Comment It's not the fax, it's paper. (Score 1) 835
It's not the fax machine that dies hard, it's the universe of paper documents that dies hard. What simpler, more reliable, more secure, and more point-to-point mechanism is there for transferring a piece of paper from one place to another?
Comment Just use FreeBSD (Score 1) 123
Linux users growing frustrated at the increasingly superior feature set of FreeBSD can take heart that FreeBSD is also open source, and runs all of your favorite software. The adjustment necessary is roughly that of moving from one Linux distribution to another.
Comment It took this long to figure this out? (Score 1) 434
It took this long for people to figure this out? Did network sniffers go out of style or something?
Comment For me it's GPL vs. BSD (Score 1) 215
GPL isn't compatible with some code because GPL introduces additional restrictions, which some licenses (Mozilla, CDDL) prohibit. Whether this makes GPL more free or less free is debatable, but BSD-like licenses avoid this. Hence some cool stuff (clang! ZFS!) can't cross-pollinate with software under the GPL, which is too bad.
Comment Patent litigation (Score 1) 245
It's a nice thought, but with all the crazy patent litigation going around, why would moneyed corporations put themselves at risk? Too many vultures out there.
Comment Re:Wake me when they build it into the hard disk (Score 1) 386
What you seem to be describing is file-level deduplication, which is not what is being described here.
Comment Re:What I'm doing this fall... (Score 1) 611
Great, you'll have a frankenstein pony, which doesn't exist yet. You know what a flamewar is though, so you must have some sort of credibility. You're certainly buzzword compliant. Nice score on that post.
Time machine over NFS over SSH? I assume you know what that entails. Wait, no I don't. ZFS over FUSE? Sounds spiffy, maybe you could put another layer of abstraction in there somewhere to make things more reliable.
For real backup needs, tape is still king. LTO4 can write 120MB/s, twice that if the data is compressible, and has a 30 year shelf life. We're talking about cheap and easy though.. Well guess what? Nothing's changed since this came up last week. Choose your cheap storage option and take your backups offline if you want them to be safer.
Comment Guards! (Score 1) 828
Nothing like real live human beings to watch over things. Nothing else has a hope against the creative, motivated attacker.
Submission + - 8 Ways To Make Software Hacker-Proof, CrackProof (ssware.com)
G. Himangi writes: "8 Ways To Make Your Software Hacker-Proof and Crack-Proof: Writing Effective License Checking Code And Designing Effective Licenses With CryptoLicensing
CryptoLicensing uses the latest military strength, state-of-the-art cryptographic technology to generate secure and unbreakable license codes to ensure that your software and intellectual property is protected. Cryptographic licenses are unbreakable even when using brute force computing power. Furthermore, since the licenses can only be generated using the private key (which only you possess), this means that it is impossible for a hacker to develop a 'keygen' (key generator) for your software. This is an excellent first line of defense. It is upto you to provide the next line of defense. The following are some useful tips and guidelines for designing effective licenses using CryptoLicensing and writing effective license validation code using the CryptoLicensing validation API. The philosophy is simple: to make it as difficult as possible for the hacker to 'crack' your software and cause the hacker to lose interest in your software or not make it worthwhile for him/her.
Check license repeatedly
Instead of checking the license at software startup only, check the license at multiple points of time during your software execution and from multiple places in your code. Do not to use a single license validation routine in your software. Check for a license from different places in your software, but don't call a single license validation routine to do this. This ensures that a hacker cannot bypass your licensing scheme by simply hacking a single piece of code in your software and forces the hacker to locate every piece of license validation code in your program.
Use multiple licensing checking layers
In addition to the normal license validation done every time your software is executed, add another layer which checks for a license when a certain random criteria is met. For example, you can check for a license on the 2nd Monday of each month, or every 63 days, or on the February 29th of a leap year. If a hacker bypasses the normal license checking code, the additional 'guerilla' layer is still present which will check for a license and cause the check to fail.
Use encrypted dlls
Move some important part of your software in a dll and encrypt the dll using a key. When generating licenses using CryptoLicensing, embed this key in your license codes (use the custom user-data feature of CryptoLicensing for this) and decrypt the dll using this key before loading it. This ensures that even if a hacker bypasses licensing checking code, your software will not function correctly since it will not be able to load the encrypted dll file.
Check for the hash of your exe/dll to detect tampering
You can include the hash/checksum of your exe/dll in your license codes generated using CryptoLicensing (use the custom user-data feature of CryptoLicensing for this). When your exe/dll is loaded, you can recalculate the hash of the exe/dll, and compare it with that included in the license code. If different, this means that your exe has been tampered or modified. Similar to license checking, perform this check at multiple points of time and place in your software.
Do not display failures immediately
If a license check fails, note this but do not immediately display to the user that the check has failed. Instead wait for some other part of your software to run and notify the user there. This makes it more difficult for the hacker to locate and bypass your license checking.
Don't use explicit error messages
When notifying the user of a failed license check, don't use explicit and obvious messages such as 'License not valid'. Instead, display a generic failure message and ask the user to contact your support department. He may not know that the cause of the error is a failed license check, and when contacted, you may try to make a sale and convert the illegal user into a licensed user or even catch a hacker if he contacts you.
Crash or fail or output incorrect results when license check fails
In combination with above two, when a license check fails or when you determine that your software has been hacked or your license scheme has been compromised, note this and when your software perform some processing at a later point of time, you can crash your software or output incorrect results. Sometimes, a hacker may also lose interest in your 'buggy' program which does not even display informative error messages!
Embed user information in generated licenses
When generating licenses, embed some data about the user in the license such as the user's name, email or company name (use the custom user-data feature of CryptoLicensing for this). Display this information prominently at multiple places in your software. This is a very effective way to discourage the user from sharing his/her license code with others.
Original Article : http://www.ssware.com/articles/writing-effective-license-checking-code-and-designing-effective-licenses-with-cryptolicensing.htm"
CryptoLicensing uses the latest military strength, state-of-the-art cryptographic technology to generate secure and unbreakable license codes to ensure that your software and intellectual property is protected. Cryptographic licenses are unbreakable even when using brute force computing power. Furthermore, since the licenses can only be generated using the private key (which only you possess), this means that it is impossible for a hacker to develop a 'keygen' (key generator) for your software. This is an excellent first line of defense. It is upto you to provide the next line of defense. The following are some useful tips and guidelines for designing effective licenses using CryptoLicensing and writing effective license validation code using the CryptoLicensing validation API. The philosophy is simple: to make it as difficult as possible for the hacker to 'crack' your software and cause the hacker to lose interest in your software or not make it worthwhile for him/her.
Check license repeatedly
Instead of checking the license at software startup only, check the license at multiple points of time during your software execution and from multiple places in your code. Do not to use a single license validation routine in your software. Check for a license from different places in your software, but don't call a single license validation routine to do this. This ensures that a hacker cannot bypass your licensing scheme by simply hacking a single piece of code in your software and forces the hacker to locate every piece of license validation code in your program.
Use multiple licensing checking layers
In addition to the normal license validation done every time your software is executed, add another layer which checks for a license when a certain random criteria is met. For example, you can check for a license on the 2nd Monday of each month, or every 63 days, or on the February 29th of a leap year. If a hacker bypasses the normal license checking code, the additional 'guerilla' layer is still present which will check for a license and cause the check to fail.
Use encrypted dlls
Move some important part of your software in a dll and encrypt the dll using a key. When generating licenses using CryptoLicensing, embed this key in your license codes (use the custom user-data feature of CryptoLicensing for this) and decrypt the dll using this key before loading it. This ensures that even if a hacker bypasses licensing checking code, your software will not function correctly since it will not be able to load the encrypted dll file.
Check for the hash of your exe/dll to detect tampering
You can include the hash/checksum of your exe/dll in your license codes generated using CryptoLicensing (use the custom user-data feature of CryptoLicensing for this). When your exe/dll is loaded, you can recalculate the hash of the exe/dll, and compare it with that included in the license code. If different, this means that your exe has been tampered or modified. Similar to license checking, perform this check at multiple points of time and place in your software.
Do not display failures immediately
If a license check fails, note this but do not immediately display to the user that the check has failed. Instead wait for some other part of your software to run and notify the user there. This makes it more difficult for the hacker to locate and bypass your license checking.
Don't use explicit error messages
When notifying the user of a failed license check, don't use explicit and obvious messages such as 'License not valid'. Instead, display a generic failure message and ask the user to contact your support department. He may not know that the cause of the error is a failed license check, and when contacted, you may try to make a sale and convert the illegal user into a licensed user or even catch a hacker if he contacts you.
Crash or fail or output incorrect results when license check fails
In combination with above two, when a license check fails or when you determine that your software has been hacked or your license scheme has been compromised, note this and when your software perform some processing at a later point of time, you can crash your software or output incorrect results. Sometimes, a hacker may also lose interest in your 'buggy' program which does not even display informative error messages!
Embed user information in generated licenses
When generating licenses, embed some data about the user in the license such as the user's name, email or company name (use the custom user-data feature of CryptoLicensing for this). Display this information prominently at multiple places in your software. This is a very effective way to discourage the user from sharing his/her license code with others.
Original Article : http://www.ssware.com/articles/writing-effective-license-checking-code-and-designing-effective-licenses-with-cryptolicensing.htm"
