1Password is a password manager. Ideally you memorize one strong password - hence the name - and let 1Password generate and manage strong, unique passwords for every site for which you have a login.
Following this guide, it will be helpful to understand a few terms we'll be using throughout.
1Password can be used in two different ways - as a standalone application (by purchasing a standalone license) or as a hosted service (by subscribing). GitLab uses 1Passwords for Teams which is a hosted service.
If you want to use 1Password for your private passwords not related to your work at GitLab, there are a few options.
1Password for Teams stores all Vaults on the 1Password servers and allows for sharing between multiple people on the same team.
Everyone at GitLab should already be signed up for our Teams account. This gives you access to the web interface, allowing you to view the Vaults we've configured and given you access to.
In addition to the shared Team vault, each member of the team has a vault called Personal which only you can see, and allows you to store personal credentials within our team's account. See the Google sheet titled "1Password Shared Folders" in Google Drive to see a listing of the available vaults and which groups or individuals have access to them. If you need access to a vault beyond the access that your onboarding process already gave you, please make a comment in the sheet and ping one of the 1Password admins in the comment. A listing of the 1Password admins can be found in a secure note in the Team vault in 1Password.
To really get the full benefit of 1Password, you'll need to hook our Teams account up to one of the native apps.
This guide will cover setting up the OSX app. It's their lead platform and is the most up-to-date. These instructions may or may not work for the Windows version.
Now you'll need the Emergency Kit PDF that 1Password told you to save when you registered your Teams account. Note: Store the Emergency Kit safely. Store a copy of the Emergency Kit on a USB flash drive or print a copy and store it in a vault at home or safe deposit box — somewhere not online or accessible by anyone other than yourself.
If you saved it as a digital PDF file:
If you printed the PDF:
After the Team is added, you should see some notifications about vaults being added to 1Password. By default you'll have Team and Personal, and may have access to others.
Read this section only if you could not follow the instructions in "Adding the GitLab Team to a 1Password app" section.
Because the Teams feature is not available in your current version of 1Password, we need to update the app to the latest version:
Click the Vault Selector in the upper-left corner of the window:
Team is a vault that everyone on the GitLab Teams account has access to, both read and write.
Personal is your hosted, private vault that is part of the GitLab 1Password for Teams account. Since the Personal vault is part of the GitLab Teams account, it should be thought of as company property (like the @gitlab.com email account), however the vault can not be viewed by anyone else on the team, including admins. If you choose to store truly personal information in the Personal vault, it opens up the possibility that you would be separated from this information if you offboard. Such truly personal information is therefore better to store in your Primary vault, which is associated with you instead of with the GitLab Teams account, assuming that you added an individual account.
Go to Browser extensions and install the extension for whatever browser you're using. You should not need a beta version here.
With the extension installed, you should be able to go to a site that has credentials stored in our Team vault and log in:
If you don't see the site listed in the results window, make sure you're using the correct vault:
When 1Password detects a login form submission, it may ask if you want to save the login with a dialog like this:
If you do want to save it, make sure the appropriate Vault is selected first.
Please refer to 1Password FAQ.
If you are planning to use both the GitLab team account and a separate individual account you should first add your separate individual account to the app first (Preferences > Accounts). By doing this you will be able to unlock the 1Password app using the Master Password of the individual account.
If you were using 1Password before joining GitLab, and you receive a prompt titled Migrate To Account, choose I'll move later. There is no harm in doing this, and it is easy to move items between vaults.
You are encouraged to use 1Password for your private passwords, not related to your work at GitLab. This makes it less likely for a security breach to occur. You can purchase a standalone license or start an individual subscription. While under the GitLab team subscription, it is also possible to create and use a 'Personal' vault (same features of a standalone license, without the cost, but you will lose access if you go through offboarding).
Please bear in mind that if you decide to purchase a standalone license or create a personal local vault, your data is stored only in a local folder on your computer. You can optionally sync this folder to Dropbox or iCloud (if you are using a Mac/iOS) to make it available on your phone's 1Password app, or on another computer.
Signing up for a subscription seems to be the solution now recommended by AgileBits (the company behind 1Password).
To create a personal local vault:
There are several ways to get your Two Factor Authentication (2FA) codes. You can get them sent via SMS or use an app like Google Authenticator to generate them. 1Password provides an alternative solution that does not require using your smartphone: 1Password Time-based One Time Passwords (TOTP). 2FA codes are displayed directly in the 1Password app running on your laptop.
To enable TOTP for a saved account:
Please refer to the 1Password blog for more information on how TOTP works.
If scanning the QR code using the "transparent window" with the 1Password Mac app fails on a recent Mac OS, please consider using the 1Password iOS app instead. This can the same, and supports Touch ID to login.
This is an example of how Robert, one of our developers, uses 1Password:
Once you fully commit to using 1Password to manage all of your security information, it really does make life easier.
I memorize one strong password and let the app generate everything else. Every site I use has a unique password that I can't compromise because I don't even know it, and a hacked site can't compromise it because the password is never re-used on another site.
I store my shipping and credit card info in 1Password and use the browser extension to quickly fill out shipping and billing information on shopping sites.
I store my passport data, along with a digital scan, in 1Password; drivers license info and scan; insurance info; software license keys; any important information that needs to be secure but still easily accessible when I need it, from anywhere. I sync my personal vault to my personal Dropbox so it's available on my phone, tablet, laptop, and desktop.
Even my 1Password for Teams account information is stored in my personal Primary vault, with the Emergency Kit PDF as a secure attachment:
I have no idea what the password is. I've never actually typed it. And that's the idea.
When traveling with a device that has access to the GitLab 1Password vaults, be sure to enable Travel Mode in 1Password. Travel Mode removes copies of any 1Password vaults that are not tagged as "safe for travel" from your mobile devices. None of the GitLab team vaults are marked as safe for travel so you will need to either create a dedicated travel vault or mark your personal vault as safe for travel.
Once you have enabled Travel Mode open 1Password on each device you will be taking with you so that it can sync with 1Password.com and remove any vaults that cannot be used while traveling.
For more information on Travel Mode and how it works, see the AgileBits blog.
During your first two weeks at GitLab you should receive an email with links to Security Awareness Training as part of the onboarding process. This training covers how to recognize phishing attacks, how to safely use public wireless networks, and some general security tips and principles.
GitLab conducts routine phishing tests using a third-party testing platform. All team members will occasionally receive emails that are designed to look like legitimate business-related communications but will in actuality be simulated phishing attacks. Real phishing attacks are designed to steal credentials or trick the recipient into downloading or executing dangerous attachments. No actual attempts will be made by GitLab or the third-party testing site to steal credentials or execute malicious code.
The goal of these campaigns is not to catch people clicking on dangerous links or punish those who do, but rather to get people thinking about security and the techniques used by attackers via email to trick you into running malicious software or disclosing web passwords. If you fall victim to one of these simulated attacks feel free to take the training courses again or to ask the security team for more information on what could've been done to recognize the attack. What you shouldn't do is feel any shame for having clicked on the link or entered any data, nor should you feel like you need to cop to the security team and let them know you made a mistake. Making a mistake online is practically the reason the Internet was invented.
When you receive an email with a link, hover your mouse over the link or view the source of the email to determine the link's true destination.
If you hover your mouse cursor over a link in Google Chrome it will show you the link destination in the status bar at the bottom left corner of your browser window.
In Safari the status bar must be enabled to view the true link destination (View -> Show Status Bar).
Some examples or methods used to trick users into entering sensitive data into phishing forms include:
When viewing the source of an HTML email it is important to remember that the text inside the "HREF" field is the actual link destination/target and the text before the
</A> tag is the text that will be displayed to the user.
<a href="http://evilsite.example.org">Google Login!</a>
In this case, "Google Login!" will be displayed to the user but the actual target of the link is "evilsite.example.org".
After clicking on a link always look for the green lock icon and "secure" label that signify a validated SSL service. This icon alone is not enough to verify the authenticity of a website, however the lack of the green icon does mean you should never enter sensitive data into that website.
Whether you believe that you have received an email from our testing platform or you believe you have received a real phishing attempt, the best thing to do is to delete the email. GMail also offers the option to report the email directly to Google as a phishing attempt which will result in its deletion. If you suspect that the email is targeted specifically at you or GitLab, please notify the security team so it can be investigated. You can also notify other team members via Slack. If you forward the phishing email to the security team please do so as an attachment and not inline. To forward the email as an attachment from inside GMail:
If you receive an email that appears to come from a service that you utilize, but other details of the email are suspicious – a private message from a sender you don't recognize, for example – do not click on any links in the email. Instead use your own bookmark for the site or manually type the address of the website into your browser.
GitLab provides a
email@example.com email address for team members to use in situations that require an immediate security response. Should a team member lose a device such as a thumb drive, Yubikey, mobile phone, tablet, laptop, etc. that contains their credentials or other GitLab-sensitive data they should send an email to
firstname.lastname@example.org right away. When the production and security teams receive an email sent to this address it will be handled immediately. Using this address provides an excellent way to limit the damage caused by a loss of one of these devices.
The following can be adapted depending on the specific situation at hand, but when in doubt: block. It is less risky to reinstate accounts and permissions than to be confronted with a malicious actor gaining access.
Copy this checklist into a confidential issue.
- [ ] Password Access and Rotation - [ ] Suspend 1Password account. (All responders to `panic@` should be members of the "Panic@ Responders" group in 1Password which has the rights to suspend and recover user accounts). - [ ] Take screenshot of what groups / vaults the individual had access to. This facilitates the next step. - [ ] Coordinate or actively change sensitive shared passwords. In particular sysadmin access passwords for GitLab.com Infrastructure (ssh, chef user/key, discuss others). - [ ] Block Google account - [ ] Block Slack account - [ ] Block [dev.GitLab.org account](https://dev.gitlab.org/admin/users). - [ ] Remove GitLab.com account from the [gitlab-org group](https://gitlab.com/groups/gitlab-org/group_members) - [ ] Block access to hackerone.com - [ ] Block access to Tweetdeck