BriceShatzer/final.html

## final.html
<html>
  <h3>Question:</h3>
  <p>Looking for advice for the small web agency that I work for. There's five of us so were a small team and want to set mature processes in place while we are still small. We would like to improve our security in regards to user access management.</p>
  <p>We're looking at a scenario where we may need to revoke an employee's access to multiple client sites and access to subscriptions like Moz, etc. We have approximately 40+ client sites which each designer has access to via a CMS login like Wordpress or Drupal.</p>
  <p>Any thoughts on the topic or examples of how your organization handles user access management?</p>
<hr>
  <h3>Answer:</h3>

<em>TL;DR:</em>
<ul>
    <li>Generate a new unique password for everything always. </li>
    <li>Adopt a password manager that has a paid team component to store and share passwords across the team.</li>
    <li>Use groups within the password manager to somewhat compartmentalize the things shared.</li>
    <li>Be ok with ex-employees possibly still having access to things until you explicitly revoke or change the passwords. </li>
</ul>
<p>Hopefully you're already doing the basic and universally acknowledged best practice around passwords of always generating a new and unique password for each login. This should include individual user and/or test accounts that your employees make for individual client websites. If the site they are working on can be accessed publicly, implore the use unique, randomly generated passwords for each one, even if it will only ever exist as a test/demo/stagging site. This practice becomes a really easy habit when you start using a password manager, another <a href="http://thewirecutter.com/blog/password-managers-are-for-everyone-including-you/" target="_blank">universally acknowledged best practice</a>.</p>
<p> Getting into the overall organizational challenges, I would say that you are at about the right size to start seriously looking into the paid team/group component that most password managers offer. The agency I work at uses 1Password, but LastPass and others all offer something similar so my thoughts on the topic are fairly universal.</p>
<p>The basic idea is that within those team/group plans, each user has an account under the org's umbrella account. Users can securely share passwords with each other which is helpful if two or more people are working on a project together. Groups of passwords can also be setup that are shared with some or all of the accounts within the org. </p>
<p>
For example, we have a couple of different groups set up:
<ul>
    <li><strong>Admin</strong> - Basically any account that has users under it (Creative Cloud, PipeDrive, Slack) or needs get paid (phone, internet, security company). Shared with the people who pay bills and/or run things.</li>
    <li><strong>Hosting/Ops</strong> - Service provider & registrar accounts (Digital Ocean, AWS, WPEngine, etc). Shared with senior devs and a couple of admin/pm type people who need it for billing purposes.</li>
    <li><strong>General</strong> - Things that everybody has access to. Stuff like the different WiFi passwords or our shared BrowserStack account.</li>
</ul>
We could probably do a better job of separating out some of the stuff in General into a Design category as our devs probably don't need access to any of the credentials for the various stock photo or type foundry sites that are in there, but you get the idea.
</p>

<p>Individual user accounts within the org can be revoked, so when someone leaves they no longer have access to any of the logins stored or shared with that account. While this doesn't prevent them being able to use memorized passwords to log into things, the likelihood of them being able to remember that the unique and randomly generated password of <samp>r60TCjk!*6Bh</samp> was the password to a particular site or service is probably not a thing they are going to be able to do. Unfortunately, the only way to truly guarantee that someone who had access to a site or service at one point no longer has that access is to change the credentials that allowed that access. This is especially true as browsers have recently become significantly more enthusiastic about wanting to hang onto passwords for users. The silver lining is that if you do have a password to something that you need to change because you explicitly don't want a former employee to have access, if it was shared via a group you simply need to update the password in there and everyone that has access to the group now has the new password.
</p>
<p>Personally, in the 8ish years I've been doing this sort of work, I've found that people don't behave maliciously when they leave, even when it's under the worst of terms.
This make sense when you consider that there is very little incentive for that sort of behavior. Even if they did throw a tantrum and do the digital equivalent of spray-painting some parting words on the break room wall, version control & db backups make erasing any damage trivial.</p>
<p>That being said, what I have seen or heard about are former employees using accounts for paid services that they still have access to. Things like using our shared BrowserStack account to QA something they're working on or using an endpoint(public but not for the public) that we had setup for something in a personal project. This sort of stuff tends to be pretty benign, but with access to metered tools like AWS or Digital Ocean that behavior does have a potential to create a financial impact. </p>
<p>This is where the idea of using password groups within a team/group password manger becomes appealing. It allows you to compartmentalizing access to things.
That way if someone leaves and you want to ensure they don't have access to anything, you only need to change the credentials within the groups they had access to, rather than having to change credentials to everything.</p>
<p>Hopefully there is something helpful in that wall of text :) <br>
Feel free to reach out to me on here or <a href="http://briceshatzer.com" target="_blank">directly</a> with any comments or questions.</p>
<p>One final, somewhat related piece of advice that I have, that I wish we had followed:<br>
When setting up credentials for accounts, tools, services, etc. that are shared by multiple members of the organization, use a standardized and universally acknowledged set of information (username, email, first/last name, address) during creation, and work incessantly to get existing stuff you have to use this standardized information. This will save you from an absurd amount of headaches in the future which include minor annoyances like having to ask 5 different people if they got a password reset email, fairly big embarrassments like missing emails about expiring domains & subscriptions, or even potentially <a href="https://www.quora.com/My-AWS-account-was-hacked-and-I-have-a-50-000-bill-how-can-I-reduce-the-amount-I-need-to-pay" target="_blank">company-ending disasters.</a></p>
<p>We haven't had anything disastrous happen to us yet, but I have spent more time than I care to admit tracking down credentials to a GoDaddy account that was setup sometime near the end of the Clinton administration. ಠ_ಠ</p>

