Logging in on website secure and general security?

[Deleted User]

Hi,

isn't logging into the web vault via website possibly dangerous?

Say your server gets compromised and the site suddenly delivers different JavaScript code to say, catch master password and secret key in plain text?

Is this a possibility or does your SRP somehow protect against such a scenario?

Also do you have any plans to increase iteration count or allow it on a user basis? Am used to that from KeePass.

By the way an option to import KeePass.xml would be great without needing to fiddle with csv or using a untrusted converter app.

Which cipher is being used to encrypt Android fingerprint when using it with 1 password? Since it protects my master password it better be strong 😁

Ben

Hi @guidanceseeker

isn't logging into the web vault via website possibly dangerous?

Everything is possibly dangerous. ;) It is important that each individual evaluate the threats they are likely to face and take appropriate steps to mitigate them. Using a password manager is one such step that can help mitigate the threat of password re-use. :)

Say your server gets compromised and the site suddenly delivers different JavaScript code to say, catch master password and secret key in plain text?

Yes, this is a concern. We talk about the associated risks in the "Crypto over HTTPS" section of our security design white paper:

1Password Security Design White Paper

Also do you have any plans to increase iteration count or allow it on a user basis? Am used to that from KeePass.

KeePass is designed for a more technically inclined audience. That isn't to say that 1Password can't or shouldn't be used by technically inclined people, but we are more mindful of the adoption of password managers by a less savvy crowd and as such aren't likely to include such options. That said we do keep up with a balance of PBKDF2 iterations based on currently available hardware, etc:

How PBKDF2 strengthens your Master Password

By the way an option to import KeePass.xml would be great without needing to fiddle with csv or using a untrusted converter app.

I don't disagree at all. This is a problem of number of hours in the day. I'd love to have robust 1st party importers for every platform people might be coming to 1Password from. It is incredibly time consuming to build and maintain such importers though, and there is definitely a point of diminishing returns. The imports can only ever be as good as the exports from the other software, which in many cases are simply not great. As such we have to focus our development time where we can do the most good for the most amount of people.

Which cipher is being used to encrypt Android fingerprint when using it with 1 password? Since it protects my master password it better be strong 😁

We have a guide on fingerprint security with Android here:

About Fingerprint Unlock security in 1Password for Android

I hope that helps. Should you have any other questions or concerns, please feel free to ask.

Ben

[Deleted User]

Thanks for your feedback. Will check the links especially regarding https crypto as this is a definite concern for me.

How many iterations are you using currently. 200.000 it is, right? Seems really low even though I know increasing password length gives more security but still even 2.000.000 is done in like 3 seconds on my mobile.

Perhaps consider switching to something memory hard like argon2id even though that is hard to implement on a Java script basis.

As for 1st party import. Bitwarden does this really good and is open source. Perhaps you can check out their code for KeePass xml import. Worked perfectly.

[Deleted User]

@Ben
P.S let's say your site were to be compromised. What is your policy? Can one assume you would immediately take it down upon realization and notify/warn users not to log in via website?

P.P.S
am on EU server which are in Frankfurt to my knowledge. Is there a geologically off-site backup in case of disaster something at least a few 100 km away and do you suggest to do backup on your own still?

P.P.P.S 😁
if I delete and entry or account, how is it being done. Overwritten by some DoD or Nist standard or just a single delete?

Sorry for all these questions but wanna know as much as I can before entrusting anyone with bank etc stuff

[Deleted User]

Hi,

after trying to understand the white paper I am still not entirely sure.

Do you store a hashed and salted version of the key which derives locally from master password+secret key or not?

I guess you have too otherwise I don't get it 😁

Ben

Hi @guidanceseeker

I've asked our security team to chime in here. Someone should be in touch soon. Thanks!

Ben

[Deleted User]

Thanks

[Deleted User]

@ Ben
what about the job security related questions I had regarding geologically off-site backup and method of data destruction (might be a topic for security team too)

jpgoldberg

Excellent questions, @guidanceseeker!

Web client tampering

Say your server gets compromised and the site suddenly delivers different JavaScript code to say, catch master password and secret key in plain text? Is this a possibility or does your SRP somehow protect against such a scenario?

Yes. That is possible, and it is a legitimate concern. SRP does a lot of magic, but it does not not guarantee the authenticity of the client software itself. Native clients are code signed in various ways, and it would be hard to deliver a malicious client without it being detected, but we do not have such protections for the web-client.

