Talk:Securing your wallet - Revision history

Mammique: /* Automated backup: inotify v.s. cron */

2012-09-25T06:20:05Z

Automated backup: inotify v.s. cron

← Older revision		Revision as of 06:20, 25 September 2012
Line 381:		Line 381:

	Hi, what would you think about a an automated backup using inotify (or pynotify: http://pyinotify.sourceforge.net/doc-v07/) to monitor writes on the wallet, which trigger the backup. It would save space by not copying the same versions of a wallet, and not wait for the next cron iteration to backup the wallet (which could be lost in between). --[[User:Mammique\|Mammique]] ([[User talk:Mammique\|talk]]) 06:17, 25 September 2012 (GMT)		Hi, what would you think about a an automated backup using inotify (or pynotify: http://pyinotify.sourceforge.net/doc-v07/) to monitor writes on the wallet, which trigger the backup. It would save space by not copying the same versions of a wallet, and not wait for the next cron iteration to backup the wallet (which could be lost in between). --[[User:Mammique\|Mammique]] ([[User talk:Mammique\|talk]]) 06:17, 25 September 2012 (GMT)
			:There is also lsyncd: http://code.google.com/p/lsyncd/--[[User:Mammique\|Mammique]] ([[User talk:Mammique\|talk]]) 06:20, 25 September 2012 (GMT)

Mammique: /* Automated backup: inotify v.s. cron */ new section

2012-09-25T06:17:56Z

Automated backup: inotify v.s. cron: new section

← Older revision		Revision as of 06:17, 25 September 2012
Line 377:		Line 377:

	@Ijel Well, TrueCrypt uses RAM-only storage when mounting a file. I'm pretty sure it has anti-swap protection too. [[User:Lordcirth\|Lordcirth]] 23:55, 27 May 2012 (GMT)		@Ijel Well, TrueCrypt uses RAM-only storage when mounting a file. I'm pretty sure it has anti-swap protection too. [[User:Lordcirth\|Lordcirth]] 23:55, 27 May 2012 (GMT)

			== Automated backup: inotify v.s. cron ==

			Hi, what would you think about a an automated backup using inotify (or pynotify: http://pyinotify.sourceforge.net/doc-v07/) to monitor writes on the wallet, which trigger the backup. It would save space by not copying the same versions of a wallet, and not wait for the next cron iteration to backup the wallet (which could be lost in between). --[[User:Mammique\|Mammique]] ([[User talk:Mammique\|talk]]) 06:17, 25 September 2012 (GMT)

Lordcirth: /* Time Sensitivity */

2012-05-28T00:02:19Z

Time Sensitivity

← Older revision		Revision as of 00:02, 28 May 2012
Line 18:		Line 18:

	Is it possible to still send money to my wallet, even if it's backed up and offline? Do bitcoins ever expire if they're not spent, or is there anything bad that can happen by not using my bitcoin client in a long time? [[User:Daniel.benoy\|Daniel.benoy]] 23:18, 8 June 2011 (GMT)		Is it possible to still send money to my wallet, even if it's backed up and offline? Do bitcoins ever expire if they're not spent, or is there anything bad that can happen by not using my bitcoin client in a long time? [[User:Daniel.benoy\|Daniel.benoy]] 23:18, 8 June 2011 (GMT)

			Technically your wallet does not hold bitcoins but rather the keys to those bitcoins. So whether you are online, offline, or dead is totally irrelevant to the Bitcoin network. They also never expire. The worst that can happen by not using it for a long time is that it will take a while to sync with the network. [[User:Lordcirth\|Lordcirth]] 00:02, 28 May 2012 (GMT)

	== How often is it needed to backup the Wallet? ==		== How often is it needed to backup the Wallet? ==

Lordcirth at 23:55, 27 May 2012

2012-05-27T23:55:52Z

← Older revision		Revision as of 23:55, 27 May 2012
Line 373:		Line 373:
	I don't feel entirely comfortable with the suggested usage of the ‘shred’ command in the given Linux script. My understanding (and according to shred's manpage) is that on modern (especially journaled) filesystems, there is ''no'' guarantee that when an application like shred asks the OS to overwrite a file, that the file will actually be physically overwritten in place on the disk. Unless there have been features implemented to allow special handling by the kernel for such security applications (I haven't investigated, so maybe there are, or maybe not), it would probably be safer to disable all system swap (i.e., with ‘swapoff’) and then store the unencrypted data on a temporary RAM disk only, then unmount the RAM disk afterwards to ensure it never gets written to disk. I've done this before, though unfortunately it's a bit of a hassle and normally requires running commands that need root privileges or sudo, etc. Comments?		I don't feel entirely comfortable with the suggested usage of the ‘shred’ command in the given Linux script. My understanding (and according to shred's manpage) is that on modern (especially journaled) filesystems, there is ''no'' guarantee that when an application like shred asks the OS to overwrite a file, that the file will actually be physically overwritten in place on the disk. Unless there have been features implemented to allow special handling by the kernel for such security applications (I haven't investigated, so maybe there are, or maybe not), it would probably be safer to disable all system swap (i.e., with ‘swapoff’) and then store the unencrypted data on a temporary RAM disk only, then unmount the RAM disk afterwards to ensure it never gets written to disk. I've done this before, though unfortunately it's a bit of a hassle and normally requires running commands that need root privileges or sudo, etc. Comments?
	~ [[User:Ijel\|Ijel]] 03:49, 11 February 2012 (GMT)		~ [[User:Ijel\|Ijel]] 03:49, 11 February 2012 (GMT)

			@Ijel Well, TrueCrypt uses RAM-only storage when mounting a file. I'm pretty sure it has anti-swap protection too. [[User:Lordcirth\|Lordcirth]] 23:55, 27 May 2012 (GMT)

Ijel: /* ‘Shred’ cannot always be assumed to be secure on modern filesystems! */ Don't mind me, I'm just a freaking perfectionist. I'll try not to edit spam so much next time. :-)

2012-02-11T03:55:33Z

‘Shred’ cannot always be assumed to be secure on modern filesystems!: Don't mind me, I'm just a freaking perfectionist. I'll try not to edit spam so much next time. :-)

← Older revision		Revision as of 03:55, 11 February 2012
Line 371:		Line 371:
	= ‘Shred’ cannot always be assumed to be secure on modern filesystems! =		= ‘Shred’ cannot always be assumed to be secure on modern filesystems! =

	I don't feel entirely comfortable with the suggested usage of the ‘shred’ command in the given Linux script. My understanding (and according to shred's manpage) is that on modern filesystems, it is ''no'' guarantee that when an application like shred asks the OS to overwrite a file, that the file will actually be physically overwritten in place on the disk. Unless there have been features implemented to allow special handling by the kernel for such security applications (I haven't investigated, so maybe there are, or maybe not), it would probably be safer to disable all system swap (i.e., with ‘swapoff’) and then store the unencrypted data on a temporary RAM disk only, then unmount the RAM disk afterwards to ensure it never gets written to disk. I've done this before, though unfortunately it's a bit of a hassle and normally requires running commands that need root privileges or sudo, etc. Comments?		I don't feel entirely comfortable with the suggested usage of the ‘shred’ command in the given Linux script. My understanding (and according to shred's manpage) is that on modern (especially journaled) filesystems, there is ''no'' guarantee that when an application like shred asks the OS to overwrite a file, that the file will actually be physically overwritten in place on the disk. Unless there have been features implemented to allow special handling by the kernel for such security applications (I haven't investigated, so maybe there are, or maybe not), it would probably be safer to disable all system swap (i.e., with ‘swapoff’) and then store the unencrypted data on a temporary RAM disk only, then unmount the RAM disk afterwards to ensure it never gets written to disk. I've done this before, though unfortunately it's a bit of a hassle and normally requires running commands that need root privileges or sudo, etc. Comments?
	~ [[User:Ijel\|Ijel]] 03:49, 11 February 2012 (GMT)		~ [[User:Ijel\|Ijel]] 03:49, 11 February 2012 (GMT)

Ijel: /* Protected user account */ Fix incorrect end tag that was messing up formatting up rest of page ;-)

2012-02-11T03:52:58Z

Protected user account: Fix incorrect end tag that was messing up formatting up rest of page ;-)

