Or don't use SecurePrint at all and write all data down by hand from the computer screen. There's nothing wrong with that.
Sometimes the easiest solution is the best
I completely agree. 
Topic: SecurePrint flawed (in the context of fragmented backups) (Read 958 times)
Sometimes the easiest solution is the best
I completely agree. 
Even if an attacker has access to my life I want to make it as difficult for them as possible. You have a lot of nifty solutions for paranoid users and I thought this would be a good complement.
In the meantime I suggest that users who want a little bit of extra security when it comes to the SecurePrint feature, to only write the code down on as many fragments as it is necessary, i.e. N - M + 1 fragments. For example in a 5-of-6 fragmented backup configuration you only need to put down the SecurePrint code on 2 (=6-5+1) fragments and then put these fragments in the locations you deem most secure.
In the meantime I suggest that users who want a little bit of extra security when it comes to the SecurePrint feature, to only write the code down on as many fragments as it is necessary, i.e. N - M + 1 fragments. For example in a 5-of-6 fragmented backup configuration you only need to put down the SecurePrint code on 2 (=6-5+1) fragments and then put these fragments in the locations you deem most secure.
The SecurePrint code is just another piece of data that is needed to unlock your fragmented backups. You can do what you're saying, or you can just recalibrate your decision of M and N (in M-of-N) to meet your security-vs-redundancy needs. For instance, use 4-of-7 instead of 3-of-5 and then you haven't destroyed your ability to recover it if particular fragments are not recovered.
Or don't use SecurePrint at all and write all data down by hand from the computer screen. There's nothing wrong with that.
Even if an attacker has access to my life I want to make it as difficult for them as possible. You have a lot of nifty solutions for paranoid users and I thought this would be a good complement.
In the meantime I suggest that users who want a little bit of extra security when it comes to the SecurePrint feature, to only write the code down on as many fragments as it is necessary, i.e. N - M + 1 fragments. For example in a 5-of-6 fragmented backup configuration you only need to put down the SecurePrint code on 2 (=6-5+1) fragments and then put these fragments in the locations you deem most secure.
In the meantime I suggest that users who want a little bit of extra security when it comes to the SecurePrint feature, to only write the code down on as many fragments as it is necessary, i.e. N - M + 1 fragments. For example in a 5-of-6 fragmented backup configuration you only need to put down the SecurePrint code on 2 (=6-5+1) fragments and then put these fragments in the locations you deem most secure.
In my opinion having to share the SecurePrint code among all fragments in an M-of-N fragmented backup scenario, is a security flaw. If an adversary manages to get access to all the fragments without the SecurePrint code (e.g by MITM the printer) he will only have to get a hold of one of the fragments to be able to get the SecurePrint code and restore the wallet.
I don't consider this to be a critical security flaw, but still something worth considering and maybe fixing for a future release.
I don't consider this to be a critical security flaw, but still something worth considering and maybe fixing for a future release.
This was intentional. Multiple codes are not required to protect the fragments from the printer. What you describe is still a multi-point attack, which is the point of fragmented backups in the first place. A compromised printer alone will not result in theft, and a compromised single fragment will not result in theft either. If someone has access to both your printer, and at least one of your fragments, they are targeting you (and have a lot of access to your life), and will probably find ways to compromise you anyway.
It achieves its goal of mitigating casual threats, which may attack thousands of people at once (such as malware), and take whatever is easy and unprotected, and forego complex, physical, targeted attacks on any particular person.
In my opinion having to share the SecurePrint code among all fragments in an M-of-N fragmented backup scenario, is a security flaw. If an adversary manages to get access to all the fragments without the SecurePrint code (e.g by MITM the printer) he will only have to get a hold of one of the fragments to be able to get the SecurePrint code and restore the wallet.
I don't consider this to be a critical security flaw, but still something worth considering and maybe fixing for a future release.
I don't consider this to be a critical security flaw, but still something worth considering and maybe fixing for a future release.
Jump to: