Overview
The application uses a passcode you provide and a secure salt value for each account you have in order to create a unique hash value for each site. A unique hash value for each site forms the basis for a unique and secure password, which in turn protects you if the security of one or several sites is breached sometime in the future, because none of your other sites will have the same password. And, the application makes these available to you after you have authenticated, so that you don't have to remember them or write them down (both of which can be problematic).
Authentication into Rosetta Salt
The application itself uses 2FA (2 Factor Authentication) or MFA (Multi-Factor Authentication). As a user, you will first authenticate with your email address and a password with the AWS Cognito service for Rosetta Salt. Then, you will request a translate token from Rosetta Salt and then authenticate yourself by providing a claim value that was sent to your email address by Rosetta Salt, proving that you still have access to your email account.
Once you have passed through these two phases of authentication, you will have a token from AWS Cognito and another from Rosetta Salt. At present, the AWS Cognito token can be refreshed for up to 30 days, meaning that you will normally only need to perform the first phase of authentication once a month, for each particular client/device that you use. And, also at present, the Rosetta Salt token is valid for 12 hours from the time you request it, meaning that you will normally only need to request a new Rosetta Salt token at the start of each day that you use it.
With these two phases of authentication, the two tokens that your clients/devices receive, and their different lifecycles, Rosetta Salt is trying to balance the need to keep your information secure with the desire to get in to the application, to get to the particular site information you need, and then log in to that particular site and do whatever you need to do there. We want to make it easy for you to get the information you need and then to get out of the way, and at the same time make it difficult or impossible for others to get to your information.
Separation of password parts
As mentioned above, a passcode that you provide and a site specific salt value that Rosetta Salt maintains for you are combined to form a site specific hash value, which in turn forms the basis for your site specific password. But, these two parts that form the basis for your site specific password are kept separate, except when you bring them together at "runtime." And the reason that they are normally kept separate is to make it harder for an adversary to gain access to all of your passwords...both parts are necessary to create the proper site specific passwords and these parts cannot be reverse engineered from a site password that is obtained from a breached site (more on that below).
The passcode that you provide is never persisted on the client/device and it is never transmitted across a network. Instead, the hash value for this passcode is persisted on the client/device, so that the application can help you to know when you have re-entered it correctly. But, you are required to enter it at the beginning of each session/day. Because it is never persisted, an adversary cannot obtain it from the storage on your device. Instead, if they are going to obtain it, they will need to obtain it from the application's memory. That is not impossible for an adversary, but, the operating system of the client/device is responsible for protecting the memory and it is generally more difficult than obtaining information from permanent storage.
The site specific salt values that Rosetta Salt maintains for you are stored in an AWS database and are only accessible with a valid Rosetta Salt token that is presented to RESTful operations deployed in the AWS API Gateway. The AWS database is encrypted at rest, which means that even if somebody were able to get the information from the persistent storage for the database, they would not be able to decrypt it. Additionally, each Rosetta Salt token that is issued has its own private key, which makes it very difficult and time consuming (and practically impossible) for an adversary to forge a token and impersonate a valid client/device token. Finally, a site specific salt value is only transmitted across a secure channel (HTTPS) and is only transmitted when it is needed at runtime, so that it can be combined with the passcode that you provide. It is never persisted on the client/device, even though one could make a case that that could be useful for offline operation of the application.
Again, the purpose for distributing these two parts (the passcode you provide and the site specific salt values that Rosetta Salt maintains for you) is to make it more difficult for an adversary to steal your site specific passwords. In order to do so, they would either need to breach both the Rosetta Salt site salt information and the memory of one of the clients/devices that you use or they would need to breach the security of all of your sites.
Why hash functions?
You might reasonably ask why Rosetta Salt uses hash functions to derive site specific passwords like this, rather than using encryption to store your site specific passwords in your browser and/or on your phone and/or on a password manager server in the cloud, as is common amongst other password managers.
The primary reason for not using encryption and decryption is that that approach would result in your site passwords being stored in multiple places. For example, with the encryption approach, your amazon.com password would be stored somewhere within amazon.com itself and would also be stored in at least one and possibly all of these other places: your phone(s), your browser(s), and your password manager server(s) (if applicable). And, although your site passwords should be safe in these several/many places because they are encrypted, the facts that they are in many places and that they are persisted in storage increases the probability that the information in one of these places will be breached.
In contrast and as described above, Rosetta Salt keeps the parts that are necessary to form your site specific hash values separate from one another, and only brings them together for a short period of time (for example, for a few seconds when you need them in order to log in to amazon.com). Because of this approach, your site specific passwords are only stored somewhere in the sites themselves (if they are stored there at all...modern sites will only store the hash value for your password, rather than the password itself).
A secondary reason for not using encryption and decryption is that the breach of one of your sites might make the set of your encrypted passwords more vulnerable. For example, if your amazon.com password is somehow breached, this might make it easier for an adversary to reverse-engineer an encrypted set of passwords that they had somehow obtained from one of your clients/devices. Encryption and decryption are two-way functions...information is encrypted with a secret key and then that same secret key is used to decrypt the information.
In contrast, hash functions are one-way functions. What this means practically is that if one of your sites is breached and they happen to store your password directly (rather than its hash value), the adversary will not be able to reverse-engineer the two parts in Rosetta Salt that were used to form your password. In particular, they will not be able to reverse-engineer the passcode that you provide, which could otherwise unlock all of your site passwords if they were also somehow able to obtain all of your site salt values from Rosetta Salt.