We've been looking at various ways we can reduce the risks, but the biggest thing that users can do is to prefer using the native clients over the web client when they can. We know that there are still some many tasks that can only be performed through the web-client, but we are (slowly) bringing more of that functionality to the native clients. As others mentioned, this is discussed in the Beware of the Leopard section of the 1Password Security Design document

Configurable iterations for PBKDF2

Also do you have any plans to increase iteration count or allow it on a user basis? Am used to that from KeePass.

We may very well increase it (or even move to a memory hard KDF – more on that later), but we do not think that making it user configurable is a good idea. The problem with bumping up iterations is that it gives you diminishing returns. Going from, say, five thousand rounds ("5,000" using English notation with a comma as the thousand separator) to 20,000 would quadruple the work that an attacker has to do. But going from 100,000 rounds (which is where we are today) to 105,000 would make little difference for an attacker. So adding 5,000 rounds gives us less benefit once the numbers get high enough.

Indeed, to get that same quadrupling effect, we'd need to go from 100,000 to 400,000. That is, we would have to increase the work done by the defending system exponentially to force an exponential increase on the attacker. But you can get better than that quadrupling effect by rolling a die (D6) and adding the number that comes up to the end of your password. So with that case, a small increase in work for the defender leads to a large increase in work for an attacker.

This is not to say that slow/hard hashing doesn't have a role. It is essential. But it provides diminishing returns. Once the number is big enough, ramping it up further gives you little increased benefit. I wrote about these diminishing returns a few years back in Bcrypt is great, but is password cracking “infeasible”?

So continuing,

How many iterations are you using currently. 200.000 it is, right?

It's 100,000 (one hundred thousand).

but still even 2.000.000 is done in like 3 seconds on my mobile.

The PBKDF2 part should really be under half a second on most devices. The delay you are experiencing is mostly in just dealing with all of the other decryption and data reading that is need to present you with anything once unlocked.

Discouraging security theater

[200,000] seems really low even though I know increasing password length gives more security

You are a sophisticated user. You know what things like PBKDF2 and Argon2 are for. You also know that increasing password length gives you more security. And still you want to ramp up that up. What that tells us is that if we made the number of iterations user configurable, there are people who would ramp it up to the maximum they could tolerate. They might even take the battery drain and the extra unlock time as giving them a feeling of extra security.

So I'd like to ask you to think to yourself why you'd like to ramp it up. Is it so that you can feel more security by picking a painfully high number? Is it because you would (correctly) take some pride in manipulating some very advanced settings? I can't answer those questions for you, but I feel that some of this stuff is security theater for the security specialist. It's like using 8192 bit RSA keys. It adds no meaningful¹ security, as it ends up only strengthening what is already the strongest part of the system. It really is security theater for geeks.

Now suppose that we still offered such an advanced option. How do we present it to the ordinary user who doesn't know what these numbers mean? We would have our "recommended" setting, but we'd have to say about the higher value settings, "Not recommended. Will eat up your battery for little meaningful security gain." Yet no matter what discouragement we offer, there will be plenty of people who ramp it up.

So instead we don't offer such configuration. The people who know enough to ask for it (like you), we can talk about math and the goal of giving the defender an asymmetric advantage. You might not be happy that I accused you of seeking a geeky kind of security theater, but I hope that upon reflection, you'll recognize it and only be a tiny bit peeved.

Memory hard KDFs

I was somewhat involved in the Password Hashing Competition at the time, and was pleased to see a good winner, Argon2. And I'd long been a user to scrypt in other contexts. Furthermore, I also have some beefs with PBKDF2. So yes, we'd love to use successor of PBKDF2. But ...

The most important thing is that we have efficient, secure and well-optimized KDF implementations available for all of our clients. We avoid writing our own crypto like the plague, and we wish to limit our dependence on third party crypto libraries as well. PBKDF2 comes built in with highly optimized implementations in the standard environments for all of our platforms. Keep in mind, then when some web service switched to something like Argon2, they only have to get that working in one single place, server-side. But we have this in our clients. And we need efficient, optimized implementations in all of our clients before we can offer it in any.

