- This topic is empty.
-
Posts
-
With APOP authentication protocol, user passwords are stored in clear text in the PasswordService database. The docs indicate that WebDAV passwords are also stored in the clear, though the output of ‘NeST -getprotocols’ suggest otherwise. My question is: if I disable these protocols (‘NeST -setprotocols * off’), can I get the clear-text passwords out of the DB without recreating it from scratch? Thanks for replies.
Thanks for your reply.
< First off, do realize that by stored in the clear they mean "stored in a recoverable way inside an encrypted database". >
How is the database encrypted? You boot up Server, OD works right away. Nobody has to enter a password. The database contains some hashed data, but the APOP and (possibly) WebDAV passwords are recoverable, according to the documentation. That doesn’t mean they’re searchable text, but they can be extracted by someone who has access to the storage medium.
< Compounded by the fact that you'd need to be root on the box to get to the password store to begin with. >
Not if you have physical access. You come back to the server and find it shut down. It’s not under 24-hour surveillance. How do you know somebody hasn’t been there in your absence, booted in FW target mode, and copied the password database?
< However, after changing the protocol type you'll need to change the users password to flush out the disabled protocol. >
I tried that, and it doesn’t seem to work. I created a test user with an OD password, then disabled APOP, deleted the account completely in WGM, saved changes, and recreated the account with the same password. Only one byte of authservermain (a non-printing character) was different. It looks to me like you have to wipe out the whole database and start over AFTER you disable APOP and perhaps WebDAV.
< The database is encrypted by a key that's embedded into the password server binary. There is no easy way to extract the key from the binary. That's not to say it's impossible, but that it's well beyond me and anyone I know. >
Not that I doubt your word, but do you have any documentation for this statement? Taking it at face value, the key is the same for every installation. I’m not sure offhand whether the PasswordService executable is open-source, but the database engine certainly is. In any case, somebody other than myself knows the key, and therefore I have zero confidence in it. Zip, zilch, nada.
< Agreed, with physical access all bets are off. However if strange people have physical access to your server, game over. All of your data, not just the passwords, is at risk, so why bother protecting it at all? >
I disagree. In fact I go to great lengths to ensure that my data is secure against a black-bag attack. Everything is on encrypted disk images, FileVault or otherwise. Apart from what leaks out into the swapfiles, nothing I care about is at risk. You may say the swapfiles are a problem, and that’s true, but I check them periodically, and the passwords, at least, seem to be safe in the last few revisions of OS X. If you steal my hard drive, you might get to read some of my files, but you will not be able to log in as me.
< So I'm not quite sure what you did. If the new user didn't have a password server password you won't see a change. >
Obviously, the test user did have an OD password; otherwise there would have been no point to the exercise.
< Orphaned passwords, when you delete the user, are not deleted from the password server. Instead a new slot in the password server is used when the new user is created. So, don't expect to see the old hash go away necessarily. >
Unfortunately that confirms what I thought, which is that I have to securely wipe authservermain and recreate it from scratch after disabling the insecure authentication modes. Wish I’d known that when I first set up the server.
- You must be logged in to reply to this topic.