That would work fine for lost or stolen devices, or whenever the user *knows* that their password has been compromised.
What about cases when the user does not know that the password is compromised. I think in those cases it would be easier to have multiple passwords. There can still be one place to change those passwords if the loss is known. --mat Tim Fournet wrote: > Which is exactly my point - use ONE password that has ONE known way for > this user to change it when a theft happens. Using multiple passwords > just means there's that many points of entry into his personal > information/data/account/credentials/whatever. > > If you give a user 5 different passwords for all his networked > functions, that's FIVE different open doors when his device gets stolen. > Give him one password, and he only has to change one password. > > > Now, back to email, which was the original question - I mentioned > earlier that many corporate email services for PDAs do not even store > the password on the device. Authentication happens on an encrypted > channel that gets created which is based on server-assigned keys plus > the device's unique identifier with the phone company. > Examples: > 1) NotifyLink - PDA talks to intermediate server, which then talks to > the mail server. The communication between PDA and the intermediate > server uses a password that is unique to that connection. The user > doesn't even know this password, it is provisioned by the administrator > upon initial configuration > 2) Blackberry with mailbox sync provided by communications vendor - The > user logs into an account at the cell company > (Verizon/T-Mobile/Cingular, etc). He puts his POP/IMAP login information > in there, and then the phone company "pushes" the email to the device > over a non-"internet" connection. Something more like SMS messages > 3) Blackberry Enterprise Server - account is linked to Exchange/Notes on > the BES server itself. The communications with the device start on the > BES server and travel over the cell network as non-IP data. A user can > even change his domain password and never have to update the PDA or the > BES server. > > In none of these examples does the PDA even know what the user's > password is. It's simply talking to an intermediate server that does the > authentication for it. If the user loses his PDA, then there are actions > available to disable the PDA. NotifyLink has a special command to wipe > the mailbox and not send more data, as does BES. I'm not sure about the > cell-provided Blackberry service, but future mail can sure be disabled > by logging into the site. > > To clarify, here are my recommendations: > 1) Use email software on PDAs that is enterprise-grade. These don't > require the PDA to know anything about corporate logins > 2) Use a single sign-on, but make sure the user can easily change his > password or have it disabled in the event of potential compromise. A > single sign-on means a single change. > 3) Enforce a sane password policy. Some minimum length of letters, > numbers, etc, but one that the user can remember > 4) multi-factor authentication should always be considered where possible > > > > Dustin Puryear wrote: > >> I guess I'm not understanding this. If most users don't use a PDA >> password feature, then how can the PDA encrypt user passwords (e.g., >> their POP3 password) stored in the PDA's memory? At best, the PDA can >> scramble the password in a way that is consistently unscrammable (my >> word) since the PDA has no unique key to do the encryption that is >> external to the PDA itself. >> >> At first pass it may seem like nobody would bother to pull data off a >> PDA or cell, but there are entire rings of people that buy stolen >> credit cards, phones, etc., and they have the motivation to basically >> create an assembly line for getting and using stolen information. >> >> I MEAN HELLO! Don't you watch Dateline? :) >> >> --- >> Puryear Information Technology, LLC >> Baton Rouge, LA * 225-706-8414 >> http://www.puryear-it.com >> >> Author: >> "Best Practices for Managing Linux and UNIX Servers" >> "Spam Fighting and Email Security in the 21st Century" >> >> Download your free copies: >> http://www.puryear-it.com/publications.htm >> >> >> Thursday, February 15, 2007, 12:39:04 PM, you wrote: >> >> >> >>> Both of those articles mention that PDA owners are saving corporate >>> passwords on their PDAs in cleartext. If they are doing so, then they'd >>> be saving both their "email" passwords and their "non-email" passwords, >>> along with PIN numbers, bank account numbers, etc. In which case, it >>> doesn't matter how many different passwords users are given to access >>> corporate systems, they'd all be in there. In fact, it would be even >>> worse with the more passwords they use, since that makes it more >>> passwords that need to be changed. >>> >>> >> >> >>> Neither articles mentions that email clients on PDAs store passwords in >>> an unencrypted or easily crackable manner. >>> >>> >> >> >>> Dustin Puryear wrote: >>> >>> >>>> I think your being a tad optimistic about the state of security for >>>> PDAs and cells: >>>> >>>> http://www.pointsec.com/news/newsreleases/release.cfm?PressId=44 >>>> http://www.net-security.org/article.php?id=533 >>>> >>>> --- >>>> Puryear Information Technology, LLC >>>> Baton Rouge, LA * 225-706-8414 >>>> http://www.puryear-it.com >>>> >>>> Author: >>>> "Best Practices for Managing Linux and UNIX Servers" >>>> "Spam Fighting and Email Security in the 21st Century" >>>> >>>> Download your free copies: >>>> http://www.puryear-it.com/publications.htm >>>> >>>> >>>> Thursday, February 15, 2007, 11:47:44 AM, you wrote: >>>> >>>> >>>> >>>> >>>>> You're assuming someone would be able to hack out an email password from >>>>> a stolen device. I doubt many devices actually store the passwords in an >>>>> easy-to-access cleartext sort of way. Usually this will require a >>>>> brute-force attempt on the device, which would be extremely difficult >>>>> given the nature of getting data out of a cell phone, for example. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>> We host email for users that use mobile devices. These devices use >>>>> specialized software to push the email to them. With the software we use >>>>> (NotifyLink), the device doesn't even know the true email password of >>>>> the user. That information is stored on an intermediate server that sits >>>>> between the real mail server and the user's device to push out that >>>>> information. I'm pretty sure that the Blackberry Enterprise Server does >>>>> something similar. I know that the basic Blackberry services that the >>>>> cell phone providers offer do the same as well. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>> Even if it is possible to somehow crack those passwords, given enough >>>>> time, it would also be assumed that the user will notice that he's had a >>>>> theft, and have been able to change his password as well. This is where >>>>> it's advantageous to use a single sign-on for all his services. That way >>>>> he's got a single password to have to change and most likely has an easy >>>>> way to either do it himself or get administrative assistance in doing it. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>> If we're using separate passwords for email and other services, then the >>>>> user may not even realize that fact. If he gets an email device stolen, >>>>> he may change his password for 'other' services, not knowing that his >>>>> email is still getting to the device. The thief then can potentially >>>>> read that user's email, or masquerade as him and cause all kinds of >>>>> damage. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>> In the case of a VPN client, it's within the policies of many VPN >>>>> clients to not save passwords, and require the user to enter passwords >>>>> for every login. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>> Considering the above, my vote is for a single, well protected, easy to >>>>> change password for all of a user's activities. This keeps things very >>>>> simple and makes it possible to enforce password complexity. It's a lot >>>>> easier for a user to remember one complex password than many. In the >>>>> event his secret password does get compromised, it's a one-step task to >>>>> change it. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>> I've had a lot of success hosting accounts in Active Directory, and then >>>>> using LDAP mechanisms to authenticate against it across several >>>>> platforms. AD makes it easy for semi-technical people to manage >>>>> accounts, and it's a predictable schema for building LDAP-aware >>>>> applications to authenticate against. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>> -Tim >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>> Dustin Puryear wrote: >>>>> >>>>> >>>>> >>>>>> Agreed. How often do people tie their VPN into, for example, AD or >>>>>> LDAP? And how many people tie their email credentials to, for example, >>>>>> AD or LDAP? So if I get your email credentials from your lost >>>>>> cellphone or PDA, then I have your VPN credentials.. >>>>>> >>>>>> This really has nothing to do with admins. >>>>>> >>>>>> --- >>>>>> Puryear Information Technology, LLC >>>>>> Baton Rouge, LA * 225-706-8414 >>>>>> http://www.puryear-it.com >>>>>> >>>>>> Author: >>>>>> "Best Practices for Managing Linux and UNIX Servers" >>>>>> "Spam Fighting and Email Security in the 21st Century" >>>>>> >>>>>> Download your free copies: >>>>>> http://www.puryear-it.com/publications.htm >>>>>> >>>>>> >>>>>> Wednesday, February 14, 2007, 6:40:32 PM, you wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> The admin isn't the only user that has valuable information. I don't >>>>>>> think we are talking only about network security, but data security as >>>>>>> well. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> --mat >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Kevin Kreamer wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Dustin Puryear wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> What are your thoughts on whether email accounts should be separate >>>>>>>>> from normal network accounts? Pros? Cons? Should companies just not >>>>>>>>> allow external access to email via POP or IMAP and just require >>>>>>>>> Webmail access so users have to manually enter passwords? Does that >>>>>>>>> solve the real problem? I'm interested in hearing what everyone has to >>>>>>>>> say. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I'm going to add here the opinion that if your network security relies >>>>>>>> on the security of non-admin user passwords, you've already got >>>>>>>> problems. Likewise if your admins pick insecure passwords or write >>>>>>>> them >>>>>>>> down in sticky notes. >>>>>>>> >>>>>>>> Kevin >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> General mailing list >>>>>>>> General at brlug.net >>>>>>>> http://mail.brlug.net/mailman/listinfo/general_brlug.net >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> General mailing list >>>>>>> General at brlug.net >>>>>>> http://mail.brlug.net/mailman/listinfo/general_brlug.net >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> General mailing list >>>>>> General at brlug.net >>>>>> http://mail.brlug.net/mailman/listinfo/general_brlug.net >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>>> _______________________________________________ >>>>> General mailing list >>>>> General at brlug.net >>>>> http://mail.brlug.net/mailman/listinfo/general_brlug.net >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> General mailing list >>>> General at brlug.net >>>> http://mail.brlug.net/mailman/listinfo/general_brlug.net >>>> >>>> >>>> >> >> >>> _______________________________________________ >>> General mailing list >>> General at brlug.net >>> http://mail.brlug.net/mailman/listinfo/general_brlug.net >>> >>> >> _______________________________________________ >> General mailing list >> General at brlug.net >> http://mail.brlug.net/mailman/listinfo/general_brlug.net >> >> > > > _______________________________________________ > General mailing list > General at brlug.net > http://mail.brlug.net/mailman/listinfo/general_brlug.net > >
