Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Re: Adding a password to Zip compression ?

by peterr (Scribe)
on Jan 04, 2004 at 12:25 UTC ( [id://318652]=note: print w/replies, xml ) Need Help??


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

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

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

Replies are listed 'Best First'.
Re: Re: Re: Adding a password to Zip compression ?
by CountZero (Bishop) on Jan 04, 2004 at 18:18 UTC
    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

      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...

      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..
      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

        Perhaps a job for the mod_rewrite engine of Apache? I think (without having tried it yet) that you can force such redirections by writing some rewriting rules.

        CountZero

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

Re: Re: Re: Adding a password to Zip compression ?
by chanio (Priest) on Jan 04, 2004 at 21:48 UTC
    check this Invisible Proxy. Sourceforge also has some encrypted IMs projects.
      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

Re: Re: Re: Adding a password to Zip compression ?
by zakzebrowski (Curate) on Jan 05, 2004 at 13:21 UTC
    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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://318652]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2024-04-25 16:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found