← Older revision		Revision as of 03:52, 11 February 2012
Line 172:		Line 172:
	The first step is [https://help.ubuntu.com/8.04/serverguide/C/user-management.html to create a new user], which goes with the command:		The first step is [https://help.ubuntu.com/8.04/serverguide/C/user-management.html to create a new user], which goes with the command:

	sudo adduser <code> new_user_name </ code>		sudo adduser <code> new_user_name </code>

	On the message "Enter a new value or press ENTER for the default" one needs only to press the Return key.		On the message "Enter a new value or press ENTER for the default" one needs only to press the Return key.

Ijel: Whoops, the “add topic” button didn't thread properly for some reason

2012-02-11T03:50:59Z

Whoops, the “add topic” button didn't thread properly for some reason

← Older revision		Revision as of 03:50, 11 February 2012
Line 369:		Line 369:
	It may be worth it if someone would describe the correct procedure to secure the bitcoin wallet using MinorFs/AppArmor in a way similar to described in the above link for ssh keys without passphrases.		It may be worth it if someone would describe the correct procedure to secure the bitcoin wallet using MinorFs/AppArmor in a way similar to described in the above link for ssh keys without passphrases.

	== ‘Shred’ cannot always be assumed to be secure on modern filesystems! ==		= ‘Shred’ cannot always be assumed to be secure on modern filesystems! =

	I don't feel entirely comfortable with the suggested usage of the ‘shred’ command in the given Linux script. My understanding (and according to shred's manpage) is that on modern filesystems, it is ''no'' guarantee that when an application like shred asks the OS to overwrite a file, that the file will actually be physically overwritten in place on the disk. Unless there have been features implemented to allow special handling by the kernel for such security applications (I haven't investigated, so maybe there are, or maybe not), it would probably be safer to disable all system swap (i.e., with ‘swapoff’) and then store the unencrypted data on a temporary RAM disk only, then unmount the RAM disk afterwards to ensure it never gets written to disk. I've done this before, though unfortunately it's a bit of a hassle and normally requires running commands that need root privileges or sudo, etc. Comments?		I don't feel entirely comfortable with the suggested usage of the ‘shred’ command in the given Linux script. My understanding (and according to shred's manpage) is that on modern filesystems, it is ''no'' guarantee that when an application like shred asks the OS to overwrite a file, that the file will actually be physically overwritten in place on the disk. Unless there have been features implemented to allow special handling by the kernel for such security applications (I haven't investigated, so maybe there are, or maybe not), it would probably be safer to disable all system swap (i.e., with ‘swapoff’) and then store the unencrypted data on a temporary RAM disk only, then unmount the RAM disk afterwards to ensure it never gets written to disk. I've done this before, though unfortunately it's a bit of a hassle and normally requires running commands that need root privileges or sudo, etc. Comments?
	~ [[User:Ijel\|Ijel]] 03:49, 11 February 2012 (GMT)		~ [[User:Ijel\|Ijel]] 03:49, 11 February 2012 (GMT)

Ijel: /* ‘Shred’ cannot always be assumed to be secure on modern filesystems! */ new section

2012-02-11T03:49:21Z

‘Shred’ cannot always be assumed to be secure on modern filesystems!: new section

← Older revision		Revision as of 03:49, 11 February 2012
Line 368:		Line 368:

	It may be worth it if someone would describe the correct procedure to secure the bitcoin wallet using MinorFs/AppArmor in a way similar to described in the above link for ssh keys without passphrases.		It may be worth it if someone would describe the correct procedure to secure the bitcoin wallet using MinorFs/AppArmor in a way similar to described in the above link for ssh keys without passphrases.

			== ‘Shred’ cannot always be assumed to be secure on modern filesystems! ==

			I don't feel entirely comfortable with the suggested usage of the ‘shred’ command in the given Linux script. My understanding (and according to shred's manpage) is that on modern filesystems, it is ''no'' guarantee that when an application like shred asks the OS to overwrite a file, that the file will actually be physically overwritten in place on the disk. Unless there have been features implemented to allow special handling by the kernel for such security applications (I haven't investigated, so maybe there are, or maybe not), it would probably be safer to disable all system swap (i.e., with ‘swapoff’) and then store the unencrypted data on a temporary RAM disk only, then unmount the RAM disk afterwards to ensure it never gets written to disk. I've done this before, though unfortunately it's a bit of a hassle and normally requires running commands that need root privileges or sudo, etc. Comments?
			~ [[User:Ijel\|Ijel]] 03:49, 11 February 2012 (GMT)

X at 17:20, 8 January 2012

2012-01-08T17:20:05Z

← Older revision		Revision as of 17:20, 8 January 2012
Line 1:		Line 1:
	The Mac solution does not scale~~. The~~ suggested sizes are too low and the maximum size is infinite. [[User:X\|X]] 17:10, 8 January 2012 (GMT)		The article is too huge. The Mac solution does not scale; the suggested sizes are too low and the maximum size is infinite. [[User:X\|X]] 17:10, 8 January 2012 (GMT)

	This article needs a rewrite following the introduction of the Bitcoin.org client's ability to passphrase protect the keys in the wallet. Perhaps some sections also -- something like "typical consumer use" (where the client's encryption is adequate) and "commercial-grade protection" where the topics such as encryption at the filesystem is addressed. - [[User:Sgornick\|Sgornick]] 10:24, 28 December 2011 (GMT)		This article needs a rewrite following the introduction of the Bitcoin.org client's ability to passphrase protect the keys in the wallet. Perhaps some sections also -- something like "typical consumer use" (where the client's encryption is adequate) and "commercial-grade protection" where the topics such as encryption at the filesystem is addressed. - [[User:Sgornick\|Sgornick]] 10:24, 28 December 2011 (GMT)

X at 17:10, 8 January 2012

2012-01-08T17:10:22Z

← Older revision		Revision as of 17:10, 8 January 2012
Line 1:		Line 1:
			The Mac solution does not scale. The suggested sizes are too low and the maximum size is infinite. [[User:X\|X]] 17:10, 8 January 2012 (GMT)

	This article needs a rewrite following the introduction of the Bitcoin.org client's ability to passphrase protect the keys in the wallet. Perhaps some sections also -- something like "typical consumer use" (where the client's encryption is adequate) and "commercial-grade protection" where the topics such as encryption at the filesystem is addressed. - [[User:Sgornick\|Sgornick]] 10:24, 28 December 2011 (GMT)		This article needs a rewrite following the introduction of the Bitcoin.org client's ability to passphrase protect the keys in the wallet. Perhaps some sections also -- something like "typical consumer use" (where the client's encryption is adequate) and "commercial-grade protection" where the topics such as encryption at the filesystem is addressed. - [[User:Sgornick\|Sgornick]] 10:24, 28 December 2011 (GMT)