So we've returned to the web-client. PBLDF2 is implemented natively in browsers as part of WebCrypto. Anything else would need to be implement in JavaScript or WebAssembly. The former is way too slow, while the later still can't safely be integrated into web applications. Using web-crypto means enabling "unsafe-eval" for the page.

We also need these things to be very well tested and evaluated. PDKDF2 has plenty of warts that one needs to work around to use safely, but by now these are all known. So we are going to be naturally conservative about adopting new algorithms.

So, yes, I'm confident that we will move to a memory-hard KDF at some point. But it is going to be done carefully, without rushing into anything and when safe tools are available for all clients.

Anyway, thanks for the great questions!

---

1. Back in 2013 I wrote about why increasing key size beyond a certain point adds no meaningful security in Guess why we’re moving to 256-bit AES keys ↩︎

[Deleted User]

@jpgoldberg
Thank you for in-depth reply. Appreciate it and am not peeved at all.

Just want to increase my understanding.

I get your points and indeed just thought a higher iteration count or memory hard function set to a high iteration and memory number too is just giving an extra sense of security even if it is overkill. Just thought that given banking logins, pins, email, signature, passport etc. you can't be safe enough so crank it up.

I am really liking the non auto generated replies here. Is becoming a point which is swaying me more and more to make the move from KeePass to 1password.

Can you perhaps answer also regarding my initial questions about if you have geologically off-site backups for EU server and how you delete data if a user chooses to.

Also you say avoid web client if possible and go native. 1password X on Linux in Chromium would still be considered native correct?

[Deleted User]

@jpgoldberg
P.S in your white paper you are stating that nothing crackable is stored. I don't get that part. You must store some sort of hash to authenticate a user and if that gets stolen it would be something crackable even if it takes millennia.

[Deleted User]

@jpgoldberg
sorry to put a 3rd reply before you had a chance to reply to any of the two above but one more security related question.

Secret key or not an attacker could still try to hit the right hash for the encrypted data. For my understanding the secret key just makes the encryption stronger by adding more entropy but so would using a password the likes of a keyfile, so something around 200 bits of entropy or more.

So even if there were no secret key a password like this is still practically impossible to crack. In such a case the secret key does not really add any more security I guess since the used password is so strong to begin with. Right?

Sorry again for all the questions but would greatly appreciate if you could reply to my last three comments. ,😁

MerryBit

@guidanceseeker wrote:

I am really liking the non auto generated replies here. Is becoming a point which is swaying me more and more to make the move from KeePass to 1password.

You and me both. This forum was a great resource for me to peruse prior to settling on 1Password as my new password manager, and after reading many of the threads on here, I decided to make the jump and buy a subscription to the Personal plan once my trial was over.

I especially enjoy the down-to-earth and personal attitude displayed by the 1Password team members here, and how their communication is completely devoid of corporate BS and canned answers. They display a deep knowledge of the technical nitty-gritty, too, which I, given my career as a software developer in the crypto business, appreciate very much. No "military-grade" snake-oil crypto here, only real crypto. ;)

The product is great, too, so I really had no excuse not to buy a subscription! Shout-out to @jpgoldberg, @brenty, @Lars, @Ben, and everyone else I may have forgotten. Keep up the good work! :+1:

Lars

@guidanceseeker - you're quite welcome. We don't really do "auto-generated" replies on this forum, with the exception of a few salutations/closings which are of course nearly identical anyway. Glad you enjoyed jpgoldberg's in-depth reply. We (1Password) don't specifically have protocols in place for offsite backups separate from where the data is stored in Frankfurt, for two main reasons:

1. That's part of what you (in this case, WE) pay AWS for; their unparalleled uptime, durability and redundancy. If you're familiar with with AWS, you'll know they're arguably the best in the business at this stuff, at present. AWS does have "availability zones" within each region, which aren't distributed enough to prevent, say, a nuclear strike, but are distributed enough to likely cause you to not even notice, say, a localized power outage, even one that lasted hours.
2. More importantly, however, every device onto which you install a 1Password app (Mac, Windows, iOS, Android) will have a local cache of your data.

So, in other words, if your own devices were to be lost/stolen/destroyed in a disaster -- even all of them simultaneously, like a house fire -- then when you acquire new devices, you simply download the 1Password app and just sign into your account. In such a case (of local data unavailability), the data in your 1Password.eu account can be thought of as your "offsite backup" (for purposes of this, even though it is not a traditional backup but rather a remote sync file). And if the opposite scenario happens and either AWS or we (AgileBits) or maybe even the entire city of Frankfurt "goes dark," then your own local devices' installations of 1Password are your "offsite backup" - because of the local cache of data, you don't need an internet connection to unlock it. And you can always export it (in a desktop app) or copy it to a standalone local vault (in any 1Password app).

