Re: Auth, Mcrypt and two-way encryption

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