With cloud and virtual systems, your usernames and passwords are really the key asset for the company. If you think about it, you don't have the hardware sitting there, you don't have software on a CD, you don't have the data. Usually, even if you back it up occasionally, your access to that thing is based on username or usernames, plural, and passwords. What I want to talk about in this section is a scheme that we came up with over time to manage passwords, to keep them secure. Give us the ability to know them within the company without letting the password on one service. give away the password on another service.

We face it, you do it, I did it for years. You know, I got some new passwords to remember. I'm going to use this and it's a combination that means something to you, hopefully not password, but that's the one to use for Everything, the problem and there was a well publicized case not that long back. problem is if someone gets it, and guess is that you use the same username and password or email and password on other services on your hooped. But at the same time, a different password for every service. Forget about it.

I've got hundreds of passwords, and there's no way on Earth. I'll remember them all. at the tail end of this, I will talk about a bit of technology that I strongly recommend to help you with that. But macro level on this is about understanding and remembering and I've got it we've got a better solution for you to do that. It doesn't load your memory. It doesn't require remembering a different password for every service, but it actually enables you to use a different password for every service sound like an impossible trick.

Check this out. Okay. By the way, I just realized even though I should have known this, that the technique of creating A an email alias, or an email forward for each service you use also has the benefit of buffering one service from another. If your username on PDQ comm is PDQ. At PDQ, calm, and your username on Amazon is Amazon at PDQ, calm, different username as well as different passwords so double the protection there are plenty of people in the security world that think username and password is antiquated dead should go the way the dodo bird. I don't disagree with that, but it's not gonna happen anytime soon and you will be using username and passwords for years and years to come.

We still use an internal combustion engines right? So let me see if I can spell out this scheme for in a way that makes sense. So username which is very frequently email sometime you get a username Aside from email assign and password, so username, password normal default we are we have too much to remember. solution is to say I'll use my email here, me at PDQ calm. And I'll use password for a password. Terrible solution, right?

Don't do that. Don't do that. Here's what you do instead. The basis of this technique for passwords is one set a strong password that you can remember, maybe even one or multiple people in your company can remember I'll come back to that to borrow from the service, set those two steps. So the strong password you keep consistent from service to service and the borrow you borrow from the service itself. Let me see if I can show Yeah, let's say this service I'm just making this up to make the point was was is salesforce.com I've used Salesforce, it's pretty amazing.

Okay salesforce.com let's say I don't know what the Salesforce uses usernames or passwords right now. If you sign up for Salesforce at least one account for your company, the email you're going to use, if you take the advice earlier, is Salesforce at PDQ calm, you may get to where everyone in your company has their own login. That's kind of the nature of Salesforce as a service. And from that perspective, it's a little broader scope. And some of the other services we'll be talking to even then you might consider using aliases. So if a sales guy leaves, you're still in control of his logging, but leave that aside.

So you've decided to use Salesforce at PDQ PDQ calm as username, what do you set for a password that's going to make that different from other services and yet memorable at the same time. So a strong password. The technical advice is a mix. It's a mix of letters, numbers, and sometimes if you're really going to be strict about it symbols, and preferably a mix of upper and lowercase letters, so let me pick a strong password and make up a strong password. To illustrate. We use my company name or a variant of it, sa y, and I'll use a one instead of a capital I say it.

Usually, we don't use it for a password of course, but it's a strong password because it's got a mix of letters upper lowercase, a number in the middle of it in that case and assemble the exclamation point at the end. You're even better served To use something is complete gibberish with no English no words at all. Honestly, you are, I always have a hard time remembering those. So for the sake of the example I'll use say it visually with a one for the capital I. That's not the password we want to set on Salesforce. com that's half of the equation.

So strong password that we're going to use part part of what we're going to use on multiple services. Now, what do I mean by borrow from the service? We've got these letters that we know because we're logging into salesforce.com si le, s fo r seek. So here's the here's the critical. Here's a critical Tumblr Elan is locked. My suggestion is that you pick a position in the service usually in the domain name of the service, right salesforce.com Salesforce is the domain name here.

Pick a position first letter, second letter, third letter. Something like that, then decide on a shift if you want to. So if you said we're going to always use the second letter in a domain, in this case, it would be what it'd be a write as a Salesforce essay, and then decide where you gonna put that in combination with the strong password you use. So, in that scenario for Salesforce, I made say that my password is going to be say it with a one visually, exclamation point, I just picked the second letter. And I didn't shift it, I didn't rotate it at all. If you want to make it slightly stronger, you might say we're going to do second letter, and we're always going to shift it up by three characters, A, B, C, D, so a plus three would equal D. In that case, I would say, my password for this service is little D might sound a little and I decide on my design lowercase might decide an uppercase little D, say it visually with a one in the middle and an exclamation point at the end.

Sounds complicated, right? All I had to remember coming into this was the password the strong password that we picked, say warranty visually exclamation point, save visually, I remember that one right company name, all I have to do is remember that the information I need to get or to derive from the particular login is baked right into the name itself. Salesforce gives me letters to work with. And if you want to be a little bit more secure, instead of taking a letter out of the name, take a letter and shift it so a plus three, up three, gives me a D. Let's test that against another like hypothetical service say we wanted to pick up a subscription to up accom fresh books because I think those guys are really great fresh books. Right, what's the password gonna be? What's the username and the password going to be if you open a freshbooks comm account for your company?