We don't provide any kind of DoD/NSA/Gutmann-style "secure erase" for data you trash in 1Password (in the local app or on the server directly via web app), for a couple of reasons:

1. As more and more of our data is stored on SSDs or hybrid drives instead of strictly spinny-platter HDDs, it becomes less and less possible to "securely erase" data due to the drives' controllers/wear levelers themselves. Older HDDs could be visualized/wiped, right down to the individual sector; SSDs really can't. And if you try, you significantly decrease the lifespan of the drive itself because with solid-state flash memory, there is a (more or less) hard limit to the number of times you can write to each memory block before it fails. This is also one of the main reasons you don't hear much about "drive defragmentation" any longer -- because it isn't relevant with flash memory and trying to perform it involves multiple writes to most if not all memory blocks and thus greatly decreases SSD lifespan.
2. More importantly, on the 1password.com servers, all user data is encrypted at all times, including trashed/purged items. We also don't possess the decryption keys to your data anywhere on our servers, nor the secrets (your Master Password and Secret Key) with which to derive them, as these are never transmitted to us in any form.

In short, both in general and in the age of SSDs and flash memory (both in your own devices and increasingly in "the cloud"), the best strategy for ensuring that your data remains private is conscientious encryption, not overwriting memory blocks, which degrades disks' lifespan.

1password X on Linux in Chromium would still be considered native correct?

Not in the sense that 1Password for Mac on an iMac or 1Password for Windows on a Surface Pro is, no. It has some properties, such as being code-signed, that are more native-app-like than simply typing https://my.1password.com into your browser window and using the web app. Your data is still encrypted, of course, and when you enter your Master Password to unlock, it uses SRP directly with the 1password.com server, whereas entering that Master Password into the browser window could potentially allow any other extensions you had installed that had "Read/Write, all sites" access to read it in the browser window. I presume by the nature of your responses so far that you're quite cautious about what extensions you install and what they can do...but not everyone is.

I'm not sure what specific section of the white paper you were referring to with regard to "nothing crackable stored." In general, though we don't use the specific phrase "not crackable," what we mean is: by any reasonable measure of the term. The Secret Key is a string equivalent to 128 bits of entropy which is (it's more complicated than this, but essentially) "added to" whatever entropy your Master Password would have on its own. We require a 10-digit Master Password for 1password.com accounts and the sign-up process won't accept things like AAAAAAAAAA or 1234567890 or many obvious, well-know and easily-guessable passwords like password123, etc. As you note, you are free to use as long a Master Password as you like. Anything at around the 23-character mark (depends on character-set used, but generally) is also equivalent to around 128 bits of entropy. It's unguessable for any real-world purposes, with current computing resources. If you use a very long, truly random Master Password, then I suppose you could argue that the Secret Key doesn't add any meaningful additional security, in the same way as described in this blog post. But not everyone will use a good Master Password. Some will use the minimum they can, and we can't prevent people from using a Master Password that technically passes all our "bad password" checks but is still easily guessable/crackable in practice. But we want these users to be safe as well, and ensuring the data stored on our servers is protected by a key with at least 128 bits of entropy is what we've achieved by means of the Secret Key.

Hope that's helpful.

Lars

@MerryBit - thanks for the kind words! We put a lot of effort into these forums and our email support for exactly the reasons you mentioned: we want people to feel like they can ask questions and get answers they understand, not just either meaningless corporate boilerplate or a blizzard of technical mumbo-jumbo. We can do the latter if necessary, but one of our animating principles here is that good security should be available to, and comprehensible to (even if only on a surface level) anyone of any technical background, if they want to know. I'm glad to know you value that as well. :)

P.S. - do not get us started on the misuse of "military-grade encryption" terminology. If jpgoldberg hears you, multi-paragraph replies may ensue. ;) I was in a big-box-hardware-store-that-shall-remain-nameless just the other day, and in the door hardware section, there was a "smart lock" from a big-lock-manufacturer-that-shall-remain-nameless with a big "Military-grade encryption!!" banner right on the front of the box, as a selling point. Grrrr....

