Re: Auth, Mcrypt and two-way encryption

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? Thanks. > > > > Thanks in advance, > > sarah > > > > -- > Justin Patrin