in reply to Re: Adding a password to Zip compression ?
in thread Adding a password to Zip compression ?

Ah, sensitive data. Nope, as sporty said, don't use the zip password thingy!

You entered a realm of hassle now :) Sending out an e-mail with user/pass combo for a .htaccess protected site doesn't do much good either. The mail can be sniffed on it's way to the user, or the user's mailbox can be read by others (how many people do "lock" their screens when AFK?). The same argument is of course valid with the SSL connection. How does the user get his/her username/password? If you have the option of handing it over in person, go for that, otherwise: good luck :)

I would opt for GPG/PGP encryption (although I dislike the idea of sending files over SMTP, but that's just my personal believe). A lot of Windows users seem to see PGP/GPG as a burden though, but I even convinced my mom to use it, so I bet everyone can be convinced after some (long) discussions :)

--
b10m
  • Comment on Re: Adding a password to Zip compression ?

Replies are listed 'Best First'.
Re: Re: Adding a password to Zip compression ?
by peterr (Scribe) on Jan 04, 2004 at 12:25 UTC
    Hi,

    What are my alternatives to use email/PGP ?

    The user needs to see this (sensitive) information, and already has an user/pass for .htaccess paths. I _think_ using .htaccess login though, even though the password is encrypted at 'root' level, sends the username/pwd across the internet as plain text, just like FTP. :(

    I guess I could setup another path/directory, and the user _has_ to use the SSL connection, plus a .htaccess login. Would that make the viewing of the information 'secure' ?

    Sorry this is a bit OT for Perl now, but considering what people have stated, using a zip password is not secure, using PGP/email may be difficult as I haven't used it before, and this user is not very computer literate at all.

    Peter

[reply]
      I guess I could setup another path/directory, and the user _has_ to use the SSL connection, plus a .htaccess login. Would that make the viewing of the information 'secure' ?

      I always understood that all SSL connections are encrypted including the sending/receiving of logins and passwords. It will be as secure as SSL.

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
        Yes, that's essentially correct.

        If the directory is in an ssl-protected place, then the challenge/response (ie, the user/pass sent over the network) will be encased within the cryptographic sleeve.

        It goes something like this:

        1. browser makes an https request (ie, tries to access an https/ssl webpage)
        2. webserver responds with server certificate and encryption keys (public key)
        3. browser examines (sometimes with user intervention) the certificate, and accepts the session key
        4. a secure connection (cryptographic sleeve) is created; all traffic between the client/browser and server is encrypted
        5. if the .htaccess is set to require http basic auth, the basic auth challenge is presented (ie, user/pass dialog appears)
        6. user/pass is passed to server, inside SSL crypto sleeve
        7. if valid, server returns contents of requested location, also protected by SSL

        and so forth ad nauseum...

[reply]
        It is secure as a man-in-the-middle attack. He doens't have to act as a proxy, but if he can capture and reconstruct the end results of the transmitted data.. it's not all that secure. It's because the key creation, unless cert's are used on the client end, are negotiated, the negotiation can be replayed. If a client and a server both have cert's, then they'll use PKI... similar to GPG/PGP in effect.

        Play that funky music white boy..
[reply]
        Hi,

        I always understood that all SSL connections are encrypted including the sending/receiving of logins and passwords. It will be as secure as SSL.

        Sorry, I didn't explain it too well. At present, the user does have a login (.htacess,etc), and he accesses it like this

        http://example.com/userloginpath

        which, as I understand, still sends the user/pwd across the 'net as plain text. What I would like to do is to _force_ it to be

        https://example.com/userloginpath

        .. although he doesn't have SSL, I do, so using mine on a shared basis

        https://mydomain/example.com/userloginpath

        Peter

[reply]
      check this Invisible Proxy. Sourceforge also has some encrypted IMs projects.
[reply]
        The Invisible Proxy looks interesting, .."anonymous, encrypted Internet Relay Chat". No doubt you can send text (chat) and also send files (it looks like it is free as well). Thanks for the Sourceforge tips also

        Peter

[reply]
      Just as an aside... If you *did* use pgp, and just not send the mail, you could simply have an open web server (no ssl/.htascess required), allow people to download the file, and since it's protected using pgp, it would be 'hard' to see the file contents...


      ----
      Zak
[reply]
Slightly OT
by SavannahLion (Pilgrim) on Jan 05, 2004 at 17:02 UTC
    Excuse me for butting in here, I've been out of the loop for a while on PGP. Didn't the U. professor sell PGP to someone (Netscape I think?) and there was a lot of concern about PGP being patented and no longer being secure anymore? The news broke out right about when my life took a turn for the worse and I didn't have the time then to track the PGP news.

    When you refer to GPG, I guess you're meaning the project at gnupg.com? I would guess so since a search turns up the gnupg.com site at the top, but they don't seem to refer to themselves as GPG.

    ----
    Thanks for your patience.
    Prove your knowledge @ HLPD

[reply]

      AFAIK, the PGP(.com) program is indeed commercial and they have patented their "IDEA". I also heard that the FBI (or whatever three-letter US department) tried to persuade the company to build in a backdoor, which PGP claims not to have done.

      With GPG I indeed mean GnuPG, the Open Source variant of PGP (and based on OpenPGP). And their website is (how original) http://www.gnupg.org/. On that site, they say:

      GnuPG is a complete and free replacement for PGP. Because it does not use the patented IDEA algorithm, it can be used without any restrictions. GnuPG is a RFC2440 (OpenPGP) compliant application.
      --
      b10m
[reply]

In Section Seekers of Perl Wisdom