If I want my outside people to send me a file with not-so-sensitive information that isn't very useful to anyone else, I think they should be able to FTP it to me ( or SFTP or SCP or FTP with SSL if pedantic IT people were so inclined). Instead of X saying " you can't have an ftp server up because it's a security hole", the IT person should say "I'll set up a secure FTP server instead and they can send it there".
I've worked with MySQL replication for about three years and I'd have to say that feature isn't quite done. Some of the most annoying features:
- Manual cleanup of binary change files is sometimes required.
- Databases in "slave" mode can still be updated by local applications; you can't configure them to only log changes from the "master" database.
- Automated master-slave role-switching requires you to write some code.
- The whole "master/slave" terminology. I know it's meant as just computer-speak and the MySQL team is European, but I work in America; it can be offensive in some situations.
MySQL clustering is also only available for a few of the OSs regular MySQL supports; it's not a universal option for all platforms.
1) MOVEit DMZ with Secure Messaging (http://www.standardnetworks.com/moveitdmz) Many companies (and especially company HR departments) buy this web-based product so that they have an encrypted NOT-EMAIL channel to send secure messages.
2) If you don't mind the administrative hassle, SMIME/PGP-encrypted email will also protect you.
PGP is used in secure file transfer; SMIME revenge
on
PGP & GPG
·
· Score: 2, Interesting
"I can't say I ever found any PGP product good for any application. It was way too complicated and just not what was needed."
PGP is big in the secure file transfer worlds of banking, insurance and the like. It's quite common to "PGP" a file and then send it via FTP or SSH.
Someone else mentioned S/MIME encryption. I have two things to say about that:
#1: An analogy: PGP is to S/MIME as SSH is to SSL. The first technologies are designed for individuals to each trust each other; the latter technologies are designed to rely on a trusted third party (specifically, a CA).
#2: Despite not-wide-use in email, S/MIME is having its revenge in the form of the AS/x protocols, most commonly AS/2. This protocol is widely used in retail, distribution and pharmas and uses S/MIME encryption to both send files and receive cryptographically secure receipts. (Drop me a line at jonathan.lampe@standardnetworks.com if you want to chat about this further; I'm looking for some beta testers for a related application!)
How do I know? Before the U.S. Post Office looked at our web-based secure file transfer and messaging product (MOVEit DMZ), they required us to pass this requirement.
Among the interesting bits: to meet full compliance we added an option that allows our administrators to add a "skip repetative navigation" link to the top of the page; this specifically allows audio readers to skip directly to the unique content on the page.
"...in contrast to the existing AES implementations that have not been through an evaluation, we plan to get our implementation evaluated to meet FIPS guidelines and requirements."
First, thanks for answering my question.
Believe me - I noticed the lack of FIPS validation too. In fact, my company (Standard Networks - http://www.standardnetworks.com/ was more or less forced to develop an FIPS 140-2 validated AES implementation ("MOVEit Crypto" - http://www.standardnetworks.com/uploads/media/MOVE it-Crypto-FIPS-140-2-Overview.PDF) for Windows (and later, Linux) to get around this Microsoft limitation. If a FIPS-approved AES algorithm HAD been part of the base Microsoft OS, it would have saved us a lot of extra work and money.
I also know that AES is implemented by the "Microsoft Enhanced RSA and AES Cryptographic Provider" on Windows XP and "Microsoft Enhanced RSA and AES Cryptographic Provider" on Windows 2003. Windows NT and 2000 appear not to support this cipher.
So...I guess my more specific question would be "why didn't Microsoft put AES support into SSL at the same time they put AES support into the underlying crypto packages?"
Why hasn't Microsoft added AES to its SSL stack yet? As a Microsoft developer, it's annoying to get beaten over the head when facing competing solutions that can use the AES (128-,192- and 256-bit) encryption algorithm in their SSL implementations.
(OpenSSL - including the Mozilla browsers - and Java SSL have all had AES support for a while. Most SSH implementations have also had it for a while.)
Slashdot Mirror
Can I make a suggestion for this? It does SFTP and FTPS with automatic encrypted storage...
http://www.standardnetworks.com/moveitdmz
I've worked with MySQL replication for about three years and I'd have to say that feature isn't quite done. Some of the most annoying features:
- Manual cleanup of binary change files is sometimes required.
- Databases in "slave" mode can still be updated by local applications; you can't configure them to only log changes from the "master" database.
- Automated master-slave role-switching requires you to write some code.
- The whole "master/slave" terminology. I know it's meant as just computer-speak and the MySQL team is European, but I work in America; it can be offensive in some situations.
MySQL clustering is also only available for a few of the OSs regular MySQL supports; it's not a universal option for all platforms.
1) MOVEit DMZ with Secure Messaging (http://www.standardnetworks.com/moveitdmz) Many companies (and especially company HR departments) buy this web-based product so that they have an encrypted NOT-EMAIL channel to send secure messages.
2) If you don't mind the administrative hassle, SMIME/PGP-encrypted email will also protect you.
PGP is big in the secure file transfer worlds of banking, insurance and the like. It's quite common to "PGP" a file and then send it via FTP or SSH.
Someone else mentioned S/MIME encryption. I have two things to say about that:
#1: An analogy: PGP is to S/MIME as SSH is to SSL. The first technologies are designed for individuals to each trust each other; the latter technologies are designed to rely on a trusted third party (specifically, a CA).
#2: Despite not-wide-use in email, S/MIME is having its revenge in the form of the AS/x protocols, most commonly AS/2. This protocol is widely used in retail, distribution and pharmas and uses S/MIME encryption to both send files and receive cryptographically secure receipts. (Drop me a line at jonathan.lampe@standardnetworks.com if you want to chat about this further; I'm looking for some beta testers for a related application!)
In the United States, ADA website compliance means Section 508.
n /moveitdmz_generalinformation_federalregs_ada.htm
See:
http://www.access-board.gov/sec508/guide/
How do I know? Before the U.S. Post Office looked at our web-based secure file transfer and messaging product (MOVEit DMZ), they required us to pass this requirement.
You can see a short version of our "yes, we comply" statement online here:
https://support.standardnetworks.com/moveit/doc/e
Among the interesting bits: to meet full compliance we added an option that allows our administrators to add a "skip repetative navigation" link to the top of the page; this specifically allows audio readers to skip directly to the unique content on the page.
First, thanks for answering my question.
Believe me - I noticed the lack of FIPS validation too. In fact, my company (Standard Networks - http://www.standardnetworks.com/ was more or less forced to develop an FIPS 140-2 validated AES implementation ("MOVEit Crypto" - http://www.standardnetworks.com/uploads/media/MOVE it-Crypto-FIPS-140-2-Overview.PDF) for Windows (and later, Linux) to get around this Microsoft limitation. If a FIPS-approved AES algorithm HAD been part of the base Microsoft OS, it would have saved us a lot of extra work and money.
I also know that AES is implemented by the "Microsoft Enhanced RSA and AES Cryptographic Provider" on Windows XP and "Microsoft Enhanced RSA and AES Cryptographic Provider" on Windows 2003. Windows NT and 2000 appear not to support this cipher.
So...I guess my more specific question would be "why didn't Microsoft put AES support into SSL at the same time they put AES support into the underlying crypto packages?"
Why hasn't Microsoft added AES to its SSL stack yet? As a Microsoft developer, it's annoying to get beaten over the head when facing competing solutions that can use the AES (128-,192- and 256-bit) encryption algorithm in their SSL implementations.
(OpenSSL - including the Mozilla browsers - and Java SSL have all had AES support for a while. Most SSH implementations have also had it for a while.)
This is a Fourth Grade Math Problem
You don't need two morons on a Segway to figure this one out.
http://www.standardnetworks.com/moveitfreely
Free FTP/S command-line client for Windows. (FTP/S = FTP over SSL). Traditional and portable installations available.