Fact is that you need to do something on the client side to decrypt it. You don't need https of course, but then you need to convince the client side to run alien code. Luckely, almost anyone happily runs any Java applet send their way. So, that's an option if you don't want to use https.

Note that https (or rather, the use of certificates) can give you things that PGP or something similar cannot give you: authentication of both the sender and the receiver (PGP can give you authentication of the sender, that is, if you have a way of proving a certain key belongs to a certain person).

But you said "as safe as possible". Even with https, you are still not as safe as possible, because you are merely encrypting your data. What you are not hiding is the fact information is exchanged - or whether that's a small or a large piece of information. There are techniques to make it hard to do any form of traffic analysis, but they aren't easy to do right, and I doubt you will find canned solutions on CPAN.

Abigail

At a company I used to work for, we used PGP this way:

  * client company and our company agree to use PGP to
    exchange private PGP encrypted files.
  * client company and our company (generate if necesary,
    and) exchange PGP public keys
  * client company develops their own methods(manual or 
    automated scripts) for encrypting files to send to
    us, *AND* for decrypting files that we send to them.
  * likewise, our company developed our own software based
    on PGP's command line batch API, for encrypting files 
    to send to clients, and for decrypting encrypted files 
    sent to us by clients.
[download]

I haven't personally used Crypt::OpenPGP, but I'd bet that all the tools are there to allow you to script both encrypting and decrypting GPG files.

What https gives you is security while your data is *being* tranferred from the browser to the server and visa-versa. If you don't have https availability, in my mind the next best thing is encrypting the data on one end, and decrypting data on on the other end. Just my opinion.

Yes and no. https will only encrypt the transmission between the webserver and the browser for you. It won't prevent anyone from getting into your site.

I think your first thought should be, how important is the data you have. For example, if you're storing confidential client data, you want to secure it. If it's just a plain bulletin board with non-secret information, why bother with https?

As I said, https will only send html via an encrypted channel between the server and browser. https does not include a method for you to authenticate against the webserver, unless you want to issue certificates to all users (or you're VERY paranoid).

In my opinion, you could setup a perl CGI script, to accept the user and password, authenticate the user, and once authenticated, keep the session alive by passing a unique variable around all your forms, or by placing a cookie on the browser. There are many ways around this.

If security is your focus, don't just focus on https. Yes, https is important, but you also have to secure your database (if you have one), tie down any loose ends with your OS (eg. can a anonymous user connect to your box and get /etc/passwd ?)

Play around with Perl CGIs. They're a lot of fun, and they work on both the Unix's and Windoze boxes with either IIS or Apache.

https is a bidirectional encrypted transfer method between your browser and webserver, that makes the data unreadable while in transit. You configure it in your webserver by adding a certificate to it. The encryption is then transparent for your content providers, ie. you use your cgi script as you would with http. No need for encryption in your perl script, it isn't even aware that the data is being encrypted.

So with https, you have data encryption. Now you need user authentication and authorization, and possible session management. There are several ways to accomplish that (ie. basic authentication realms, sessionid's in URL, cookies etc.)

DES is considered laughable these days. You could probably find many programs that could brute force DES on a common PC in a respectable time.

Look at PGP/GPG for easy public key encryption or consider symmetrical ciphers such as IDEA or Blowfish, any of the leading AES contenders - not just Rijndael - or something like RC5.

There are plenty of good ciphers out there, DES should near the bottom of the list, just below Crypt::Rot26 (jeffa++ :-)

Cheers.

BazB

DES is considered laughable these days. You could probably find many programs that could brute force DES on a common PC in a respectable time.


You are right. I forgot to mention that the triple DES version should be used, which basically consists of three repetitions of DES with three different keys. It is significantly more secure than DES. Incidentally, the link I suggested has an implementation of both.
Of course, the choice of this or any other algorithm (like the ones BazB suggests) should be done according to a number of technical considerations (security constraints, algorithm efficiency, existence of ready-made implementations, etc.).

Best regards

Antonio Bellezza

• Are you transfering content that will be viewed in a web browser? Or is this content that will be used by some kind of back-end system at your client's location?
• What kind of relationship do you have with your clients? Do you have a speaking relationship, where you can discuss security matters, or an anonymous relationship, where you have to make assumptions and provide a very general solution?
• Do you trust your clients, or is there a community that can be trusted? Do you need to provide unique encrypt-decrypt information for each client?
• What does your data look like, big chunks of data, or many little pieces?
• How important is speed here? Do you need to generate information on the fly, or can information be 'pre-encrypted' for transmission at a later time?
• What level of inconvenience are your clients willing to tolerate? Where is the balance point between security and useability in your situation?

True security is HARD so take some time to research the different systems available and define your needs as specifically as possible so you will know what the solution looks like when you find it :)

oakbox