williakz

Your in-depth discussion of these complex issues is greatly appreciated. Looks like I picked a fine "family" for my family.

Ben

Thanks so much for the kind words, everyone! :)

Ben

MerryBit

@Lars - you're most welcome. Any praise you may receive is well-deserved in my opinion. 1Password is not perfect, but it is the best of the half-dozen or so password managers I've evaluated.

Speaking of competitors, a simple Google search will dig up other password managers that sport military-grade encryption front and center. Should I switch to one of those instead, @jpgoldberg, you know, given that 1Password does not have the same strong encryption? ;)

(To anyone reading this, and because irony is sometimes lost in writing, I'm joking in the previous paragraph. "Military-grade encryption", to anyone knowledgeable about cryptography and security, is construed as a clear warning sign, not an accolade. I do wonder if @jpgoldberg will take the bait though... ;))

[Deleted User]

@Lars
First of all a big thanks for another great reply.

Regarding white paper. I was referring to this statement on site 2 of your white paper

"Nothing “crackable” is stored Often a server will store the password hash.
If captured, this can be used in password cracking attempts. Ourtwo-
secret key derivation mixes your locally held Secret Key with your
Master Password so that data we store cannot be used in cracking
attempts."

You must store some kind of hashed and salted key which dervived from master password and secret key. Otherwise how do you authenticate a user to allow the transfer of encrypted data to the users local device for local decryption?

Whatever you store and however you call it, I just call it hash is in theory crackable if someone were to get hold of it, even if it is mathematical very unlikely to crack this dervived key. Would appreciate if you can confirm that you store some kind of authentication hash or explain how it otherwise works. Really want to understand.

Regarding 1password X. So in all honesty if I use this in a separate browser with no other extensions at all, do you consider the security level equal to a native app or not? Am using solely Linux on desktop and sadly there is no other option.

Regarding off-site backup : totally makes sense and if a nuclear strike hits Frankfurt I am so close that I have other worries 😁

Refarding data deletion and SSD wear leveling and controller influence: also makes sense.

Regarding password strength: I actually do use a password longer than 30+ characters which KeePass told me is equal to 146 bits of entropy. Guess in such a scenario the secret key is no longer a must have and rather a nice to have.

Cheers and am looking forward to your reply

AGAlumB

@MerryBit: 😂👍

AGAlumB

Otherwise how do you authenticate a user to allow the transfer of encrypted data to the users local device for local decryption?

@guidanceseeker: Secure Remote Password:

Developers: How we use SRP, and you can too

You can check out our implementation. :)

if someone were to get hold of it, even if it is mathematical very unlikely to crack this dervived key.

An attacker would need to 1) break into our server, 2) exfiltrate the encrypted data, and 3) guess both the Master Password and Secret Key together to use to decrypt the data. That's not something that anyone is going actually to be able to do for the foreseeable future, given the current state of the art and available resources.

Regarding 1password X. So in all honesty if I use this in a separate browser with no other extensions at all, do you consider the security level equal to a native app or not? Am using solely Linux on desktop and sadly there is no other option.

Effectively, yes:

About 1Password X security