</html>

## rough
<html>
<em>TL;DR:</em>
<ul>
    <li>Generate a new unique password for everything always. </li>
    <li>Adopt a password manager that has a paid team component to store and share passwords across the team.</li>
    <li>Use groups within the password manager to somewhat compartmentalize the things shared.</li>
    <li>Be ok with ex-employees possibly still having access to things until you explicitly revoke or change the passwords. </li>
</ul>
<p>Hopefully you're already doing the basic and universally acknowledged best practice around passwords of always generating a new and unique password for each login. This should include individual user and/or test accounts that your employees make for individual client websites. If the site they are working on can be accessed publicly, implore the use unique, randomly generated passwords for each one, even if it will only ever exist as a test/demo/stagging site. This practice becomes a really easy habit when you start using a password manager, another <a href="http://thewirecutter.com/blog/password-managers-are-for-everyone-including-you/" target="_blank">universally acknowledged best practice</a>.</p>
<p> Getting into the overall organizational challenges, I would say that you are at about the right size to start seriously looking into the paid team/group component that most password managers offer. The agency I work at uses 1Password, but LastPass and others all offer something similar so my thoughts on the topic are fairly universal.</p>
<p>The basic idea is that within those team/group plans, each user has an account under the org's umbrella account. Users can securely share passwords with each other which is helpful if two or more people are working on a project together. Groups of passwords can also be setup that are shared with some or all of the accounts within the org. </p>
<p>
For example, we have a couple of different groups set up:
<ul>
    <li><strong>Admin</strong> - Basically any account that has users under it (Creative Cloud, PipeDrive, Slack) or needs get paid (phone, internet, security company). Shared with the people who pay bills and/or run things.</li>
    <li><strong>Hosting/Ops</strong> - Service provider & registrar accounts (Digital Ocean, AWS, WPEngine, etc). Shared with senior devs and a couple of admin/pm type people who need it for billing purposes.</li>
    <li><strong>General</strong> - Things that everybody has access to. Stuff like the different WiFi passwords or our shared BrowserStack account.</li>
</ul>
We could probably do a better job of separating out some of the stuff in General into a Design category as our devs probably don't need access to any of the credentials for the various stock photo or type foundry sites that are in there, but you get the idea.
</p>

<p>Individual user accounts within the org can be revoked, so when someone leaves they no longer have access to any of the logins stored or shared with that account. While this doesn't prevent them being able to use memorized passwords to log into things, the likelihood of them being able to remember that the unique and randomly generated password of <samp>r60TCjk!*6Bh</samp> was the password to a particular site or service is probably not a thing they are going to be able to do. Unfortunately, the only way to truly guarantee that someone who had access to a site or service at one point no longer has that access is to change the credentials that allowed that access. This is especially true as browsers have recently become significantly more enthusiastic about wanting to hang onto passwords for users. The silver lining is that if you do have a password to something that you need to change because you explicitly don't want a former employee to have access, if it was shared via a group you simply need to update the password in there and everyone that has access to the group now has the new password.
</p>
<p>Personally, in the 8ish years I've been doing this sort of work, I've found that people don't behave maliciously when they leave, even when it's under the worst of terms.
This make sense when you consider that there is very little incentive for that sort of behavior. Even if they did throw a tantrum and do the digital equivalent of spray-painting some parting words on the break room wall, version control & db backups make erasing any damage trivial.</p>
<p>That being said, what I have seen or heard about are former employees using accounts for paid services that they still have access to. Things like using our shared BrowserStack account to QA something they're working on or using an endpoint(public but not for the public) that we had setup for something in a personal project. This sort of stuff tends to be pretty benign, but with access to metered tools like AWS or Digital Ocean that behavior does have a potential to create a financial impact. </p>
<p>This is where the idea of using password groups within a team/group password manger becomes appealing. It allows you to compartmentalizing access to things.
That way if someone leaves and you want to ensure they don't have access to anything, you only need to change the credentials within the groups they had access to, rather than having to change credentials to everything.</p>
<p>Hopefully there is something helpful in that wall of text :) <br>
Feel free to reach out to me on here or <a href="http://briceshatzer.com" target="_blank">directly</a> with any comments or questions.</p>
<p>One final, somewhat related piece of advice that I have, that I wish we had followed:<br>
When setting up credentials for accounts, tools, services, etc. that are shared by multiple members of the organization, use a standardized and universally acknowledged set of information (username, email, first/last name, address) during creation, and work incessantly to get existing stuff you have to use this standardized information. This will save you from an absurd amount of headaches in the future which include minor annoyances like having to ask 5 different people if they got a password reset email, fairly big embarrassments like missing emails about expiring domains & subscriptions, or even potentially <a href="https://www.quora.com/My-AWS-account-was-hacked-and-I-have-a-50-000-bill-how-can-I-reduce-the-amount-I-need-to-pay" target="_blank">company-ending disasters.</a></p>
<p>We haven't had anything disastrous happen to us yet, but I have spent more time than I care to admit tracking down credentials to a GoDaddy account that was setup sometime near the end of the Clinton administration. ಠ_ಠ</p>
</html>


+++++++++++++++++

TL;DR:

Generate a new unique passwords of everything always.
Adopt a password manager that has a paid team component to store and share passwords across the team.
Use groups within the password manager to somewhat compartmentalize the things shared.
Be OK with ex-employees possibly still having access to things until you explicitly revoke or change the passwords.


Hopefully you're already doing the basic and universally acknowledged best practice around passwords of always generating a new and unique password for each login.
This should include individual user and/or test accounts that your employees make for individual client websites. If the site they are working on can be accessed publicly, implore the use unique, randomly generated passwords for each one, even if it will only ever exist as a test/demo/stagging site.
This practice becomes a really easy habit when you start using a password manager, another universally acknowledged best practice.

Getting into the overall organizational challenges, I would say that you are at about the right size to start seriously looking into the paid team/group component that most password managers offer. The agency I work at uses 1Password, but LastPass and others all offer something similar so my thoughts on the topic are fairly universal.

The basic idea is that within those team/group plans, each user has an account under the org's umbrella account. Users can securely share passwords with each other which is helpful if two or more people are working on a project together. Groups of passwords can also setup that are shared with some or all of the accounts within the org.

For example, we have a couple of different groups set up:
Admin - Basically any account that has users under it (Creative Cloud, PipeDrive, Slack) or needs get paid (phone, internet, security company). Shared with the people who pay bills and/or run things
Hosting/Ops - Service provider & registrar accounts (Digital Ocean, AWS, WPEngine, etc). Shared with senior devs and a couple of admin/pm type people who need it for billing purposes
General - Things that everybody has access to. Stuff like the different WiFi passwords or our shared BrowserStack account.

We could probably do a better job of separating out some of the stuff in General into a Design category as our devs probably don't need access to any of the credentials for the various stock photo or type foundry sites that are in there, but you get the idea.


Individual user accounts with the org can be revoked, so when someone leaves they no longer have access to any of the logins stored or shared with that account.

While this doesn't prevent them being able to use memorized passwords to log into things, the likelihood of them being able to remember that 'r60TCjk!*6Bh' was the password to a particular site or service is probably not a thing they are going to be able to do.


Unfortunately, the only way to truly guarantee that someone who had access to a site or service at one point no longer has that access is to change the credentials that allowed that access. This is especially true as browsers have become significantly more enthusiastic about wanting to hang onto passwords for users.

The silver lining is that if you do have a password to something that you need to change because you explicitly don't want a former employee to have access to, if it was shared in via a group you simply need to update the password in there and everyone that has access to the group now has the new password.