We'll keep the Salesforce stuff over here. Right? There's your Salesforce credentials, right there. Remember our rule is second letter plus three. Okay. So you're racing ahead of me and you already know the answer to this one.

For fresh books. There's letters we've got to work with. For fresh books. The username that we're going to use, it's going to be fresh books, at PDQ calm, okay. And password. I'm going to take the second letter, which in this case is in our I'm going to go plus three s t you do that right.

Are you s t u ABCD. Yeah, so it's u r plus three equals u. So my password for this service is going to be U. S a one T, exclamation point. So look at the security that I've got in place there. If someone gets my Salesforce password our Salesforce password on, they know that it's Salesforce at PDQ calm, that's a username.

It's not a rocket scientist would say, okay, they're using the name of the service, but leave that aside, most of this is automated, and most of most, much of the nasty cracking and hacking is highly, highly automated. So if you're gonna grab your username and your password and go knock on the door of a bunch of other services, you're going to have the wrong email the wrong username, and they're going to have a password that's not the same as the others. Salesforce at PDQ calm And D, strong password versus fresh books at PDQ calm and s, I should be a you Sorry. And you strong password. So different passwords on different services, but you don't have to remember what's different about them different usernames on different services. And again, you don't have to remember it.

It's derived what's implicit in the name of the thing itself. domains at a minimum are two letters. I don't know if there's unique commercial two letters in existence, like three is very, very typical. And that's if you were early early on in the internet. So borrowing first, second or third letter letter, and preferably shifting it works. I use the same thing for desktop apps that require a password and I use the name of the app itself.

If I was going to password protect Excel, I'd say e x e L is the string set I've got to work with at a company level You can take the strong password and say this is what we use. And this is the schema we use. So here's the company strong password. And here's the technique. second letter shifted by three in this example there. The virtue of that is someone else in your company.

And I'm assuming a relatively small and trusted company here, who needs to get into a service that you use multiple users one password, multiple users, one login, can guess it, right? If I've set up a password for some relatively new service, and I say to my business partner, go check it out. He actually knows how to login. I didn't have to tell him the username, or the password. I'm consistent about doing this. And I'm consistent about the strong password that we use for company stuff, and he knows the place and the shift to pick.

It's not as good as Super top secret cryptography and fingerprints but like I said, that's really not going to show up anytime soon and password. And usernames are one of the critical assets that you've got. The other thing that that really insulates you from practice everyone should follow that's really, really hard to follow is having records, right? If everyone in your company has accounts here and accounts there, those are key company assets. If you don't have them written down and something gets wiped out, someone leaves the company. Someone's plugged in nasty and you need to change stuff really fast to protect yourself with this approach to a reasonable extent.

You know what the password is going to be. And you've got a good shot at what the username is going to be. Our last tip about passwords you might even consider giving every employee an alias to use for sign ups that's different than their email name. If we had a guy Fred at PDQ calm, this may be a repeat example. My apologies. We might say we're going to give Fred an alias we might say Fred Smith uses alias at PDQ calm We say Fred, listen, when you're signing up for the kind of services that require an individual login, because each of us in the company is going to have one.

We want you to use Fred Smith Fred dot Smith. It's an alias, it goes to Fred at PDQ calm. Why do you want to do that? If Fred leaves, you can report that to yourself to catch the last of the traffic from his account. If you need to log in to reset or you need to log in to get access, you know what he used. So that's one other company policy.

You might you might use. last suggestion about passwords. I am I'm a longtime really long time 567 years I think user of a utility called one password. I'm not going to show you one password in action because it's mine. It's got thousands of records and obscuring them all would kind of wipe out your experience of the user interface. This is the site for one password agile bits comm Mac windows and In mobile devices, one password does a couple of things.

It remembers the username, password, and possibly address credit card those kind of details if you want it to, and it will actually autofill those. For example here, I talked about Twilio and I was talking about telephony. If I jump onto the Twilio sign in page and it wants the username and password, I can click one password, it's going to feed it the password. Notice it's Twilio, it's a visually calm, and boom, we're in. The really cool thing about one password is they've used the Dropbox, technology Dropbox as a platform. So the previous lesson and built one password clients for iPhone, iPad, Android, and those will sync synchronize with your desktop back and forth.

So I keep all these passwords on my desktop. In addition to secure nodes, credit card records, being scription is top notch, that's actually synchronized without being decrypted with my phone with my iPad. So if I go, oh my gosh, what was the password for such and such, if I can't guess it from a consistent schema, I've actually got that thing there with me. There are systems that force, a regular change of passwords, one passwords really, really handy in that scenario, as well. And I suppose if I got hit by a bus, my business partner knew my password into one password, he then be able to recover all of the stuff accounts, etc, that I log into on a regular basis. It's actually quite an important record.

If you think about it. There's an earlier Windows app called roboform. I used it 10 years ago or so. It was terrific at the time. One password started on the Mac, there was no roboform on the Mac roboform may still be in existence, it's probably worth checking out. But these guys at agile beta Are is terrific.

They're just a terrific company. They keep advancing their technology. They keep up with stuff like iPhone, Android, Dropbox, and I'm very impressed with him. So passwords are a company asset. I can't emphasize that strongly enough. And security is are terrifically important thing.

If you're going to be cloud and virtual base, you want to keep stuff locked down. But you don't want to keep everyone locked out. This approach, consistent strong password, and a letter and a shift a place letter and a shift kind of balances off security of a single system versus the frustration of having to remember lots of different things. It's very useful. I hope you find it useful. That's it.

Thanks.