Re: Auth, Mcrypt and two-way encryption

Thanks for your suggestions. They make sense. I will run them by the client, hopefully they will have a bit of reason about them ;) Justin Patrin wrote: > On Wed, 05 Jan 2005 13:53:09 -0600, Sarah Gray <sarah@fabled.net> wrote: > > > > > > Justin Patrin wrote: > > > > > On Wed, 05 Jan 2005 13:19:13 -0600, Sarah Gray <sarah@fabled.net> wrote: > > > > Hi, > > > > > > > > I have a client who wants to store encrypted passwords in a db, but also > > > > wants to be able to decrypt the passwords so that the administrators can > > > > have a list of passwords handy if the students have forgotten them. They > > > > basically need to be able to print out lists with the student names next > > > > to the students' plain text passwords. They then distribute these lists, > > > > or read off of them themselves. There is no email-my-password or > > > > change-my-password functionality in the application (it does not meet > > > > this systems' needs). > > > > > > > > I know that using md5 encryption you get one-way, which would not be > > > > good for this clients need. I have looked briefly into the Mcrypt > > > > library that supports two-way encryption (meaning I have read about it > > > > online, have not downloaded or tried it). Can one use this library and > > > > also use PEAR:: Auth (by setting the cryptType to Mcrypt (or the > > > > specific algorithm you have selected from mcrypt)? How would you do > > > > that? > > > > > > > > If anyone could answer that question, or the more general questions: > > > > -- Is there a way to do two-way encryption using Auth (and if so, is it > > > > worthwhile or secure)? > > > > -- If not, is there another way to do two way encryption that I have not > > > > thought of? > > > > -- Or would you suggest just storing the passwords as plain text and > > > > forgetting about encrypting them altogether? > > > > > > > > I'd be very appreciative for any advice on this matter. > > > > > > > > > > (IMHO) > > > Having plain text listings of password next to username printed out > > > (or electronically saved somewhere) is as bad as having them plaintext > > > in the DB. My suggestion to you is to use one-way (md5 or better) > > > excryption to store in the DB and checkk the PW and make a "reset my > > > password" page for the system. If you don't want this, then make a > > > page where the admin can change someone's PW. Then the student goes to > > > the admin and gets a PW change. Plaintext PWs *anywhere* is a recipe > > > for insecurity. > > > > I agree entirely. Printing them out defeats the purpose -- basically, the > > client wants to be the person who distributes the passwords to the students in > > the first place. They want the passwords autogenerated when importing a list > > of students. Which is fine, but if they're stored using md5 then no one knows > > what they are unless they are also stored somewhere as plain text. They don't > > want them emailed to students. They don't want students to be able to > > access, set or change them anywhere in the application. They want to be able > > to say, 'let me see those 100 new autogenerated passwords and who they belong > > to! Let me print out the list and send it to the faculty member who will then > > distribute the passwords one by one to each student!'. So yes, the client > > really wants cake and eat it too. I was wondering if I could at least make > > the development side of this secure and reasonable, so the only unreasonable > > entity here would be the client waving around their plain text lists of > > passwords. At least feel like I wasn't just foolishly storing plain text > > passwords in a db. Does that make sense? To that end I was curious about > > two-way encryption, though you may still tell me that the ability to decrpyt > > it for the browser is just as bad as plain text in the first place... Other > > than having new system requirements, do you see any good options for this > > situation? Would emailing a plain text list of passwords to the admin before > > they're encrypted be any better? Probably not, right? > > Depends. If the webserver is the same server as the mail server, this > is reasonably secure, although the passwords would be plain-text in > the e-mail spool. > > You could display the passwords in the browser after making them and > have the admin print them out then. As long as you're doing this over > HTTPS you should be fine for security as long as you make sure to send > "No Cache" headers and such to the browser. For what you say you need, > this seems like the best bet. *And* you should be able to regenerate > or reset the passwords in the admin frontend. > > > > > Thanks. > > > > > > > > > > > > Thanks in advance, > > > > sarah > > > > > > > > > > -- > > > Justin Patrin > > > > -- > Justin Patrin