Personally, in the 8ish years I've been doing this sort of work, I've found that people don't behave maliciously when they leave, even when it's under the worst of terms.
This makes a sense you consider that there is very little incentive for that sort of behavior. Even if they did throw a tantrum and do the digital equivalent of spray-painting some parting wisdom on the break room wall, version control & db backups make erasing any damage trivial.

That being said, what I have seen or heard about are former employees using accounts for paid services that they still have access to.
Things like using our shared BrowserStack account to QA something they're working on or using an endpoint(public but not for the public) that we had setup for something in a personal project. This sort of stuff tends to be pretty benign, but with access to metered tools like AWS or Digital Ocean that behavior does have a potential to create a financial impact.

This is where the idea of using password groups within a team/group password manger becomes appealing. It allows you to compartmentalizing access to things.
That way if someone leaves and you want to ensure they don't have access to anything, you only need to change the credentials within the groups they had access to.


Hopefully there is something helpful in that wall of text :)

Feel free to ask reach with any questions either on here or to me directly.


One final, somewhat related piece of advice that I have, that I wish we had followed:

When setting up credentials for accounts, tools, services, etc. that are shared by multiple members of the organization, use a standardized and universally acknowledged set of information (username, email, first/last name, address) during creation, and work incessantly to get existing stuff you have to use this standardized information. This will save you from an absurd amount of headaches in the future which include
minor annoyances like having to ask 5 different people if they got a password reset email,
fairly big embarrassments like missing emails about expiring domains & subscriptions,
or even potentially company-ending disasters (https://www.quora.com/My-AWS-account-was-hacked-and-I-have-a-50-000-bill-how-can-I-reduce-the-amount-I-need-to-pay)


We haven't had anything disastrous happen to us yet, but I have spent far to much of time trying to track down credentials to a GoDaddy account that was setup sometime near the end of the Clinton administration. ಠ_ಠ


--


For logins to
I do have a big piece of advice that really wish we would have followed.

When setting up those sorts of accounts,

--


Ex-employees doing stuff like using our shared BrowserStack account to QA something they're working on or using an endpoint(public but not for the public) that we had setup for something in a personal project.
Most of this behavior tends to be pretty benign, like using our shared BrowserStack account to QA a freelance project they were working on,

for them to do anything malicious to your or a client's site.
they tend to be professional  ()

In general you should already be using some sort of password manager software
(http://www.howtogeek.com/141500/why-you-should-use-a-password-manager-and-how-to-get-started/)
(http://thewirecutter.com/blog/password-managers-are-for-everyone-including-you/)

You should already be using some sort of password manager software in general, but you're organization is at about the right size to start giving seriously looking into the paid team/group component that most offer. The agency I work at uses 1Password, but LastPass and others all offer something similar so my thoughts on the topic are fairly universal.


The


Using

and


That being said,

browsers have become significantly more enthusiastic about wanting to hang onto passwords for users,
so it's probably a good idea to make piece with the idea that


As far as individual user and/or test accounts that your employees make for individual client websites, the best practice of always generating a new and unique
If the site they are working on can be accessed publicly, implore the use unique, randomly generated passwords for each one, even if it will only ever exist as a test/demo/stagging site.
As for passwords in general, always generate


==
A general piece of advice that I have, that I wish we'd follow


For logins to accounts, tools, services, etc. that are shared by multiple members of the organization, I do have a big piece of advice that really wish we would have followed.

When setting up those sorts of accounts, use a standardized and universally acknowledged set of information (username, email, first/last name, address) during creation, and work incessantly to get existing stuff you have to use this standardized information. This will save you from an absurd amount of headaches in the future which include
minor annoyances like having to ask 5 different people if they got a password reset email,
fairly big embarrassments like missing emails about expiring domains & subscriptions,
or even potentially company-ending disasters (https://www.quora.com/My-AWS-account-was-hacked-and-I-have-a-50-000-bill-how-can-I-reduce-the-amount-I-need-to-pay)


We haven't had anything disastrous happen to us yet, but I have spent far to much of time trying to track down credentials to a GoDaddy account that was setup sometime near the end of the Clinton administration. ಠ_ಠ
==


W


As far as individual user and/or test accounts that your employees make for individual client websites, the best practice of always generating a new and unique

If the site they are working on can be accessed publicly, implore the use unique, randomly generated passwords for each one, even if it will only ever exist as a test/demo/stagging site.


As for passwords in general, always generate


One important piece of advise:


For logins to accounts, tools, services, etc. that are shared by multiple members of the organization, there is one piece of advice that

use a standardized and universally acknowledged set of information (username, email, first/last name, address) during creation, and work incessantly to get existing stuff you have to use this standardized information. This will save you from an absurd amount of headaches in the future which includes everything thing from minor annoyances like having to ask 5 different people if they got a password reset email,
fairly big embarrassments like missing emails about expiring domains & subscriptions,
to potentially company-ending disasters (https://www.quora.com/My-AWS-account-was-hacked-and-I-have-a-50-000-bill-how-can-I-reduce-the-amount-I-need-to-pay)


  go-to-meeting, browserstack, etc. )

 shared with everybody


with 5 people you're probably right at the)
We use 1Password, although it appears LastPass, and others have similar services available, so the advice is fairly generic.


Personally, I've found that when people leave (even when it's under )


There is very little incentive for them to do anything malicious to your or a client's site.
Even if they did throw a tantrum and do the digital equivalent of spray-painting some parting wisdom on the break room wall, version control & db backups make erasing any damage trivial.


They're far more likely to walk out with a laptop
What
done from a backup is trivial.
would be reverted with

There's not It's the
If


Generally speaking, when somebody leaves
even co-workers that depart under the burning


what is far more likely, is occasionally using a paid services


Using a

It allows


1password


Generating

Ideally you should get into the habit of generating a unique password for each site.


For logins to accounts, tools, services, etc. that are shared by multiple members of the organization,

use a standardized and universally acknowledged set of information (username, email, first/last name, address) during creation, and work incessantly to get existing stuff you have to use this standardized information. This will save you from an absurd amount of headaches in the future which includes everything thing from minor annoyances like having to ask 5 different people if they got a password reset email,
fairly big embarrassments like missing emails about expiring domains & subscriptions,
to potentially company-ending disasters (https://www.quora.com/My-AWS-account-was-hacked-and-I-have-a-50-000-bill-how-can-I-reduce-the-amount-I-need-to-pay)


Those


While passphrases are easier to remember and usually more secure (due to length)
having them being something that can be easily remembered for

Using a the team service like 1Password or LastPass


the browser attachment


browsers have become significantly more enthusiastic about wanting to hang onto passwords for users,
so it's probably a good idea to make piece with the idea that

removing


an employee leaves
removing their accounts access to the shared


As far as user and/or test accounts that your employees make for individual websites,

If the site they are working on can be accessed publicly, implore the use unique, randomly generated passwords for each one, even if it will only ever exist as a test/demo/stagging site.


,


Reduce unnecessary exposure.
We had an instance a few years ago where a few the old demo/staging sites we had up had been co-opted by some email spammers. The majority of those boxes were for clients we no longer had relationships with or for projects that no longer existed. Those VMs literally had no purpose for existing. The only reason they were still live was simply because no one had thought to go through and look at what was up and taking things down we didn't need.

--------


Simple stuff like having to ask 5 different people if they got a password reset email to catastrophic stuff
like missing emails about expiring domains & subscriptions, unpaid
or usage notifications
and/or failure notifications stuff
 or
creation. This can prevent an absurd amount of headaches
for

(We still run into issues occasionally)
	<html>
	<h3>Question:</h3>
	<p>Looking for advice for the small web agency that I work for. There's five of us so were a small team and want to set mature processes in place while we are still small. We would like to improve our security in regards to user access management.</p>
	<p>We're looking at a scenario where we may need to revoke an employee's access to multiple client sites and access to subscriptions like Moz, etc. We have approximately 40+ client sites which each designer has access to via a CMS login like Wordpress or Drupal.</p>
	<p>Any thoughts on the topic or examples of how your organization handles user access management?</p>
	<hr>
	<h3>Answer:</h3>

	<em>TL;DR:</em>
	<ul>
	<li>Generate a new unique password for everything always. </li>
	<li>Adopt a password manager that has a paid team component to store and share passwords across the team.</li>
	<li>Use groups within the password manager to somewhat compartmentalize the things shared.</li>
	<li>Be ok with ex-employees possibly still having access to things until you explicitly revoke or change the passwords. </li>
	</ul>
	<p>Hopefully you're already doing the basic and universally acknowledged best practice around passwords of always generating a new and unique password for each login. This should include individual user and/or test accounts that your employees make for individual client websites. If the site they are working on can be accessed publicly, implore the use unique, randomly generated passwords for each one, even if it will only ever exist as a test/demo/stagging site. This practice becomes a really easy habit when you start using a password manager, another <a href="http://thewirecutter.com/blog/password-managers-are-for-everyone-including-you/" target="_blank">universally acknowledged best practice</a>.</p>
	<p> Getting into the overall organizational challenges, I would say that you are at about the right size to start seriously looking into the paid team/group component that most password managers offer. The agency I work at uses 1Password, but LastPass and others all offer something similar so my thoughts on the topic are fairly universal.</p>
	<p>The basic idea is that within those team/group plans, each user has an account under the org's umbrella account. Users can securely share passwords with each other which is helpful if two or more people are working on a project together. Groups of passwords can also be setup that are shared with some or all of the accounts within the org. </p>
	<p>
	For example, we have a couple of different groups set up:
	<ul>
	<li><strong>Admin</strong> - Basically any account that has users under it (Creative Cloud, PipeDrive, Slack) or needs get paid (phone, internet, security company). Shared with the people who pay bills and/or run things.</li>
	<li><strong>Hosting/Ops</strong> - Service provider & registrar accounts (Digital Ocean, AWS, WPEngine, etc). Shared with senior devs and a couple of admin/pm type people who need it for billing purposes.</li>
	<li><strong>General</strong> - Things that everybody has access to. Stuff like the different WiFi passwords or our shared BrowserStack account.</li>
	</ul>
	We could probably do a better job of separating out some of the stuff in General into a Design category as our devs probably don't need access to any of the credentials for the various stock photo or type foundry sites that are in there, but you get the idea.
	</p>

	<p>Individual user accounts within the org can be revoked, so when someone leaves they no longer have access to any of the logins stored or shared with that account. While this doesn't prevent them being able to use memorized passwords to log into things, the likelihood of them being able to remember that the unique and randomly generated password of <samp>r60TCjk!*6Bh</samp> was the password to a particular site or service is probably not a thing they are going to be able to do. Unfortunately, the only way to truly guarantee that someone who had access to a site or service at one point no longer has that access is to change the credentials that allowed that access. This is especially true as browsers have recently become significantly more enthusiastic about wanting to hang onto passwords for users. The silver lining is that if you do have a password to something that you need to change because you explicitly don't want a former employee to have access, if it was shared via a group you simply need to update the password in there and everyone that has access to the group now has the new password.
	</p>
	<p>Personally, in the 8ish years I've been doing this sort of work, I've found that people don't behave maliciously when they leave, even when it's under the worst of terms.
	This make sense when you consider that there is very little incentive for that sort of behavior. Even if they did throw a tantrum and do the digital equivalent of spray-painting some parting words on the break room wall, version control & db backups make erasing any damage trivial.</p>
	<p>That being said, what I have seen or heard about are former employees using accounts for paid services that they still have access to. Things like using our shared BrowserStack account to QA something they're working on or using an endpoint(public but not for the public) that we had setup for something in a personal project. This sort of stuff tends to be pretty benign, but with access to metered tools like AWS or Digital Ocean that behavior does have a potential to create a financial impact. </p>
	<p>This is where the idea of using password groups within a team/group password manger becomes appealing. It allows you to compartmentalizing access to things.
	That way if someone leaves and you want to ensure they don't have access to anything, you only need to change the credentials within the groups they had access to, rather than having to change credentials to everything.</p>
	<p>Hopefully there is something helpful in that wall of text :) <br>
	Feel free to reach out to me on here or <a href="http://briceshatzer.com" target="_blank">directly</a> with any comments or questions.</p>
	<p>One final, somewhat related piece of advice that I have, that I wish we had followed:<br>
	When setting up credentials for accounts, tools, services, etc. that are shared by multiple members of the organization, use a standardized and universally acknowledged set of information (username, email, first/last name, address) during creation, and work incessantly to get existing stuff you have to use this standardized information. This will save you from an absurd amount of headaches in the future which include minor annoyances like having to ask 5 different people if they got a password reset email, fairly big embarrassments like missing emails about expiring domains & subscriptions, or even potentially <a href="https://www.quora.com/My-AWS-account-was-hacked-and-I-have-a-50-000-bill-how-can-I-reduce-the-amount-I-need-to-pay" target="_blank">company-ending disasters.</a></p>
	<p>We haven't had anything disastrous happen to us yet, but I have spent more time than I care to admit tracking down credentials to a GoDaddy account that was setup sometime near the end of the Clinton administration. ಠ_ಠ</p>

	</html>