Different from the 1Password web app, the browser extensions are validated by the vendor and browser, and are available for download directly from the "store" in the case of Firefox and Chrome (-based browsers) and Edge (in the case of Safari, it's built right into the 1Password app itself). So while there's not the same level of code signing facility of the truly "native" apps, there's a chain of trust there established that the user would need to actively circumvent to install unverified extensions from unverified sources.

Regarding password strength: I actually do use a password longer than 30+ characters which KeePass told me is equal to 146 bits of entropy. Guess in such a scenario the secret key is no longer a must have and rather a nice to have.

Welllll...I wouldn't go that far. Keep in mind that "entropy" in the case of a human-"generated" password is just a rough equivalency. With the Secret Key, you get 128 bits of actual entropy, as it's completely random. The Secret Key allows you to use a not-completely-ridiculous Master Password day to day compared to the Secret Key, while still benefiting fully from the protection the Secret Key affords you in the case of an attack on us. Cheers! :chuffed:

jpgoldberg

Ah, @MerryBit, you know how to push my buttons. "Military grade encryption" indeed. And so taking the bait, I will refer people to what I wrote six years ago in Guess why we’re moving to 256-bit AES keys.

[Deleted User]

@brenty
Puhh trying to wrap my head around all the information regarding SRP. If I get it you actually never even receive a hashed and salted encryption key.

Everything is done entirely local and your server only stores a verfier along the encrypted data which is what is being used to allow the server to push encrypted data to me for local decryption

Roughly correct? If so it is big.

That seems indeed preferably to what LastPass or Bitwarden are doing, which do store a hashed and salted version of my master password to authenticate.

Form a security point of view I am however not sure if having a hash/salt version of my password is an issue at all.

That is the whole point of hashing after all, being able to get the same hash from my password but not vice versa.

So if someone were to get such a hash vs not having it at all (like with your SRP) but only the encrypted data itself. Does the attack surface really change? They still need to find the proper master password in both cases.

1password X uses SRP too from what I read so far, right? Still voting for a native Linux client perhaps as appimage.

jpgoldberg

Puhh trying to wrap my head around all the information regarding SRP. If I get it you actually never even receive a hashed and salted encryption key.

Exactly.

Everything is done entirely local and your server only stores a verifier along the encrypted data which is what is being used to allow the server to push encrypted data to me for local decryption

Yes.

Form a security point of view I am however not sure if having a hash/salt version of my password is an issue at all.

The relevant difference is that no secret is transmitted during authentication at all. We can't learn any secrets or anything that helps with discovering your secrets during authentication, and neither can anyone listening in on the process. So while we do have your encrypted data, neither we nor an eavesdropper can learn anything useful during the authentication process.

This also means that the authentication process is not replayable. Someone who gets a full transcript of the authentication session cannot use that to authenticate at a later time.

So if someone were to get such a hash vs not having it at all (like with your SRP) but only the encrypted data itself. Does the attack surface really change? They still need to find the proper master password in both cases.

That is only true if you think in terms of data captured from what we store, but it is different if you think about what is transmitted to us. Consider a traditional username/password authentication process. The client sends the password to the server and the server does the hashing. A good server will only store the hash, but it still receives a user secret.

Additionally, SRP gives us a session key for encrypting messages during the session. This provides a layer of transport security even when the secrecy of TLS fails as happened in February 2017: Three layers of encryption keeps you safe when SSL/TLS fails

1password X uses SRP too from what I read so far, right?

Yes. SRP is the only way to authenticate.

[Deleted User]

@jpgoldberg
Thanks and sorry but I hope you allow me to ask again for my understanding. Really just trying to understand this in as much detail as I can to make an educated descisson on which service to use.

Consider a traditional username/password authentication process. The client sends the password to the server and the server does the hashing. A good server will only store the hash, but it still receives a user secret.>

That is what I wanted to get into. Other password managers of course do not receive the password and hash it on their end, that would be a huge joke.

That is also done locally and only the hashed and salted version is stored for authentication. At least that is what I gathered from reading all about this stuff.

In this case, yes they do receive a "secret" but it is not something they can actually use. Without the password from which the hash was derived from ,it is pretty much useless, or is it? I thought you would still need to crack such a hash, which, given a strong password should not be feasible for a long time.

Not sure about someone capturing that hash in transit... that could be used to pull the data from server, as it could allow authentication but even then, you would still need the password, won´t you? That is not even taking 2FA into account.

I guess your way is the most secure as it protects from man in the middle too.

Quite unrelated. Do you consider storing the emergency sheet in a LUKS container, which is put on a Cloud service for backup purposes as a viable way to make sure one does not loose it? In my case I would only store the secret key as I really know everything else and would even only store a textfile in the encrypted container to make sure someone would not even have an idea what it is for.

Thanks in advance for any more insights and again a huge thumbs up for such a tremendous support.

DanielP

@guidanceseeker:

In this case, yes they do receive a "secret" but it is not something they can actually use. Without the password from which the hash was derived from ,it is pretty much useless, or is it? I thought you would still need to crack such a hash, which, given a strong password should not be feasible for a long time.

Not sure about someone capturing that hash in transit... that could be used to pull the data from server, as it could allow authentication but even then, you would still need the password, won´t you? That is not even taking 2FA into account.

It is absolutely true that a strong password is of fundamental importance to protect against this. However, the unfortunate reality is that not everybody uses a strong Master Password, therefore seriously undermining the security of their systems. The Secret Key also exists to help mitigate this problem: by adding 128 bits of entropy, it makes cracking the Secret Key and Master Password combination much more difficult, even if you are not using a very strong Master Password.

Quite unrelated. Do you consider storing the emergency sheet in a LUKS container, which is put on a Cloud service for backup purposes as a viable way to make sure one does not loose it? In my case I would only store the secret key as I really know everything else and would even only store a textfile in the encrypted container to make sure someone would not even have an idea what it is for.

This is certainly an option, but please make sure you handle this very carefully: for instance, you will need to remember (or find a way to securely store) the decryption key for the LUKS container which contains your Emergency Kit separately, and make sure you never lose it.

And because you would encrypt your Secret Key, which is a part of your login credentials, that decryption key cannot live inside 1Password, because it would be like leaving the car keys inside a locked car: you would need your LUKS decryption key to decrypt the Secret Key, but you need the Secret Key to access 1Password, where the LUKS decryption key is stored.

At this point, it becomes quite a risky option: a better alternative would be to keep a printed copy of the Emergency Kit stored in a safe place, and/or make sure you always have at least one device where you are logged into your 1Password account. In this case, you will be able to retrieve your Secret Key from the app itself, without having to use third-party tools or additional layers of encryption.

jpgoldberg

@guidanceseeker asks how other password managers address related problems. Not something I feel comfortable going into as my understanding of how they do things can may well be faulty and out of date. So take what I say with a large grain of salt.

Other password managers of course do not receive the password and hash it on their end, that would be a huge joke.

I believe that a different password manager has found an interesting approach to the problem. They have a separate password for authentication and for decryption. That is, you've got one password for logging into their system and another one for decrypting your data. That way a secret is transmitted to the server, but it is a secret that can only be used for authentication. And so the authentication password is used like a traditional password.

Another approach is something along the lines of

That is also done locally and only the hashed and salted version is stored for authentication. At least that is what I gathered from reading all about this stuff.
In this case, yes they do receive a "secret" but it is not something they can actually use. Without the password from which the hash was derived from ,it is pretty much useless, or is it? I thought you would still need to crack such a hash, which, given a strong password should not be feasible for a long time.

In both cases, the an authentication secret is transmitted. And anyone who captures the communication (for example through some SSL sniffing mechanism) will learn enough at a minimum to authenticate to the service, even if they don't obtain a decryption key.

With SRP, on the other hand, the exchange is really zero-knowledge. Nothing captured in one exchange can be used to log in in another. So in this respect, SRP is like a one time password. What gets captured can't be reused for anything. Additionally, SRP provides mutual authentication. The server proves to the client that it knows the corresponding verifier.

Here is a table outlining some of the security properties of different authentication schemes from a paper I presented at a couple of conferences last year. Note when reading this table that SRP is a Password Authenticated Key Exchange (PAKE), and the Secret Key is the second key in Two-Secret Key Derivation (2SKD).

SRP and other PAKEs don't give us absolutely everything we could possibly want in an authentication scheme (no single method does), but it does give us a lot.

As for how crackable the alternatives you describe are, that depends on the heavily on the the fine details. But because of our Secret Key stored on our server can be used for cracking and because of SRP nothing that is captured during authentication can be used either for cracking or for replay. So a PAKE (like SRP) along with your Secret Key gives us a really nice bundle of security properties.

Fairgame

I do wonder if @jpgoldberg will take the bait though... ;)

Military grade encryption sounds interesting.

Please do take a bait.

Even though most of the response is over my head, he has a way to explain things in laymen terms, and in funny way on top of that.

Ben

My friend who was in the military once told me: "anyone who thinks of 'military grade' as a good thing has never served in the military."
In all seriousness, I think Tom explains it quite well in this video:
https://youtu.be/WVDQEoe6ZWY
(2:12 – 2:23 or so)

"Military grade encryption means AES, which is the same encryption baked into every web browser and app. You are using military grade encryption to watch this video. The claim isn't wrong, it's just not special either."

It is a bit like claiming your device uses military grade GPS because it uses the same satellites for GPS that the military does. Yeah; they all do. Beyond that, how the encryption is implemented is really the important bit, and describing it as "military grade" does nothing to explain the implementation. That is my take anyway.

It looks like Goldberg already did take the bait above, and pointed folks to his blog post here: https://discussions.agilebits.com/discussion/comment/531910/#Comment_531910

Ben