Keep in mind that in this day and age you really should be using cryptographically protected protocols and many of these when you're dealing with device access will cryptographically protect your passwords. So for example ssh to access the device. Absolutely use that--never use telnet. All right? I'm also surprised that people still use FTP and TFTP to copy files over. Me, I would much rather use SCP i.e. secure copy. Now there are environments where you have legacy older devices, really old, and they only have telnet. If that's the case you don't want to create an unsecure infrastructure but by saying that well we have to use the lowest common denominator and everything is only accessible by telnet that is wrong. What you want to do is take those devices that are legacy, that are only accessible via telnet and put them somewhere in their own section of the network and then also what you want to do is use jump hosts. So in this picture here imagine that you're going to a conference right and then all of a sudden you get a phone call and there's a network outage that you need to be able to jump in and help resolve. What you then do is you would log in using SSH into a jump host. So it's a designated device within your network infrastructure that then you can log into but you're using a cryptographically protective protocol, SSH So your password is not sent in clear text. It's protected by a tunnel, a cryptographically protected tunnel, and then you would go from that host to then login to that legacy device using telnet but over the conference network and the entire Internet until you get to your device all the credentials would be protected. The main point here is that do not use telnet in your entire infrastructure. If devices support SSH please use that. there are some very serious consideration to think about when you have larger infrastructures and you have a lot of passwords to keep track of. You want to be careful of where you store the data. There are many password management systems that utilize the cloud. Now keep in mind the cloud is somebody else's computer so it may be well protected but don't just assume that. Right, validate their operational security practices and so if a third-party management system really looks to have really good people and really solid practices it may make sense to use that. I would recommend looking into something called the iron key. An iron key is an encrypted USB device. Everything that's on there is encrypted. You can set up the number of passwords that it will accept and if you have three or five or whatever your number is that you configured wrong passwords, then the device will no longer work. And why I like the iron key is because it's much easier to remember one password and have access than to anything that you need on this USB device but obviously it's a physical device that you also must really protect. So in summary for some best current practices for credential management set passwords to something that is not easily guessed. It used to be that everybody said create very complex passwords. Well, with this complexity and also mandating that you have to change it every 30 days or 90 days nobody's going to remember that. Right? You're going to end up writing it down and that's even worse. So much better practice is really determine what frequency makes sense to change the passwords and it's much better to have longer passwords so think about a passphrase, right, insert some uppercase, lowercase letters in there, some numbers, maybe one or two different characters like a hash or a bang or something but length really matters more. Also use single user passwords, try to avoid group passwords wherever possible, make sure you encrypt the passwords and configuration files, use different passwords for different functions and also as often as possible try to use cryptographically protected protocols for device access so you're not sending credentials in clear-text. Thank you.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.