security - Safely storing passwords when access to the plaintext is still needed -

possible duplicate:
php 2-way encryption: need store passwords can retrieved

i know best practice storing user passwords store irreversible hash of password.

however, developing application need store user's login information web service -- i'll need periodically log them in , perform maintenance tasks. unfortunately, service doesn't offer authorization tokens (very apprehensively) have store passwords in way can access plain-text values. don't own or control service authenticating, , method 'borrow' users username , password , authenticate.

i planning aes_encrypt passwords in db, means if somehow able access db won't able plaintext. code need have access key unencrypt them, if entire server compromised no protection , passwords revealed.

aside above-described encryption, there best practices or steps can take safely possible?

edit

i know whatever do, passwords must accessible in plaintext , compromised server means passwords revealed, wondering steps can mitigate risk. e.g. encrypting db protects me in situation db compromised not entire server. other similar mitigating steps appreciated.

however, developing application need store user's login information web service -- i'll need periodically log them in , perform maintenance tasks.

ok... read through answers , comments, , can hope have crack legal team. sounds me service offering predicated on user trust. it's it's user-controlled switch, , not being helpfully done behind backs, think want iron clad service agreement on this.

that said, there's lot of security paranoia can invoke. you'll have figure out how want go through based on harm product, company , users if break in occurs. here's thoughts:

• data storage - store passwords far away attacker can in. highly access controlled files, database on end machine, etc. make attacker have go through layers of defense place data stored. have network protection firewalls , date security patches. no 1 thing works in isolation here.
• encryption - encryption technique delaying tactic - 1 attacker has data, crack encryption given infinite amount of time. you're aiming slow them down long enough rest of system discover you've been hacked, alert users, , give users time change passwords or disable accounts. imo - either symmetric or assymetric cryptography work - long store key securely. being pki person myself, i'd lean towards assymmetric crypto because understand better , know of number of cots hardware solutions make possible store private key extremely securely.
• key storage - encryption key storage. if key sitting right next encrypted data, stands reason attacker doesn't need break crypto, use key. hsm (hardware security modules) high end choice key storage - @ upper ranges these secure boxes tamper proof both hold keys , perform crypto you. @ low end, usb token or smart card perform same function. critical part of ultimately, it's best if make admin activate key access on server startup. otherwise, end chicken , egg scenario try figure out how securely store ultimate password.
• intrusion detection - have system in place has chance of raising alarms if should hacked. if password data compromised, want word users ahead of threat.
• audit logging - have records of did on system - particularly in vicinity of passwords. while create pretty awesome system, threat of privileged users doing bad (or dumb) bad external threats. typical high end auditing systems track high privilege user behavior in way can't viewed or tampered high privilege user - instead, there's second "auditor" account deals audit logs , nothing else.

this highlight of high points of system security. general point - if serious protecting user passwords, can't afford think data. encrypting passwords not enough protect users , safeguard trust.

the standard way approach consider cost of explotation vs. cost of protection. if both costs high value of feature, have indication shouldn't bother doing it...