elective-stereophonic
elective-stereophonic
Wallet.dat file
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.12.2

Pages: 1 2 3 ... 9 [All]

Author Topic: Wallet.dat file  (Read 56741 times)

mczarnek

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
Wallet.dat file
« on: July 18, 2014, 07:48:22 am »

One of the issues with our wallets is that it's all brainwallet and this is bad for new users.  We've all seen a couple people were were scammed and there are probably at least 20 who didn't say anything for everyone who does.

I would like to create a brainwallet API for Nxt that allows wallets and websites(such as nxtblocks.info) to all access the same wallet file on the same computer.  So wallet file will be built into the core and accessible via API calls.

This wallet file will be password protected itself, with an easier to remember password.

Thinking I'll use something like pbkdf2 to add a time delay between the password to unlock the wallet and unencrypting the wallet: https://nxtforum.org/general-discussion/peanut-butter-keeps-dogs-friendly-too-(pbkdf2)/

New estimate, instant transaction confirmations will take at least 4 months for me to complete.  I'd like something short term that can make a little bit of money and considering 3 months of work has already gone into it, I'm trying to fundraise a little in that area.  In the meantime, this is a smaller project but in light of recent developments, maybe a more necessary one and I'd like to get it done first.

So, I would like to request a bounty for implementing this.

Basic API functions will be:
Create wallet file(requires password and security level(aka time/security trade-off for PBKDF2)
Delete wallet file
Edit wallet file
Add new account(aka secret phrase)
Delete account
Get list of public keys
Get private key associated with public key
Backup wallet file to file path

Thoughts on a bounty?  I'm ready to work on this as soon as I get the green light. Thanks.
« Last Edit: July 18, 2014, 07:51:17 am by mczarnek »
Logged
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

wesley

  • Hero Member
  • *****
  • Karma: +204/-3
  • Offline Offline
  • Posts: 1159
    • View Profile
Re: Wallet.dat file
« Reply #1 on: July 18, 2014, 07:55:17 am »

Great, I'd just like to add that the reason this should be done via Java API is that due to browser security issues you can't access files, so no wallet.dat is possible in the browser. It would theoretically be possible to add such functionality to my mac and windows application, but I'd like it to work in all cases, even if the user is using his browser and the command line client, so an API as described above is the answer to that.

I think this is a pretty important topic so the bounty should be significant enough.
Logged

farl4bit

  • Hero Member
  • *****
  • Karma: +210/-45
  • Offline Offline
  • Posts: 3466
    • View Profile
    • Crypto Advies
Re: Wallet.dat file
« Reply #2 on: July 18, 2014, 09:11:05 am »

Good luck with this project! :)
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Wallet.dat file
« Reply #3 on: July 18, 2014, 09:23:46 am »

I disagree. Instant transactions is more important. Wallet.dat is a vanity feature as far as the core is concerned, the core is a server, not a desktop application. What do you mean by "websites(such as nxtblocks.info) to all access the same wallet file on the same computer"?
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

cc001

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 829
    • View Profile
Re: Wallet.dat file
« Reply #4 on: July 18, 2014, 09:32:20 am »

Very nice idea!
Would it be possible to use multiple wallet files? Or the possibility to select which addresses should be exported/imported. This would allow the classical wallet-cold-storage of some specific addresses. This would allow the easy management of several addresses/accounts and it would allow a lot of different scenarios of brainwallet/coldstorage/walletfile, and every user could use the method he likes the most (or combine them).

But I think it is more a client feature (how to handle/manage different accounts/addresses/wallets) and should not be included into the core. Well there seems to be some issues using wallet files in the browser... hmm...

Logged
cc001 Personal - NXT-8RXS-2SSK-RNF2-HSNL8
NxtReporting.com - The Nxt Asset Exchange Portfolio Manager with Profitability Tracking - Donations are greatly appreciated on NXT-5W4G-GAR6-JHJP-H8ZTW

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #5 on: July 18, 2014, 10:50:12 am »

I disagree. Instant transactions is more important. Wallet.dat is a vanity feature as far as the core is concerned,

Wallet.dat  is far easy to implement than "Instant transactions" . It shouldn't take even a week to implement Wallet.dat. It greatly increases usability and security for the users. 



Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #6 on: July 18, 2014, 11:25:44 am »

Get private key associated with public key

Why? It should be "Get get secret phrase associated with public key'" That's what the client would need
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

CryptKeeper

  • Hero Member
  • *****
  • Karma: +78/-5
  • Offline Offline
  • Posts: 1235
    • View Profile
Re: Wallet.dat file
« Reply #7 on: July 18, 2014, 12:42:24 pm »

Great, I'd just like to add that the reason this should be done via Java API is that due to browser security issues you can't access files, so no wallet.dat is possible in the browser. It would theoretically be possible to add such functionality to my mac and windows application, but I'd like it to work in all cases, even if the user is using his browser and the command line client, so an API as described above is the answer to that.

I think this is a pretty important topic so the bounty should be significant enough.

What about HTML5 web storage? http://www.w3schools.com/html/html5_webstorage.asp

Quote
Web storage is supported in Internet Explorer 8+, Firefox, Opera, Chrome, and Safari.

Note: Internet Explorer 7 and earlier versions, do not support Web Storage.
Logged
Follow me on twitter for the latest news on bitcoin and altcoins!
Vanity Accounts Sale :-)

antanst

  • Full Member
  • ***
  • Karma: +36/-0
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
Re: Wallet.dat file
« Reply #8 on: July 18, 2014, 12:45:18 pm »

One of the issues with our wallets is that it's all brainwallet and this is bad for new users. We've all seen a couple people were were scammed and there are probably at least 20 who didn't say anything for everyone who does.

I assume by "scammed" you mean that they picked an insecure password and as a consequence their account has been emptied by an attacker.

Quote
I would like to create a brainwallet API for Nxt that allows wallets and websites(such as nxtblocks.info) to all access the same wallet file on the same computer.  So wallet file will be built into the core and accessible via API calls.

This will require sweeping changes to the client UI as well. The API calls will be the easy tasks. Implementing multiple account functionality in the wallet, while simultaneously keeping the user experience as simple as possible is a much more time consuming task.

Quote
This wallet file will be password protected itself, with an easier to remember password.

The wallet password should be secure, so you must follow the same password creation/generation method as in creating an account in the first place. Using a KDF such as PBKDF2 doesn't mean one can get away with an insecure password.

Quote
Basic API functions will be:
<snip>
Add new account(aka secret phrase)

If you can specify a custom secret phrase for an account, then the behavior is virtually the same as it is right now as far as a single NXT account's security is concerned. Users will still be able to enter insecure passwords (at their own risk, of course) like now. Having a wallet with multiple accounts is primarily a usability feature, not a security one, unless you force automatic account creation as well and completely discard accounts with custom passphrases. Unfortunately, this behavior will be backwards incompatible with the current user experience people expect from the client. Which means even more UI complications, if you want to remain compatible and offer a way for the user to import his old passphrases.

Having said the above, feel free to browse the encryption/decryption code in the wallet.js file from nxtblocks.info, as well as the decrypted wallet format. We have no problem giving code back for inclusion into the NXT core.

What about HTML5 web storage?

The users will lose their wallets whenever they clean their browser cache.
Logged

CryptKeeper

  • Hero Member
  • *****
  • Karma: +78/-5
  • Offline Offline
  • Posts: 1235
    • View Profile
Re: Wallet.dat file
« Reply #9 on: July 18, 2014, 12:48:14 pm »

The users will lose their wallets whenever they clean their browser cache.

Not with HTML5 web storage:

Quote
The localStorage Object
The localStorage object stores the data with no expiration date. The data will not be deleted when the browser is closed, and will be available the next day, week, or year.

There are a few examples if you follow the link http://www.w3schools.com/html/html5_webstorage.asp, so you can try it yourself!
Logged
Follow me on twitter for the latest news on bitcoin and altcoins!
Vanity Accounts Sale :-)

antanst

  • Full Member
  • ***
  • Karma: +36/-0
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
Re: Wallet.dat file
« Reply #10 on: July 18, 2014, 12:58:34 pm »

The HTML5 web storage is cleared up whenever the user uses a private ("incognito") window and closes it afterwards, or when he empties his cookies/cache (depending on the browser). My point is that there are too many things that can go wrong and the users will accidentally lose their wallets.
Logged

CryptKeeper

  • Hero Member
  • *****
  • Karma: +78/-5
  • Offline Offline
  • Posts: 1235
    • View Profile
Re: Wallet.dat file
« Reply #11 on: July 18, 2014, 01:12:16 pm »


The HTML5 web storage is cleared up whenever the user uses a private ("incognito") window and closes it afterwards, or when he empties his cookies/cache (depending on the browser). My point is that there are too many things that can go wrong and the users will accidentally lose their wallets.

Ok, I understand that, but you can prevent that by offering a backup of the pass phrase:  maybe a printout with qr code or the user must write it down. If you use a wallet.dat file, you need a backup as well.

How many users uses the "incognito" mode with the NXT client? You can't even save your contacts with that! I don't know if you could detect incognito mode and warn the user about it, maybe that would be a solution for this problem.
Logged
Follow me on twitter for the latest news on bitcoin and altcoins!
Vanity Accounts Sale :-)

antanst

  • Full Member
  • ***
  • Karma: +36/-0
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
Re: Wallet.dat file
« Reply #12 on: July 18, 2014, 01:14:39 pm »

Incognito mode is undetectable.
Logged

v39453

  • Full Member
  • ***
  • Karma: +12/-2
  • Offline Offline
  • Posts: 155
    • View Profile
Re: Wallet.dat file
« Reply #13 on: July 18, 2014, 01:57:20 pm »

How many users uses the "incognito" mode with the NXT client?

A recommendation was made on this forum to use incognito mode.

Here's an alternative to wallet.dat:

The client could refuse to accept a passphrase for a new account that was not generated by it. This would be inconvenient for users who want to pick their own passphrases, but would prevent accounts getting stolen because of weak passwords.
Logged

mczarnek

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
Re: Wallet.dat file
« Reply #14 on: July 18, 2014, 04:25:15 pm »

I disagree. Instant transactions is more important. Wallet.dat is a vanity feature as far as the core is concerned, the core is a server, not a desktop application. What do you mean by "websites(such as nxtblocks.info) to all access the same wallet file on the same computer"?

So, maybe it hasn't been fully thought through but this is how NEM intends to do it and Wesley was waiting to implement something like this in the wallet, hoping that the core would implement it instead.  The idea is that you go to Nxtblocks.info, give them your wallet password, and they have access to the core API, and can make calls to communicate with the same wallet.dat file that Wesley's wallet accesses.

I do need a little bit of feedback regarding wallet.dat vs Instant Transactions.  If I don't implement this, it looks like HumanFractal may be able to do it, though he's got a couple other things to finish up first.


Wallet.dat  is far easy to implement than "Instant transactions" . It shouldn't take even a week to implement Wallet.dat. It greatly increases usability and security for the users. 


That's the idea, though I'm thinking a little longer than that, I'm only just learning the core code and don't know how I'd go about testing this, though it certainly is a simpler system.

Also, it'd be nice to have some funds to slightly more comfortably last me through IT implementation.  Maybe the TechDev committee would be willing to restructure the IT bounty?  When I get it onto the test net and have features x,y, and z implemented, I'll get partial payment. Either that or I may try to do a little bit of fundraising, especially, considering how much work has already gone into it and is still needed, I don't think the current funding for IT even comes close to minimum wage at these prices and I need to make sure I can cover the mortgage.

One of the issues with our wallets is that it's all brainwallet and this is bad for new users. We've all seen a couple people were were scammed and there are probably at least 20 who didn't say anything for everyone who does.

I assume by "scammed" you mean that they picked an insecure password and as a consequence their account has been emptied by an attacker.
Yes but we need to hold onto new dumb/naive users who are going to do that not knowing any better.

Quote
This wallet file will be password protected itself, with an easier to remember password.

The wallet password should be secure, so you must follow the same password creation/generation method as in creating an account in the first place. Using a KDF such as PBKDF2 doesn't mean one can get away with an insecure password.
Agreed, but you need both the wallet.dat and to crack the password and the same password is more secure if run through PBKDF2.. maybe even semi-memorable passwords could provide a decent level of security if you run PBKDF2 on it.

Quote
Quote
I would like to create a brainwallet API for Nxt that allows wallets and websites(such as nxtblocks.info) to all access the same wallet file on the same computer.  So wallet file will be built into the core and accessible via API calls.

This will require sweeping changes to the client UI as well. The API calls will be the easy tasks. Implementing multiple account functionality in the wallet, while simultaneously keeping the user experience as simple as possible is a much more time consuming task.
[/quote]

Yeah, will need big changes there. But I'm not touching implementing it into the wallet.. Wesley can do that.  I'm talking API only.
Logged
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

mczarnek

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
Re: Wallet.dat file
« Reply #15 on: July 18, 2014, 05:01:50 pm »

And I think the big difference is if you are trying to hack a wallet.dat file, there is one magic password.  If trying to hack the blockchain, you are trying to simultaneously hack everyone's account at once.  So, especially combined with PBKDF2, you can use a somewhat memorable password and it's still fairly secure, longer is obviously still better, but wallet.dat holding onto long complicated passwords also needs to be stolen too.

And if a user does use a stupid insecure, very memorable password.. they are still safer because their wallet.dat needs to be stolen too and can't be hacked using public knowledge.
Logged
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #16 on: July 18, 2014, 07:26:36 pm »

The wallet password should be secure, so you must follow the same password creation/generation method as in creating an account in the first place. Using a KDF such as PBKDF2 doesn't mean one can get away with an insecure password.

This is absolutely not true and total nonsense. A "weak" account password means instantaneous stolen funds by bots that are running constantly and checking these account. A "weak"  wallet password doesn't mean a hacked account. The attacker first needs access to the wallet file file itself (unlike account password) , which isn't easy without tricking the user into installing some kind of trojan/malware.

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #17 on: July 18, 2014, 07:30:44 pm »

And I think the big difference is if you are trying to hack a wallet.dat file, there is one magic password.

Yes, and the hacker first need to "steal" wallet.dat which isn't on the blockchain like account passwords.

There is big difference.

It's still possible to never get hacked in your life even if your wallet is not encrypted at all (like bitcoin wallet isn't by default nor the wallets on the phone). Don't confuse the issue. wallet is far more secure than letting users enter insecure account passwords that are one hash to private keys on the blockchain.  It increases security and usability which are serious problems with Nxt,

Forget instant transactions, we need  wallet implementation which should not take more than a week to implement. It's easy solution to serious security problem.

 
« Last Edit: July 18, 2014, 07:34:12 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

antanst

  • Full Member
  • ***
  • Karma: +36/-0
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
Re: Wallet.dat file
« Reply #18 on: July 18, 2014, 08:07:57 pm »

The wallet password should be secure, so you must follow the same password creation/generation method as in creating an account in the first place. Using a KDF such as PBKDF2 doesn't mean one can get away with an insecure password.

This is absolutely not true and total nonsense. A "weak" account password means instantaneous stolen funds by bots that are running constantly and checking these account. A "weak"  wallet password doesn't mean a hacked account. The attacker first needs access to the wallet file file itself (unlike account password) , which isn't easy without tricking the user into installing some kind of trojan/malware.

You didn't understand my post. I'm saying that password strength rules should be enforced when encrypting the wallet as well, not just when creating an account. Obviously, an attacker needs to have the wallet in the first place in order to try to hack it.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #19 on: July 18, 2014, 08:17:57 pm »

You didn't understand my post. I'm saying that password strength rules should be enforced when encrypting the wallet as well, not just when creating an account. Obviously, an attacker needs to have the wallet in the first place in order to try to hack it.

The password doesn't have to be as strong as account password. That's why it's more user friendly. Your site nxtblocks needs to enforce stronger encryption password rules as the user is trusting you (and your server which is public) with keeping a copy of encrypted wallet. Plus hack to your server means the attacker steals hundreds/thousands of wallet files.

When it comes to local copy on user computer, let the user choose their own passwords that they can remember. Use pbkdf2 to make it stronger.

 
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

antanst

  • Full Member
  • ***
  • Karma: +36/-0
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
Re: Wallet.dat file
« Reply #20 on: July 18, 2014, 08:32:46 pm »

Indeed, we have additional reasons to enforce strong wallet passwords on nxtblocks, that's precisely why we do so. Bear in mind the following two cases though, in case a wallet is implemented within the official client:

A) The user decides to upload his encrypted wallet in a compatible web wallet service, such as nxtblocks. In this case, if his password is not strong, he will have uploaded an insecure wallet, and we can't do anything about it.

B) The wallet does not offer any additional security if the user can still create NXT accounts with custom, weak passphrases. Removing this lax behavior will pose compatibility issues for current NXT users, as they should always be able to use their existing accounts.
« Last Edit: July 18, 2014, 08:35:30 pm by antanst »
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #21 on: July 18, 2014, 08:48:50 pm »

The wallet does not offer any additional security if the user can still create NXT accounts with custom, weak passphrases. Removing this lax behavior will pose compatibility issues for current NXT users, as they should always be able to use their existing accounts.

The ability to use own passwords would not be removed. It will not be a default option. You are missing the whole "ease of use" issue. Nxt in it's current form is not a usable software for most users as no one can enter 128 bits passwords every time they login and send transactions without using additional software (like Lastpass)  or putting passwords in a plain text file and copying and pasting (which is far worse than a wallet file).

Even just 8 char encryption password with 100,000 rounds of pbKDF2 would be pretty costly to brute force (that's more difficult to bruteforce than 64 bit darknxt account ID).

Let the user use their own encryption passwords (that's the whole point of wallet file, -- ease of use), and wallet file should be implemented. It's absolutely must for security and usability -- far more important than "instant transactions"

This is one thing Nem does clearly better.
« Last Edit: July 18, 2014, 09:00:10 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

mczarnek

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
Re: Wallet.dat file
« Reply #22 on: July 18, 2014, 09:19:36 pm »

Eadeqa brings up another good point, one of the main reasons I never log in and spend time checking out the AE for is example, it because it is a hassle to dig up my password every time I want to.  Memorable password would be ok in this situation.

Instant transactions are a really cool feature, but I think we need basics first.. if someone else wants to do this, I can focus on instant transactions.
Logged
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

antanst

  • Full Member
  • ***
  • Karma: +36/-0
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
Re: Wallet.dat file
« Reply #23 on: July 18, 2014, 09:26:22 pm »

Quote
You are missing the whole "ease of use" issue.

No. I clearly stated that a wallet is primarily a convenience/usability feature in this very thread. Besides, if I would be missing it, I wouldn't have built a web wallet in the first place, would I?

The ability to use own passwords would not be removed. It will not be a default option.

Your point is that with a wallet, the user won't have as much an incentive to specify his own NXT account password, since he won't have to remember it. I agree. The thing I've been pointing out in the last posts is that especially while there are other clients that don't feature a compatible wallet out there, there will still be cases with users that, when given the choice, they will still enter their own, insecure account password. And that's unfortunate.
« Last Edit: July 18, 2014, 09:29:00 pm by antanst »
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #24 on: July 18, 2014, 09:31:06 pm »

there will still be cases with users that, when given the choice, they will still enter their own, insecure account password. And that's unfortunate.

It's going to happen far less once it's not the default option. I am not concerned about that.

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

msin

  • Hero Member
  • *****
  • Karma: +138/-18
  • Offline Offline
  • Posts: 1288
    • View Profile
Re: Wallet.dat file
« Reply #25 on: July 18, 2014, 10:33:12 pm »

Eadeqa brings up another good point, one of the main reasons I never log in and spend time checking out the AE for is example, it because it is a hassle to dig up my password every time I want to.  Memorable password would be ok in this situation.

Instant transactions are a really cool feature, but I think we need basics first.. if someone else wants to do this, I can focus on instant transactions.

mczarnek, on the topic of Instant Transactions, I think it would be great if you can tell us what kind of help you will need to expedite development, testing, and implementation as the community can definitely contribute.  As JL said, it's very important. 
Logged

mczarnek

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
Re: Wallet.dat file
« Reply #26 on: July 19, 2014, 04:48:03 am »

Eadeqa brings up another good point, one of the main reasons I never log in and spend time checking out the AE for is example, it because it is a hassle to dig up my password every time I want to.  Memorable password would be ok in this situation.

Instant transactions are a really cool feature, but I think we need basics first.. if someone else wants to do this, I can focus on instant transactions.

mczarnek, on the topic of Instant Transactions, I think it would be great if you can tell us what kind of help you will need to expedite development, testing, and implementation as the community can definitely contribute.  As JL said, it's very important.

Talked a little bit with Damelon. Think we're going to be able to figure something out. Basically, I need one other coder to help me out or it's going to take 4 months.  I'm fine doing IT instead, I realize that's important and I'm the best one for the job, given the time already spent figuring it out.

But, it's going to take me at least twice as long to implement without one, and some funds in the meantime, would be nice. Because I need to pay someone else and because at this moment, the funding will only be about 75% of minimum wage(should be same if split).. I could make more than triplet it at a full-time job and buy more Nxt that way. I think Nxt will go up and any bounty will become worth more but I hope you can see where I'm coming from.

And just to be clear, I was already asking for at least 100k more, preferably 200k before the price went down.
« Last Edit: July 19, 2014, 06:04:38 pm by mczarnek »
Logged
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #27 on: July 21, 2014, 05:50:13 am »

There is another solution that doesn't involve core (java) and can be implemented in Javascript (even browser version).

Overall it will increase usability and security, IMO.

Provide (optional) online wallet that is encrypted locally on user computer (with 200K rounds of PBKDF2). We can even provide 2FA authentication this way, and it should work with javascript as the wallet will not be  saved on user machine. (there could be optional method to save a backup or get a backup in zip file via email). 

It will work like this: the user provides an email and a password.

Hash (email + password)  with 200,000 rounds of PBKDF2, AES256 encryption key for the wallet.
one additional Hash (AES256 key) as token to login and download the wallet (with optional 2FA)

The wallet  file will be encrypted/decrypted locally on user machine.

One wallet can have multiple Nxt accounts.

We would need a reliable partner for online server, mynxtinfo or nxtblocks are obvious candidates. (maybe both sites as a way for a backup?) 

I am sure this will increase overall security and usability of Nxt. Plus 2FA will make people happy, as they will feel more "secure."  (psychological).   Even just 8 char password with 200K rounds  will provide plenty of security (plus 2FA will help too with safeguarding the wallet file).

This system can work even with "light" version of the client that does local signing  and uses public nodes.

Thoughts?
« Last Edit: July 21, 2014, 06:24:04 am by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: Wallet.dat file
« Reply #28 on: July 21, 2014, 05:59:04 am »

There is another solution that doesn't involve core (java) and can be implemented in Javascript (even browser version).

Overall it will increase usability and security, IMO.

Provide (optional) online wallet that is encrypted locally on user computer (with 200K rounds of PBKDF2). We can even provide 2FA authentication this way, and it should work with javascript as the wallet will not be  saved on user machine. (there could be optional method to save a backup). 

It will work like this: the user provides an email and a password.

Hash (email + password) -- token used by the client to login to an online server to download the wallet file (with optional google authenticator for extra security)
Hash (email + password)  with 200,000 rounds of PBKDF2, AES256 encryption key for the wallet.

The wallet  file will be encrypted/decrypted locally on user machine.

One wallet can have multiple Nxt accounts.

We would need a reliable partner for online server, mynxtinfo or nxtblocks are obvious candidates. (maybe both sites as a way for a backup?) 

I am sure this will increase overall security and usability of Nxt. Plus 2FA will make people happy, as they will feel more "secure."  (psychological).  There would not be a need for long 12 words "secret phrases". Nxt secret phrases will be auto generated and added to the user's wallet.  Even just 8 char password with 200K rounds  will provide plenty of security (plus 2FA will help too with safeguarding the wallet file).

This system will work even with "light" version of the client that does local signing  and uses public nodes.

Thoughts?
can you implement this?
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #29 on: July 21, 2014, 06:33:18 am »

can you implement this?

Would Wesley/JL agree as this requires cooperation with a third party server (mynxtinfo and/or nxtblocks)? If everyone agrees, the right person to implement it would be HumanFractal  as he has been working with 2FA and wallet ideas for a while.

I am pretty sure it increases security and usability. Plus even third party software (like MGW client) would be able to use the online wallet as it will be open source and platform neutral.


Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Berzerk

  • Hero Member
  • *****
  • Karma: +118/-40
  • Offline Offline
  • Posts: 1530
    • View Profile
Re: Wallet.dat file
« Reply #30 on: July 21, 2014, 06:38:49 am »

No third party things on the official client please.
Logged

bitcoinpaul

  • Hero Member
  • *****
  • Karma: +590/-590
  • Offline Offline
  • Posts: 3097
  • Karmageddon
    • View Profile
Re: Wallet.dat file
« Reply #31 on: July 21, 2014, 06:59:14 am »

Wtf. No third party in official client. The client update thing is centralized enough already.
Logged
Like my Avatar? Reply now! NXT-M5JR-2L5Z-CFBP-8X7P3

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #32 on: July 21, 2014, 07:13:01 am »

Wtf. No third party in official client. The client update thing is centralized enough already.

The Nxt network is isn't centralized, but the client and Java server is 100% centralized already. It's controlled by JL on server side, and Wesley on the client side, 



Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

bitcoinpaul

  • Hero Member
  • *****
  • Karma: +590/-590
  • Offline Offline
  • Posts: 3097
  • Karmageddon
    • View Profile
Re: Wallet.dat file
« Reply #33 on: July 21, 2014, 07:18:13 am »

Wtf. No third party in official client. The client update thing is centralized enough already.

The Nxt network is isn't centralized, but the client and Java server is 100% centralized already. It's controlled by JL on server side, and Wesley on the client side,

That's the excuse for throwing in some more centralized shit?
Logged
Like my Avatar? Reply now! NXT-M5JR-2L5Z-CFBP-8X7P3

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #34 on: July 21, 2014, 07:23:18 am »

That's the excuse for throwing in some more centralized shit?

It's not "centralization" . The network is decentralized. The software isn't. It's controlled and developed by developers which is 100% centralized.  It's an optional online wallet. No one has to use it. The network itself still stays the same decentralized

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

antanst

  • Full Member
  • ***
  • Karma: +36/-0
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
Re: Wallet.dat file
« Reply #35 on: July 21, 2014, 08:24:03 am »

The official NXT client should not have features that depend on third party sites/services, however lucrative those features might be.
Logged

Berzerk

  • Hero Member
  • *****
  • Karma: +118/-40
  • Offline Offline
  • Posts: 1530
    • View Profile
Re: Wallet.dat file
« Reply #36 on: July 21, 2014, 08:58:59 am »

Wtf. No third party in official client. The client update thing is centralized enough already.

The Nxt network is isn't centralized, but the client and Java server is 100% centralized already. It's controlled by JL on server side, and Wesley on the client side, 

There are many more wallets from others. Maybe one from me as well soon. So it's kind of decentralized. :)
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #37 on: July 21, 2014, 09:44:54 am »

Wtf. No third party in official client. The client update thing is centralized enough already.

The Nxt network is isn't centralized, but the client and Java server is 100% centralized already. It's controlled by JL on server side, and Wesley on the client side, 

There are many more wallets from others. Maybe one from me as well soon. So it's kind of decentralized. :)

True, but Nxt server software is centralized -- unless someone wants to write a C++ version.
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Berzerk

  • Hero Member
  • *****
  • Karma: +118/-40
  • Offline Offline
  • Posts: 1530
    • View Profile
Re: Wallet.dat file
« Reply #38 on: July 21, 2014, 09:46:50 am »

Wtf. No third party in official client. The client update thing is centralized enough already.

The Nxt network is isn't centralized, but the client and Java server is 100% centralized already. It's controlled by JL on server side, and Wesley on the client side, 

There are many more wallets from others. Maybe one from me as well soon. So it's kind of decentralized. :)

True, but Nxt server software is centralized -- unless someone wants to write a C++ version.

Sure, it can't be handled in another way.
Logged

k_day

  • Full Member
  • ***
  • Karma: +12/-0
  • Offline Offline
  • Posts: 149
    • View Profile
Re: Wallet.dat file
« Reply #39 on: July 21, 2014, 06:28:37 pm »

Guess I should add my voice to the growing chorus of us screaming please, please, please do not add services that depend on centralized resources to the client that nearly everybody uses.

I would love to have official wallet.dat support and think we should push this forward. I may not be 100% understanding the initial proposal though, so maybe someone could help clarify. As I imagined it there are two separate cases:

1)A user already has a private key and wants to create a wallet. In this case, you can give the api your private key, desired security level, and password, and it will spit out a wallet.dat that you save on your computer.

2)A new user creates an account and instead of entering a private key, enters a password. The client generates a secure private key, calls the api to create a wallet with their pw, and spits out a wallet.dat.

In each case, once you have a wallet.dat, you could easily take it to another client/machine, and unlock your account by choosing your wallet.dat and entering your wallet pw. Do I have this correct? If the wallet.dat is just a file that lives on your computer, what is the purpose of the proposed Delete/Edit wallet api methods? Wouldn't deleting a wallet just be as simple as deleting the file? Why does the core have to be involved? Sorry if I am missing something obvious.
Logged
NXT --> NXT-BY7Y-UB4X-6Z3C-8PP3V

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Wallet.dat file
« Reply #40 on: July 21, 2014, 08:10:42 pm »

I would also not want to add dependencies on external websites. Support for storing a wallet in the core would be more acceptable than having to download it every time from a website (but no way to add a 2FA then). Instead of storing it in a file, I would use the H2 database and have a separate encrypted database directory nxt_wallet, which unlike the nxt_db should be backed up and never be deleted. H2 already supports encryption of the database files.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #41 on: July 21, 2014, 08:51:17 pm »

I would also not want to add dependencies on external websites. Support for storing a wallet in the core would be more acceptable than having to download it every time from a website (but no way to add a 2FA then). Instead of storing it in a file, I would use the H2 database and have a separate encrypted database directory nxt_wallet, which unlike the nxt_db should be backed up and never be deleted. H2 already supports encryption of the database files.

That sounds fine. Can the database have more than one user? This way if two people (roommates) use the same computer they can both use it. The API could have a username and password to load their wallet. Plus a way to log off without necessarily shutting down the server. 

As for 2FA, according to HumanFractal, it's still possible. His solution involves reencrypting the wallet file with a new one time password (generated by an app on the phone) every time  the uses the old OTP, but that introduces more complexity and it's not a perfect solution, as a thief can steal the wallet file first then wait for the user to enter the OTP. It's still pretty cool trick and people might feel more secure.

I want the basic encrypted  wallet file first though. That should be easy to implement. 
 
« Last Edit: July 21, 2014, 08:55:08 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

k_day

  • Full Member
  • ***
  • Karma: +12/-0
  • Offline Offline
  • Posts: 149
    • View Profile
Re: Wallet.dat file
« Reply #42 on: July 21, 2014, 09:08:41 pm »

I would also not want to add dependencies on external websites. Support for storing a wallet in the core would be more acceptable than having to download it every time from a website (but no way to add a 2FA then). Instead of storing it in a file, I would use the H2 database and have a separate encrypted database directory nxt_wallet, which unlike the nxt_db should be backed up and never be deleted. H2 already supports encryption of the database files.

Just to clarify, would my wallet would only be stored in MY local encrypted db? I supposed this may be less good for people who are developing thin clients (like mobile) that are not running the full core/keeping a db and just interacting with the json api. Wallets support is pretty much a requirement for any mobile app.
Logged
NXT --> NXT-BY7Y-UB4X-6Z3C-8PP3V

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #43 on: July 21, 2014, 09:13:25 pm »

I would also not want to add dependencies on external websites. Support for storing a wallet in the core would be more acceptable than having to download it every time from a website (but no way to add a 2FA then). Instead of storing it in a file, I would use the H2 database and have a separate encrypted database directory nxt_wallet, which unlike the nxt_db should be backed up and never be deleted. H2 already supports encryption of the database files.

Just to clarify, would my wallet would only be stored in MY local encrypted db? I supposed this may be less good for people who are developing thin clients (like mobile) that are not running the full core/keeping a db and just interacting with the json api. Wallets support is pretty much a requirement for any mobile app.

marcus is developing a mobile app that has it's own wallet. There could even be an API to import it into mobile apps.  The problem with official client is that it's browser based (javascript) and it's not easy to implement wallet as the browser based client has limited access to the hard drive.  Clearing cache for example would delete the wallet file.  If it's done in Java, the client can talk to it via API to load/create new users etc.

Mobile apps should have no problem creating their own wallet or importing H2 wallet.
« Last Edit: July 21, 2014, 09:16:36 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #44 on: July 22, 2014, 04:45:50 am »

Can the database have more than one user? This way if two people (roommates) use the same computer they can both use it. The API could have a username and password to load their wallet. Plus a way to log off without necessarily shutting down the server. 

Another benefit  of including a "username" instead of just a password is that we trick users into stronger password. Username itself adds entropy to AES key (and acts as a salt).  So username+password would be both hashed 200K times to generate AES encryption key. Then one additional Hash (AESKey) could be used a file name for the wallet.



Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

wesley

  • Hero Member
  • *****
  • Karma: +204/-3
  • Offline Offline
  • Posts: 1159
    • View Profile
Re: Wallet.dat file
« Reply #45 on: August 01, 2014, 08:29:23 am »

So what is the bounty for this guys?  Note also that this also needs to be in a separate (client only) jar (as per discussion with JL), so it's more complex than simply implementing wallet.dat. Take that into consideration when you decide on the bounty.
« Last Edit: August 01, 2014, 08:32:46 am by wesleyh »
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #46 on: August 01, 2014, 08:32:13 am »

So what is the bounty for this guys?

This is the core feature. Shouldn't the  bounty come from tech funds?
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

wesley

  • Hero Member
  • *****
  • Karma: +204/-3
  • Offline Offline
  • Posts: 1159
    • View Profile
Re: Wallet.dat file
« Reply #47 on: August 01, 2014, 08:33:30 am »

So what is the bounty for this guys?

This is the core feature. Shouldn't the  bounty come from tech funds?

Yes of course, we are in the technical development fund committee in the applications subforum. So this is the correct place to ask for bounty size, right?  (I'm asking the tech committee)
Logged

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #48 on: August 01, 2014, 09:17:31 am »

I've spoken privately with some of you, but I should probably make known publicly that I'll be available soon to develop these features, if a sufficient bounty can be raised.

I have specific experience with secure wallet implementations and password derivation. I agree that this would greatly increase the security of NXT.

Knowing what I know now about the requirements, I estimate it'll take at least 2 weeks to develop and at least 1 week to debug and test (V1).

Please correct me if I'm missing anything- features:

V1
  • Master Key unlocks wallet.dat
  • Sub-keys derived from Master Key
  • PBKDF2 Key derivation
    • To secure the wallet.dat file
    • And to generate sub-keys
  • Future-proof derivation system
  • Contacts Storage
  • On-demand full backup
  • Custom (Import) Secret Key Storage Do we want this?

V2
  • Two Factor Authentication
  • List, Data storage
  • ...
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #49 on: August 01, 2014, 09:28:48 am »

I've spoken privately with some of you, but I should probably make known publicly that I'll be available soon to develop these features, if a sufficient bounty can be raised.

I have specific experience with secure wallet implementations and password derivation. I agree that this would greatly increase the security of NXT.

Knowing what I know now about the requirements, I estimate it'll take at least 2 weeks to develop and at least 1 week to debug and test (V1).

Please correct me if I'm missing anything- features:

V1
  • Master Key unlocks wallet.dat
  • Sub-keys derived from Master Key
  • PBKDF2 Key derivation
    • To secure the wallet.dat file
    • And to generate sub-keys
  • Future-proof derivation system
  • Contacts Storage
  • On-demand full backup
  • Custom (Import) Secret Key Storage Do we want this?

V2
  • Two Factor Authentication
  • List, Data storage
  • ...


Are you going to do this in Java (that goes in the core) or Javascript client? There are problems doing it in Javascript, as clearing browser cache will delete the wallet.

 
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #50 on: August 01, 2014, 09:29:41 am »

Are you going to do this in Java (that goes in the core) or Javascript client? There are problems doing it in Javascript, as clearing browser cache will delete the wallet.

Java.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #51 on: August 01, 2014, 09:32:17 am »

Are you going to do this in Java (that goes in the core) or Javascript client? There are problems doing it in Javascript, as clearing browser cache will delete the wallet.

Java.

Sounds good. It will need to work with the core API


 
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #52 on: August 01, 2014, 09:38:11 am »

Sounds good. It will need to work with the core API

Unless I'm mistaken, the wallet.dat code won't be interfacing much with the core, as its only job is to secure and retrieve wallets on the file system.

It will need to expose its own small API.
Logged

valarmg

  • Hero Member
  • *****
  • Karma: +178/-57
  • Offline Offline
  • Posts: 1766
    • View Profile
Re: Wallet.dat file
« Reply #53 on: August 01, 2014, 09:41:44 am »

I've spoken privately with some of you, but I should probably make known publicly that I'll be available soon to develop these features, if a sufficient bounty can be raised.


Fantastic news. I hope the bounty won't be a problem.
Logged
NXT-CSED-4PK5-AR4V-6UB5V

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #54 on: August 01, 2014, 09:42:15 am »

Sounds good. It will need to work with the core API

Unless I'm mistaken, the wallet.dat code won't be interfacing much with the core, as its only job is to secure and retrieve wallets on the file system.

It will need to expose its own small API.

Yes, but the client (written in Javascript) talks to  core via API. There would need to be API. That's part of the core.

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #55 on: August 01, 2014, 09:43:37 am »

Yes, but the client (written in Javascript) talks to  core via API. There would need to be API

Then we're all on the same page.

I'll document that once I'm sure about how we want it to work.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Wallet.dat file
« Reply #56 on: August 01, 2014, 09:54:56 am »

Why does the wallet need to be a "wallet.dat file"? We already use a database, why add another way to store and read data?

How will it work when client and server are on separate machines? Where is the wallet? Currently the client javascript does all signing and encryption on the client side, it does not send the secret phrase to the server at all. If the wallet is implemented in java and running as part of the server, once the secret phrase is extracted from the wallet it will have to be sent back to the client. Then you need to make sure your connection is secure, and also you have the secret phrase in the server memory - which is currently avoided by handling all signing and encryption client-side.


Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #57 on: August 01, 2014, 09:58:56 am »

How will it work when client and server are on separate machines? Where is the wallet?

It will not work then. The client and server need to be on the same machine for it to work. Otherwise the feature would/should be disabled and password signing would be the only option.
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

LocoMB

  • Hero Member
  • *****
  • Karma: +101/-37
  • Offline Offline
  • Posts: 751
    • View Profile
Re: Wallet.dat file
« Reply #58 on: August 01, 2014, 11:21:24 am »

One of the issues with our wallets is that it's all brainwallet and this is bad for new users.  We've all seen a couple people were were scammed and there are probably at least 20 who didn't say anything for everyone who does.

I would like to create a brainwallet API for Nxt that allows wallets and websites(such as nxtblocks.info) to all access the same wallet file on the same computer.  So wallet file will be built into the core and accessible via API calls.

This wallet file will be password protected itself, with an easier to remember password.

Thinking I'll use something like pbkdf2 to add a time delay between the password to unlock the wallet and unencrypting the wallet: https://nxtforum.org/general-discussion/peanut-butter-keeps-dogs-friendly-too-(pbkdf2)/

New estimate, instant transaction confirmations will take at least 4 months for me to complete.  I'd like something short term that can make a little bit of money and considering 3 months of work has already gone into it, I'm trying to fundraise a little in that area.  In the meantime, this is a smaller project but in light of recent developments, maybe a more necessary one and I'd like to get it done first.

So, I would like to request a bounty for implementing this.

Basic API functions will be:
Create wallet file(requires password and security level(aka time/security trade-off for PBKDF2)
Delete wallet file
Edit wallet file
Add new account(aka secret phrase)
Delete account
Get list of public keys
Get private key associated with public key
Backup wallet file to file path

Thoughts on a bounty?  I'm ready to work on this as soon as I get the green light. Thanks.

it sounds like a nice functionality to have, but maybe it needs some more definition. it sounds like a bit of a client side feature that is forced into the code.
I have had some really bad experiences with the bitcoin wallet.dat implementation, which is a one way nightmare, which is why NXT should never make it mandatory to use such a thing.
The safest wallet is a secure physical passphrase anyway- only not very user friendly, so there is delinitely use for a convenient AND safe way to do it.

How much time and what budget would you need? 
Logged
TOX
90E54E5B5213290EE616D425CADC473038CFABFA53C913271AA8559D1937DC4AF3A354A9E4E5

wesley

  • Hero Member
  • *****
  • Karma: +204/-3
  • Offline Offline
  • Posts: 1159
    • View Profile
Re: Wallet.dat file
« Reply #59 on: August 01, 2014, 11:27:48 am »

It's not forced, users will be able to choose between brainwallet or wallet.dat (in db)
Logged

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #60 on: August 01, 2014, 12:48:54 pm »

it sounds like a nice functionality to have, but maybe it needs some more definition. it sounds like a bit of a client side feature that is forced into the code.
I have had some really bad experiences with the bitcoin wallet.dat implementation, which is a one way nightmare, which is why NXT should never make it mandatory to use such a thing.
The safest wallet is a secure physical passphrase anyway- only not very user friendly, so there is delinitely use for a convenient AND safe way to do it.

How much time and what budget would you need?

You're right, this was just an outline as I see it now. This is the best method I can think to do it but I'm open to suggestions.

It's only 'wallet.dat' in spirit, we should really give it a different name as it'll be so much more than even Bitcoin's implementation. wallet.nxt  ;D

It shouldn't be mandatory but it'll enable a user to access multiple accounts derived from one Secret Key :)
Something I personally think is very much lacking with NXT.

I estimate at least 2 weeks development, 1 week debug, testing, documentation. Most likely more, bugs like to arise.

What kind of bounty is available?
I'm thinking 125K-150K
Logged

k_day

  • Full Member
  • ***
  • Karma: +12/-0
  • Offline Offline
  • Posts: 149
    • View Profile
Re: Wallet.dat file
« Reply #61 on: August 01, 2014, 04:52:55 pm »

Glad to see some traction on this! Hopefully funding won't be an issue, since this is much needed.
Logged
NXT --> NXT-BY7Y-UB4X-6Z3C-8PP3V

mczarnek

  • Hero Member
  • *****
  • Karma: +68/-4
  • Offline Offline
  • Posts: 898
    • View Profile
    • Nxt Place - Craigslist for Nxt
Re: Wallet.dat file
« Reply #62 on: August 03, 2014, 09:24:22 am »

Why does the wallet need to be a "wallet.dat file"? We already use a database, why add another way to store and read data?

How will it work when client and server are on separate machines? Where is the wallet? Currently the client javascript does all signing and encryption on the client side, it does not send the secret phrase to the server at all. If the wallet is implemented in java and running as part of the server, once the secret phrase is extracted from the wallet it will have to be sent back to the client. Then you need to make sure your connection is secure, and also you have the secret phrase in the server memory - which is currently avoided by handling all signing and encryption client-side.

You could store it in the database instead of a file.. would need to be some easy way to backup that file though.

Point is that you need to steal both this file and the passphrase in order to steal the contents of the wallet.

How often are the server side wallet and client going to be on separate machines?

Logged
NXT Organization: Tech
Donations greatly appreciated: NXT-DWVJ-G89C-RHNL-6QW6Q

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #63 on: August 03, 2014, 09:29:07 am »

You could store it in the database instead of a file.. would need to be some easy way to backup that file though.

Yes, I spoke with Wesley about this briefly. The conclusion I came to is that if I implement my features this way, it's just a storage layer and doesn't matter whether it's stored on a file or in DB.

How often are the server side wallet and client going to be on separate machines?

Uhh... Never? Am I missing something, how would this ever come up?
This is for Local clients.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #64 on: August 03, 2014, 09:57:30 am »

You could store it in the database instead of a file.. would need to be some easy way to backup that file though.

Yes, I spoke with Wesley about this briefly. The conclusion I came to is that if I implement my features this way, it's just a storage layer and doesn't matter whether it's stored on a file or in DB.


Really, there is absolutely no reason we need DB for this. Simply wallet.nxt as you suggested is fine.

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

lucky88888

  • Hero Member
  • *****
  • Karma: +42/-14
  • Offline Offline
  • Posts: 694
  • NXT-E328-UJDF-KTGH-9C6YQ
    • View Profile
Re: Wallet.dat file
« Reply #65 on: August 03, 2014, 09:59:53 am »

i think we should just forget about this passphrase "problem". people will adapt.
Logged
NXT-E328-UJDF-KTGH-9C6YQ
8897013707391239174

wesley

  • Hero Member
  • *****
  • Karma: +204/-3
  • Offline Offline
  • Posts: 1159
    • View Profile
Re: Wallet.dat file
« Reply #66 on: August 03, 2014, 10:03:31 am »

You could store it in the database instead of a file.. would need to be some easy way to backup that file though.

Yes, I spoke with Wesley about this briefly. The conclusion I came to is that if I implement my features this way, it's just a storage layer and doesn't matter whether it's stored on a file or in DB.


Really, there is absolutely no reason we need DB for this. Simply wallet.nxt as you suggested is fine.

I believe JL is concerned about file corruption during saving, etc.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Wallet.dat file
« Reply #67 on: August 03, 2014, 10:05:40 am »

The client is javascript running in the browser. The server is a java application using jetty servlets to communicate to the client using the http protocol. You cannot assume that they are on the same machine, or that they share a filesystem, or that they have any way to communicate other than http.

Where in this system is the wallet and how does it communicate to those two components?
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #68 on: August 03, 2014, 10:06:33 am »

I believe JL is concerned about file corruption during saving, etc.

This is indeed an issue which I had some plans to protect against if it's implemented as a file.

Like I said it matters little to me as far as the implementation.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #69 on: August 03, 2014, 10:11:19 am »

You could store it in the database instead of a file.. would need to be some easy way to backup that file though.

Yes, I spoke with Wesley about this briefly. The conclusion I came to is that if I implement my features this way, it's just a storage layer and doesn't matter whether it's stored on a file or in DB.


Really, there is absolutely no reason we need DB for this. Simply wallet.nxt as you suggested is fine.

I believe JL is concerned about file corruption during saving, etc.

Wallet isn't a file we change that often.  If so, make two copies  wallet.nxt and wallet.backup

The real problem is that I want more than one person using the same machine to have their own wallet.  Does DB solve that problem?


Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Wallet.dat file
« Reply #70 on: August 03, 2014, 10:19:47 am »

Browser will have "download wallet backup" and "restore wallet by uploading a backup" buttons. How wallet is actually stored is not a user concern, and may as well change in a later release.


Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #71 on: August 03, 2014, 10:34:04 am »

Browser will have "download wallet backup" and "restore wallet by uploading a backup" buttons. How wallet is actually stored is not a user concern, and may as well change in a later release.

Sounds good to me.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Wallet.dat file
« Reply #72 on: August 03, 2014, 10:41:34 am »

We agree that wallet is a client side feature, but the only reason we can't do it in the client is that javascript has restrictions reading and writing files from the filesystem. So why not just solve this problem and instead of using the filesystem for storage, use the server.

create table wallets (username varchar, wallet varbinary)

When user needs to access the wallet, javascript sends a get wallet request to server, gets the "wallet" binary blob for that user and from then on treats it as if it was read from the filesystem, except keep it in memory only. If wallet is modified, upload it back to the server using send wallet request.

The server can keep multiple, timestamped wallet records for each user. There will be two more api requests to download all wallet records for a user (as a file, generated by the server on the fly), and save them (from the browser) as a backup, and to upload such a backup to a server.

The server will not do any encryption or decryption of the binary wallet content, and no wallet passphrase (or Nxt secret passphrase) will ever be sent to the server. The client will use PBKDF2 (or some other) algorithm to encrypt and decrypt that wallet binary blob using a user supplied wallet passphrase that never leaves the browser.

Then the question is, can PBKDF2 be done all in javascript? Or is there an alternative, in javascript?
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

wesley

  • Hero Member
  • *****
  • Karma: +204/-3
  • Offline Offline
  • Posts: 1159
    • View Profile
Re: Wallet.dat file
« Reply #73 on: August 03, 2014, 10:43:17 am »

Logged

antanst

  • Full Member
  • ***
  • Karma: +36/-0
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
Re: Wallet.dat file
« Reply #74 on: August 03, 2014, 10:47:37 am »

Then the question is, can PBKDF2 be done all in javascript? Or is there an alternative, in javascript?

Yes, it can be done. http://crypto.stanford.edu/sjcl/

Wesley, feel free to look here for examples and borrow code. https://nxtblocks.info/static/js/wallet.js
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Wallet.dat file
« Reply #75 on: August 03, 2014, 10:53:15 am »

And to make it easier for the client, that server side table can have separate columns for account_id, last_modified, version, salt, and so on, so that the "wallet" binary data does not need to have any structure and not need to be parsed or constructed, just used to store the actual encrypted content.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #76 on: August 03, 2014, 10:59:39 am »

We agree that wallet is a client side feature, but the only reason we can't do it in the client is that javascript has restrictions reading and writing files from the filesystem. So why not just solve this problem and instead of using the filesystem for storage, use the server.

create table wallets (username varchar, wallet varbinary)

When user needs to access the wallet, javascript sends a get wallet request to server, gets the "wallet" binary blob for that user and from then on treats it as if it was read from the filesystem, except keep it in memory only. If wallet is modified, upload it back to the server using send wallet request.

The server can keep multiple, timestamped wallet records for each user. There will be two more api requests to download all wallet records for a user (as a file, generated by the server on the fly), and save them (from the browser) as a backup, and to upload such a backup to a server.

The server will not do any encryption or decryption of the binary wallet content, and no wallet passphrase (or Nxt secret passphrase) will ever be sent to the server. The client will use PBKDF2 (or some other) algorithm to encrypt and decrypt that wallet binary blob using a user supplied wallet passphrase that never leaves the browser.

Then the question is, can PBKDF2 be done all in javascript? Or is there an alternative, in javascript?

Makes sense. Yes, PBKDF2  can de done in javascript but it's much slower (several factor) than doing it in Java.

My own experience  50,000 rounds (with SHA2) has 3 to 4 second delay on i7. Wesley can check if 200K rounds (adds arounds 21 bits of entropy)  is possible in javascript
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #77 on: August 03, 2014, 11:03:57 am »

Makes sense. Yes, PBKDF2  can de done in javascript but it's much slower (several factor) than doing it in Java.

My own experience  50,000 rounds (with SHA2) has 3 to 4 second delay on i7. Wesley can check if 200K rounds (adds arounds 21 bits of entropy)  is possible in javascript

I have already implemented in JS Brain Wallet features that use PBKDF2 if we need it for reference.

You're right, it's much slower than Java.

One question I did have was, how many Seconds are we aiming for, to be able to open the wallet?
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #78 on: August 03, 2014, 11:07:01 am »

Makes sense. Yes, PBKDF2  can de done in javascript but it's much slower (several factor) than doing it in Java.

My own experience  50,000 rounds (with SHA2) has 3 to 4 second delay on i7. Wesley can check if 200K rounds (adds arounds 21 bits of entropy)  is possible in javascript

I have already implemented in JS Brain Wallet features that use PBKDF2 if we need it for reference.

You're right, it's much slower than Java.

One question I did have was, how many Seconds are we aiming for, to be able to open the wallet?

Not more than 2 seconds would be my guess
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #79 on: August 03, 2014, 11:11:05 am »

Not more than 2 seconds would be my guess

Follow up question - have we decided on a set of minimum wallet password requirements?

EDIT: Let me just throw this out there - I suggest using a random generator that outputs sets of mnemonic words from the list of 2048 words from BIP39. Each word = 11 bits. I suggest minimum 4 words.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #80 on: August 03, 2014, 11:13:46 am »

Not more than 2 seconds would be my guess

Follow up question - have we decided on a set of minimum wallet password requirements?

Absolutely not. That point of wallet is to make it user friendly. User makes a password (or no password, but that shouldn't be the option).  If we are going to enforce password rules, then what's the point? Stick with nxt secret phrase
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #81 on: August 03, 2014, 11:15:16 am »

Absolutely not. That point of wallet is to make it user friendly. User makes a password (or no password, but that shouldn't be the option).  If we are going to enforce password rules, then what's the point? Stick with nxt secret phrase

The full master secret phrase is the same as the wallet password then?

I was not sure it was supposed to be this way or the other.
JL what's your thought on the matter?
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #82 on: August 03, 2014, 11:19:08 am »

The full master secret phrase is the same as the wallet password then?

The point of wallet is that user can choose smaller encryption password instead of typing the 50 char 12 words. It's more user friendly.

What's the full master secret phrase?

The wallet has secret keys for Nxt account, but those secret keys are randomly generated. 
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #83 on: August 03, 2014, 11:31:22 am »


  • Master Key unlocks wallet.dat
  • Sub-keys derived from Master Key

Is Master Key key derived from the user password and  Sub-keys secret phrases for Nxt accounts? 

If yes, that isn't secure. Nxt secret phrases should be random and should have no relation to user password.


Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #84 on: August 03, 2014, 12:01:40 pm »

We agree that wallet is a client side feature, but the only reason we can't do it in the client is that javascript has restrictions reading and writing files from the filesystem. So why not just solve this problem and instead of using the filesystem for storage, use the server.

create table wallets (username varchar, wallet varbinary)

When user needs to access the wallet, javascript sends a get wallet request to server, gets the "wallet" binary blob for that user and from then on treats it as if it was read from the filesystem, except keep it in memory only. If wallet is modified, upload it back to the server using send wallet request.

The server can keep multiple, timestamped wallet records for each user. There will be two more api requests to download all wallet records for a user (as a file, generated by the server on the fly), and save them (from the browser) as a backup, and to upload such a backup to a server.

The server will not do any encryption or decryption of the binary wallet content, and no wallet passphrase (or Nxt secret passphrase) will ever be sent to the server. The client will use PBKDF2 (or some other) algorithm to encrypt and decrypt that wallet binary blob using a user supplied wallet passphrase that never leaves the browser.

Then the question is, can PBKDF2 be done all in javascript? Or is there an alternative, in javascript?

Just to be clear: Are you going to do the server part yourself? Make the API and DB.

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #85 on: August 03, 2014, 12:02:52 pm »


  • Master Key unlocks wallet.dat
  • Sub-keys derived from Master Key

Is Master Key key derived from the user password and  Sub-keys secret phrases for Nxt accounts? 

If yes, that isn't secure. Nxt secret phrases should be random and should have no relation to user password.

Here's the system as I would suggest to build it.

User creates a Master Secret Key, at least 32 bytes of entropy, randomly generated.
----
The user then is assigned a minimum 4-word mnemonic as their password (44bits)
OR
The user picks their own password with password complexity requirements
OR
The user picks whatever password they want - no requirements
---
The master secret key (and any other data we might be storing) will be encrypted using the PBKDF2 derivation of the password.
The derivation should be done in Java ideally since it's so much faster.
I'll figure out how many iterations will be needed for a system like this to be secure.
---
Sub keys will be deterministically based on the Master Key, not the short password. It will most likely using some form of PBKDF2 to create the chain.
I have already coded a system to compute a chain like this securely.
---
On initial creation the user should be prompted to print at least 2 copies of the original encrypted data. This can be done as a print out with 2 sections on one page.
---

If you read JL post, there is neither wallet.dat nor wallet.nxt. He wants to store the encrypted blob in the database and let the javascript client do everything else.

I need something to call it, or are we calling it wallet.db now?

I am not sure if JL himself wants to do the server part of it. The server isn't doing anything but storing the blob. Everything is done by the client. If you want to do it, you should do the client part. Talk to Wesley.

If this is being implemented client side I have something else that should be taken into consideration, which is a Local 2FA system I already have working. It's all JavaScript and uses PBKDF2 and Google Auth codes to unlock the wallet. In this system the 2FA part is optional so it could just be a password and no 2FA.

https://nxtforum.org/cryptopapers/(feature)-local-two-factor-authentication-for-cryptopapers-and-any-client-app/


« Last Edit: August 03, 2014, 12:07:49 pm by HumanFractal »
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #86 on: August 03, 2014, 12:20:35 pm »

Here's the system as I would suggest to build it.

User creates a Master Secret Key, at least 32 bytes of entropy, randomly generated.
----
The user then is assigned a minimum 4-word mnemonic as their password (44bits)
OR
The user picks their own password with password complexity requirements
OR
The user picks whatever password they want - no requirements
---
The master secret key (and any other data we might be storing) will be encrypted using the PBKDF2 derivation of the password.
The derivation should be done in Java ideally since it's so much faster.
I'll figure out how many iterations will be needed for a system like this to be secure.
---
On initial creation the user should be prompted to print at least 2 copies of the original encrypted data. This can be done as a print out with 2 sections on one page.

The user should pick whatever password as the whole point of wallet is to make it user friendly -- not to introduce more complexity by asking them to remember 4-word mnemonic or enforcing password strength. 

Why does it matter if derivation is faster in java if Master Secret Key is random? The hacker still has to steal both the Master Secret Key and password to steal nxt, right? 2 sec delay in javascript is sufficient.

Are all Nxt accounts derived from Master Secret Key?

« Last Edit: August 03, 2014, 12:30:42 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #87 on: August 03, 2014, 12:27:07 pm »

The user should pick whatever password as the whole point of wallet is to make it user friendly -- not to introduce more complexity by asking them to remember 4-word mnemonic or enforcing password strength. 

Why does it matter if derivation is faster in java if Master Secret Key is random? The hacker still have to steal both the Master Secret Key and password to steal nxt, right? 2 sec delay in javascript is sufficient.

Are all Nxt accounts derived from Master Secret Key?

I think what maybe isn't coming across is that in a system like this, even with PBKDF2, the data contained is exactly as secure as that password is complex.

IMO enforcing some BASIC password requirements is a must.

In my own experience and calculations I find that 4-word mnemonic phrases give the best bits of entropy, and are much easier to remember than other password types for how much entropy it provides. EDIT: if 4 is too much the minimum can be 3.

In the JS 2FA system I have written, the user is able to choose from several options for passwords mnemonic, numeric, even a QR code to print out and scan, or enter their own custom password. We could do something like this
« Last Edit: August 03, 2014, 12:31:15 pm by HumanFractal »
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #88 on: August 03, 2014, 12:41:43 pm »

The user should pick whatever password as the whole point of wallet is to make it user friendly -- not to introduce more complexity by asking them to remember 4-word mnemonic or enforcing password strength. 

Why does it matter if derivation is faster in java if Master Secret Key is random? The hacker still have to steal both the Master Secret Key and password to steal nxt, right? 2 sec delay in javascript is sufficient.

Are all Nxt accounts derived from Master Secret Key?

I think what maybe isn't coming across is that in a system like this, even with PBKDF2, the data contained is exactly as secure as that password is complex.

IMO enforcing some BASIC password requirements is a must.

In my own experience and calculations I find that 4-word mnemonic phrases give the best bits of entropy, and are much easier to remember than other password types for how much entropy it provides. EDIT: if 4 is too much the minimum can be 3.

In the JS 2FA system I have written, the user is able to choose from several options for passwords mnemonic, numeric, even a QR code to print out and scan, or enter their own custom password. We could do something like this

I understand the security issue, but if the user can't pick his own password, then why do we need a wallet anyway? Given that both the wallet file (which is never on the blockchain) and password must be stolen, already increases security. Plus we are using PBKDF already to ,make the attack difficult if just wallet stolen.

The whole thing sounds total waste of time if the user can't even pick his own password.

Basically we are back to square zero

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #89 on: August 03, 2014, 12:44:37 pm »

I understand the security issue, but if the user can't pick his own password, then why do we need a wallet anyway? Given that both the wallet file (which is never on the blockchain) and password must be stolen, already increases security. Plus we are using PBKDF already to ,make the attack difficult if wallet stolen.

The whole thing sounds total waste of time if the user can't even pick his own password.

By what reasoning is it a waste of time unless the user can choose whatever password they want, even if it's 1 character long?

I'm just saying there should be some requirement. I didn't even begin to suggest what that should be.
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Wallet.dat file
« Reply #90 on: August 03, 2014, 12:45:09 pm »

Just to be clear: Are you going to do the server part yourself? Make the API and DB.
I don't have to do that myself, as it is a standalone feature, and is really simple.

It will be a separate db, optionally encrypted, stored in nxt_wallet_db subdirectory. The server will not even try to connect to it on startup, only the first time a request for a wallet is made, and at that time the database encryption password will need to be supplied too. Users sharing the same computer will have to share this password too, but within the db each user wallet will be personal and have its own password. The benefit of having the whole db encrypted too is that an attacker getting access to the hard disk will not be able to get private info - such as the user account_ids that are being accessed from this computer, last modified dates, and so on. And such an attacker would need to break both the db AES encryption, and the individual wallets PBKDF2. Of course if both passwords are weak, this doesn't add security.
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #91 on: August 03, 2014, 12:53:06 pm »


By what reasoning is it a waste of time unless the user can choose whatever password they want, even if it's 1 character long?

It's a a waste of time because we can just simply enforce strict password requirements for secret phrase . The point of wallet is to make it more friendly. The user picks his own password, PBKDF2 makes it even stronger,  pus the wallet is NOT on the blackchain. That alone increase security by a factor of billion.

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #92 on: August 03, 2014, 12:55:19 pm »

It's a a waste of time because we can just simply enforce strict password requirements for secret phrase . The point of wallet is to make it more friendly. The user picks his own password, PBKDF2 makes it even stronger,  pus the wallet is NOT on the blackchain. That alone increase security by a factor of billion.

The secret key is stored Behind this password. If the password is ' ' and an attacker obtains the DB, it doesn't matter HOW complex the secret key is, it's lost!

Yes PBKDF2 makes the encryption stronger, but the attacker will probably need to compute less than 10 times to crack a DB with ' ' as a password.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #93 on: August 03, 2014, 01:04:15 pm »

The secret key is stored Behind this password. If the password is ' ' and an attacker obtains the DB, it doesn't matter HOW complex the secret key is, it's lost!

How would attacker steal DB? It's not on the blockchain. If an attacker can steal files from your hard drive, long passwords aren't going to help, as he can also steal whatever you type, and maybe he can steal Nxt secret phrases from the memor by  forcing memory dump (by lowering the system memory by running random processes).

There is no reason to start with the assumption that DB could be easily stolen, and why do we need PBKDF2 anyway if we are going to pick encryption password for the users?

None of the software that I use (bitcoin wallet, electrum,  Truecrypt, Latpass, Keepass), enforce password encryption rules on the user -- and it's far more dangerous as user is likely to forget his password and lose his money. 
« Last Edit: August 03, 2014, 01:07:20 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #94 on: August 03, 2014, 01:07:50 pm »

By your logic, why encrypt at all?? If they can get on the computer then they can steal the keystrokes, right?
Since when did ease of use trump security when dealing with money?

This conversation is no longer productive and is distracting from the more important issue, which is, are the funds even available for the bounty?

FYI If we are going the client-side route and decide to use my existing, already working 2FA scripts then the bounty cost would be less.
« Last Edit: August 03, 2014, 01:18:48 pm by HumanFractal »
Logged

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: Wallet.dat file
« Reply #95 on: August 03, 2014, 01:24:06 pm »

If there are performance issues with javascript pbkdf2 processing, it could optionally be done server side too, at the expense of having to maintain that code in both places. We already do something similar when creating transactions - either include the secretPhrase parameter and let the server do the signing, or include publicKey and sign the returned transaction bytes client side. Similarly for wallets, either send "getWallet" request and get the encrypted wallet, or add an optional walletPassword parameter, and if that is present server also handles wallet decryption (and gets to know both secret phrase and wallet passwd, so only use with trusted server).
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #96 on: August 03, 2014, 01:26:00 pm »

If there are performance issues with javascript pbkdf2 processing, it could optionally be done server side too, at the expense of having to maintain that code in both places. We already do something similar when creating transactions - either include the secretPhrase parameter and let the server do the signing, or include publicKey and sign the returned transaction bytes client side. Similarly for wallets, either send "getWallet" request and get the encrypted wallet, or add an optional walletPassword parameter, and if that is present server also handles wallet decryption (and gets to know both secret phrase and wallet passwd, so only use with trusted server).

Mere moments before you posted this I realized - the PBKDF2 could alone be handed off to the Java and let the JS do everything else.

 ;D
« Last Edit: August 03, 2014, 01:28:41 pm by HumanFractal »
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #97 on: August 03, 2014, 01:45:47 pm »

Ok, last post on enforcing rules. Wesley will do whatever he thinks is right. 

Nxt in it's current form is not usable software for average joe, as it requires users to type curve25119 private keys  as passwords . That is fine with me, but for grandmothers,  we need to make it user friendly. That was the reason for introducing wallet file. Now enforcing passwords rules for something the user saves on his own hard drive  -- that is not only unnecessary but we are basically back to square one.
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #98 on: August 03, 2014, 01:46:56 pm »

Ok, last post on enforcing rules. Wesley will do whatever he thinks is right. 

Yes, in the end Wesley will be coding this part, not me.
Logged

LocoMB

  • Hero Member
  • *****
  • Karma: +101/-37
  • Offline Offline
  • Posts: 751
    • View Profile
Re: Wallet.dat file
« Reply #99 on: August 03, 2014, 01:49:43 pm »


well obviously there is a lot of interest in this. so how much of a budget would be needed?
Logged
TOX
90E54E5B5213290EE616D425CADC473038CFABFA53C913271AA8559D1937DC4AF3A354A9E4E5

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #100 on: August 03, 2014, 01:56:07 pm »


well obviously there is a lot of interest in this. so how much of a budget would be needed?

I didn't know that my existing system could be an option for this until now.

My previously stated bounty was for a custom Java implementation not including 2FA.

I think I need to figure out exactly how much will need to change from my current implementation to work for NXT. This will determine how much work it'll be (besides the time already spent)
Logged

antanst

  • Full Member
  • ***
  • Karma: +36/-0
  • Offline Offline
  • Posts: 216
    • View Profile
    • nxtblocks.info
Re: Wallet.dat file
« Reply #101 on: August 03, 2014, 02:05:51 pm »

It will be a separate db, optionally encrypted, stored in nxt_wallet_db subdirectory. The server will not even try to connect to it on startup, only the first time a request for a wallet is made, and at that time the database encryption password will need to be supplied too. Users sharing the same computer will have to share this password too, but within the db each user wallet will be personal and have its own password.

So in effect each user should remember two passwords, the DB password and his wallet's password, right? Why do all those things in the first place, and don't simply store the encrypted wallet blob? The private keys and the contacts are virtually the only things a wallet needs to have, all the rest can be computed in Javascript when the wallet is loaded and decrypted in memory.
Logged

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #102 on: August 03, 2014, 02:30:15 pm »

So in effect each user should remember two passwords, the DB password and his wallet's password, right? Why do all those things in the first place, and don't simply store the encrypted wallet blob? The private keys and the contacts are virtually the only things a wallet needs to have, all the rest can be computed in Javascript when the wallet is loaded and decrypted in memory.

The way I see it, can a human being actually remember a NXT secret key that's "secure enough"? No.

I want the master key to be backed up by file or paper printout initially and at any point in the future in case of hard drive failure (or many other types of unavoidable disaster)

So the secret key will be stored encrypted in the wallet.nxt or DB and they just need to remember their much shorter password to unlock it.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #103 on: August 03, 2014, 06:47:29 pm »

I want the master key to be backed up by file or paper printout initially and at any point in the future in case of hard drive failure (or many other types of unavoidable disaster)

This printout thing is cool if true.  Is print out encrypted?


 
« Last Edit: August 03, 2014, 07:21:14 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #104 on: August 03, 2014, 07:21:58 pm »

By the way, if PBKDF adds only 10 millisecond delay for the attacker, cracking a six character password requires an average of 9 years.

10 millisecond delay means the attacker can only check 100 passwords per second. That's too slow for cracking 6 char password.

62^6 / 2 / 100 / 3600 / 24 / 365 = 9 years

I see no reason to enforce password rules with  PBKDF2

Too bad BCNext didn't implement this in the core for Nxt secret phrase before the release. 
« Last Edit: August 03, 2014, 07:58:47 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #105 on: August 03, 2014, 09:29:23 pm »

I think there should be faux username+password login treated as password for PBKDF encryption on wallet.nxt

Users should always be able to pick whaterever they want and just enter password only if they wanted (probably advanced users). Only requirement is a minimum length,  for example 8+8, or 16 char length password only.

This will give us the best user experience by adopting industry standard, this means even my dad would be able to login to Nxt without feeling confused.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #106 on: August 04, 2014, 05:55:31 am »

By the way, if PBKDF adds only 10 millisecond delay for the attacker, cracking a six character password requires an average of 9 years.

10 millisecond delay means the attacker can only check 100 passwords per second. That's too slow for cracking 6 char password.

62^6 / 2 / 100 / 3600 / 24 / 365 = 9 years

I see no reason to enforce password rules with  PBKDF2

Too bad BCNext didn't implement this in the core for Nxt secret phrase before the release. 

Here is where you are wrong. Where'd you get 62? Unless theres a password requirement then the user could enter all lower case letters (or worse - 'aaaaaa' ).

If they just used lower case the math is:

26^6 / 2 / 100 / 3600 / 24 / 365 = 18 days

This also doesn't even take into account massive arrays of computers, which would make me feel that even 9 years (on one machine) would not be enough when looking at massive server farms.

Once again: Any system based on a password is only as secure as that password is complex
« Last Edit: August 04, 2014, 05:59:57 am by HumanFractal »
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #107 on: August 04, 2014, 06:05:08 am »

By the way, if PBKDF adds only 10 millisecond delay for the attacker, cracking a six character password requires an average of 9 years.

10 millisecond delay means the attacker can only check 100 passwords per second. That's too slow for cracking 6 char password.

62^6 / 2 / 100 / 3600 / 24 / 365 = 9 years

I see no reason to enforce password rules with  PBKDF2

Too bad BCNext didn't implement this in the core for Nxt secret phrase before the release. 

Here is where you are wrong. Where'd you get 62? Unless theres a password requirement then the user could enter all lower case letters (or worse - 'aaaaaa' ).

If they just used lower case the math is:

26^6 / 2 / 100 / 3600 / 24 / 365 = 18 days


Don't forget we have username name field too that will/should be used, so if his user name is bobby, even with all small letters, you are back to

26^12 / 2 / 100 / 3600 / 24 / 365  = 15 million years.

That''s assuming the wallet would be stolen (a big assumption), and if the wallet is stolen from user hard drive, so could be the long password he is typing.

Neither, Electrum, nor QT, nor lastlass, nor truecrypt force users with password restrictions  -- -- that isn't  user friendly. If the user can't choose the password, then we need to simply disable weak password for nxt secret phrase and be done with it. There is no need for wallet.

« Last Edit: August 04, 2014, 06:09:59 am by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #108 on: August 04, 2014, 06:07:49 am »

Don't forget we have username name field too that will/should be used, so if his user name is bobby, even with all small letters, you are back to

26^12 / 2 / 100 / 3600 / 24 / 365  = 15 million years.

That''s assuming the wallet would be stolen (a big assumption), and if the wallet is stolen from user hard drive, so could be the long password he is typing.

Neiiter, Electrum, bot bitcoin QT, nor lastlass, nor truecrypt force users to pick a password the software -- that isn't  user friendly.

That's the first I've heard about a username being used.

Yes this adds extra data, the problem is that this user name, depending on what they pick, may or may not be easily guessable by a hacker that knows their target, or is willing to do the peeking required to find out the user's name. This is not hard.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #109 on: August 04, 2014, 06:13:40 am »

Don't forget we have username name field too that will/should be used, so if his user name is bobby, even with all small letters, you are back to

26^12 / 2 / 100 / 3600 / 24 / 365  = 15 million years.

That''s assuming the wallet would be stolen (a big assumption), and if the wallet is stolen from user hard drive, so could be the long password he is typing.

Neiiter, Electrum, bot bitcoin QT, nor lastlass, nor truecrypt force users to pick a password the software -- that isn't  user friendly.

That's the first I've heard about a username being used.

Yes this adds extra data, the problem is that this user name, depending on what they pick, may or may not be easily guessable by a hacker that knows their target, or is willing to do the peeking required to find out the user's name. This is not hard.

If the hacker has so much info on the user and has so much controls on user machine, he might just install a keylogger and be done with it.


Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #110 on: August 04, 2014, 06:17:03 am »

If the hacker has so much info on the user and has so much controls on user machine, he might just install a keylogger and be done with it.

Is it inconceivable that an attacker or virus only has file system access? They're not ALL keyloggers.

Eadeqa what is your background with programming and security?
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #111 on: August 04, 2014, 06:30:11 am »

Is it inconceivable that an attacker or virus only has file system access? They're not ALL keyloggers.

No, it's not inconceivable, but  installing a keyloggers isn't harder than stealing files from hard driver and then snooping around to guess username.

Quote
Eadeqa what is your background with programming and security?

I have plenty of experience  in game development, but that is irrelevant. You are asking to enforce password rules, something that is not done by other  security software (electrum, bitcoin qt, lastpass, trucrypt,) which basically makes wallet (and PBKF2)  unnecessary   as we just just  enforce stronger rules and be done with it.

Let the user pick password instead of demanding  they follow your rules. I had a 22  char password for etherium sale, but it was rejected as "special charter" was a requirement. Now that's idiotic.
« Last Edit: August 04, 2014, 06:33:30 am by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #112 on: August 04, 2014, 06:34:25 am »

The other thing I should mention is that, as Jean-Luc will point out, this setup will be used primarily locally, but will need to be used in situations where the server storing the encrypted data is NOT trusted.

This makes it exponentially more important that the encryption we use is Secure, and presents the exact situation where a potential attacker has ONLY read-only access to the encrypted data.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #113 on: August 04, 2014, 06:40:54 am »

The other thing I should mention is that, as Jean-Luc will point out, this setup will be used primarily locally, but will need to be used in situations where the server storing the encrypted data is NOT trusted.

The plan was to use wallet only when connected to localhost. It will be disabled in if not connected to localhost. I sure hope no one is planning to allow wallet with public nodes as the server might delete your files.

It's only option on localhost.

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #114 on: August 04, 2014, 06:41:58 am »

The other thing I should mention is that, as Jean-Luc will point out, this setup will be used primarily locally, but will need to be used in situations where the server storing the encrypted data is NOT trusted.

The plan was to use wallet only when connected to localhost. It will be disabled in if not connected to localhost. I sure as hell hope no one is planning to allow wallet with public nodes as the server might delete your files.

It's only option on localhost.

That's what I thought too, but he says otherwise. Talk to him.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #115 on: August 04, 2014, 06:43:15 am »

The other thing I should mention is that, as Jean-Luc will point out, this setup will be used primarily locally, but will need to be used in situations where the server storing the encrypted data is NOT trusted.

The plan was to use wallet only when connected to localhost. It will be disabled in if not connected to localhost. I sure as hell hope no one is planning to allow wallet with public nodes as the server might delete your files.

It's only option on localhost.

That's what I thought too, but he says otherwise. Talk to him.

Where did he say that? I saw him ask a question but he never said users should be able to use wallet with untrusted public nodes. The files could all get deleted.
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

CryptKeeper

  • Hero Member
  • *****
  • Karma: +78/-5
  • Offline Offline
  • Posts: 1235
    • View Profile
Re: Wallet.dat file
« Reply #116 on: August 04, 2014, 06:50:54 am »

A completely different idea:

Let the user choose an arbitrary file for the pass phrase salt, like a family jpg or something like that. Would be very easy to implement in the client, needs a file open dialog from the browser and a function to create a hash from the file content to use as salt. I think this is a option in truecrypt and keepass, it's something you know + something you have.
Logged
Follow me on twitter for the latest news on bitcoin and altcoins!
Vanity Accounts Sale :-)

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #117 on: August 04, 2014, 06:56:40 am »

A completely different idea:

Let the user choose an arbitrary file for the pass phrase salt, like a family jpg or something like that. Would be very easy to implement in the client, needs a file open dialog from the browser and a function to create a hash from the file content to use as salt. I think this is a option in truecrypt and keepass, it's something you know + something you have.

That's fine if it's optional. It's pretty good for all the paranoids by the way who keep asking for 2FA. Just tell them to keep the jpeg in USB drive and not the hard drive :)

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

CryptKeeper

  • Hero Member
  • *****
  • Karma: +78/-5
  • Offline Offline
  • Posts: 1235
    • View Profile
Re: Wallet.dat file
« Reply #118 on: August 04, 2014, 07:08:33 am »


A completely different idea:

Let the user choose an arbitrary file for the pass phrase salt, like a family jpg or something like that. Would be very easy to implement in the client, needs a file open dialog from the browser and a function to create a hash from the file content to use as salt. I think this is a option in truecrypt and keepass, it's something you know + something you have.

That's fine if it's optional. It's pretty good for all the paranoids by the way who keep asking for 2FA. Just tell them to keep the jpeg in USB drive and not the hard drive :)

Optional of course.
Great idea with the usb drive ( you can call me paranoid too, I'm running the client in a VM ).
Logged
Follow me on twitter for the latest news on bitcoin and altcoins!
Vanity Accounts Sale :-)

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #119 on: August 04, 2014, 07:13:57 am »

A completely different idea:

Let the user choose an arbitrary file for the pass phrase salt, like a family jpg or something like that. Would be very easy to implement in the client, needs a file open dialog from the browser and a function to create a hash from the file content to use as salt. I think this is a option in truecrypt and keepass, it's something you know + something you have.

That's fine if it's optional. It's pretty good for all the paranoids by the way who keep asking for 2FA. Just tell them to keep the jpeg in USB drive and not the hard drive :)
That is a good idea but is more focused towards advanced users, what we need now is basic wallet.nxt support so new average joes can use our software and be secure.

Advanced users already have the current brain wallet. Although this could an idea for future improvements to the login method.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #120 on: August 04, 2014, 07:27:27 am »

A completely different idea:

Let the user choose an arbitrary file for the pass phrase salt, like a family jpg or something like that. Would be very easy to implement in the client, needs a file open dialog from the browser and a function to create a hash from the file content to use as salt. I think this is a option in truecrypt and keepass, it's something you know + something you have.

That's fine if it's optional. It's pretty good for all the paranoids by the way who keep asking for 2FA. Just tell them to keep the jpeg in USB drive and not the hard drive :)
That is a good idea but is more focused towards advanced users, what we need now is basic wallet.nxt support so new average joes can use our software and be secure.

Advanced users already have the current brain wallet. Although this could an idea for future improvements to the login method.

I agree, but you will notice there are are a lot paranoid posters here who demand 2FA. It's not really 2FA (as jpeg is static) but it still will make some people "happier" if they don't store the keyfile on the hard drive.

Yes, we need simple wallet functionality (preferably identical to Electrum that only needs a seed to recreate the wallet in case file is deleted).


Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #121 on: August 04, 2014, 07:38:24 am »



A completely different idea:

Let the user choose an arbitrary file for the pass phrase salt, like a family jpg or something like that. Would be very easy to implement in the client, needs a file open dialog from the browser and a function to create a hash from the file content to use as salt. I think this is a option in truecrypt and keepass, it's something you know + something you have.

That's fine if it's optional. It's pretty good for all the paranoids by the way who keep asking for 2FA. Just tell them to keep the jpeg in USB drive and not the hard drive :)
That is a good idea but is more focused towards advanced users, what we need now is basic wallet.nxt support so new average joes can use our software and be secure.

Advanced users already have the current brain wallet. Although this could an idea for future improvements to the login method.

I agree, but you will notice there are are a lot paranoid posters here who demand 2FA. It's not really 2FA (as jpeg is static) but it still will make some people "happier" if they don't store the keyfile on the hard drive.

Yes, we need simple wallet functionality (preferably identical to Electrum that only needs a seed to recreate the wallet in case file is deleted).

Agreed, ideally I might want to use jpeg method. But I think the focus now should be on something simple for new users.

Wouldn't the Nxt secret phrase be entered at the login giving the user the ability to create a new wallet.nxt? Virtually same as electrum.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #122 on: August 04, 2014, 08:20:46 am »

Wouldn't the Nxt secret phrase be entered at the login giving the user the ability to create a new wallet.nxt? Virtually same as electrum.

I would rather not give the user an option to enter his own seed (Electrum does not). Seed should be randomly generated. The user should print/save it as a backup to restore the wallet.

By the way, speaking of Electrum and password rules, for some accounts with the small amount of money that I used very often,  I only used 3 char password. It was convenient as I had to use it every day (to make payments to sellers) That's another thing I wouldn't have been able to do if there were passwords  rules, regardless if in this case I didn't really need it nor wanted it.
« Last Edit: August 04, 2014, 08:34:24 am by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #123 on: August 04, 2014, 09:42:33 am »

Wouldn't the Nxt secret phrase be entered at the login giving the user the ability to create a new wallet.nxt? Virtually same as electrum.

I would rather not give the user an option to enter his own seed (Electrum does not). Seed should be randomly generated. The user should print/save it as a backup to restore the wallet.

By the way, speaking of Electrum and password rules, for some accounts with the small amount of money that I used very often,  I only used 3 char password. It was convenient as I had to use it every day (to make payments to sellers) That's another thing I wouldn't have been able to do if there were passwords  rules, regardless if in this case I didn't really need it nor wanted it.

...


I only used 3 char password.

...

I could bruteforce that by hand.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #124 on: August 04, 2014, 09:46:51 am »

Wouldn't the Nxt secret phrase be entered at the login giving the user the ability to create a new wallet.nxt? Virtually same as electrum.

I would rather not give the user an option to enter his own seed (Electrum does not). Seed should be randomly generated. The user should print/save it as a backup to restore the wallet.

By the way, speaking of Electrum and password rules, for some accounts with the small amount of money that I used very often,  I only used 3 char password. It was convenient as I had to use it every day (to make payments to sellers) That's another thing I wouldn't have been able to do if there were passwords  rules, regardless if in this case I didn't really need it nor wanted it.

...


I only used 3 char password.

...

I could bruteforce that by hand.

For that to happen you have to steal my wallet first. The chances of that happening are zilch. Try it please

The point stands: I don't always want software to tell me what password I should use, especially not in this case, where wallet is on my hard drive.

« Last Edit: August 04, 2014, 09:49:11 am by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #125 on: August 04, 2014, 09:52:25 am »

For that to happen you have to steal my wallet first. Thew chances of that happening are zilch. Try it please

Of course I know that. If someone were able to steal your wallet, we want it to be difficult (if we can, impossible) to crack.

It's going to happen, if not to you then to somebody else. It can't be stopped. Wallets will be compromised.

A 3 character password is almost entirely pointless and is only very slightly better than using no password at all.
« Last Edit: August 04, 2014, 09:55:54 am by HumanFractal »
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #126 on: August 04, 2014, 09:56:47 am »


Of course I know that. If someone were able to steal your wallet, we want it to be difficult to crack.

It's going to happen, if not to you then to somebody else. It can't be stopped. Wallets will be compromised.


A user should make a stronger password if they think it can happen. Let them make the decision. There is no software that enforces password rules on files that are in 100% under user control.  It's not a server login.

Quote
A 3 character password is almost entirely pointless and is only very slightly better than using no password at all.

No really. It stops any of my friends in the house messing with it. It's good enough for that. 
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #127 on: August 04, 2014, 09:57:43 am »


Of course I know that. If someone were able to steal your wallet, we want it to be difficult to crack.

It's going to happen, if not to you then to somebody else. It can't be stopped. Wallets will be compromised.


A user should a stronger password if they think it can happen. Let them make the decision. There no software that enforces password rules on files that are in 100% under user control.  It's not a server login.

Except when it is. Talk to Jean Luc, it is the way it is.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #128 on: August 04, 2014, 10:02:57 am »

Except when it is. Talk to Jean Luc, it is the way it is.

JL said nothing about about enforcing passwords rules on wallet.  He was talking about enforcing rules on Nxt secret phrase.  There is no software that forces me to use programmer passwords to encrypt  files on my hard drive.   If we are going to enforce password rules anyway despite introducing wallet, we then don't need a wallet file.

I change my vote.  Lets move to something else as apparently this is pretty useless and I won't use it.

« Last Edit: August 04, 2014, 10:06:16 am by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #129 on: August 04, 2014, 10:07:43 am »

Wouldn't the Nxt secret phrase be entered at the login giving the user the ability to create a new wallet.nxt? Virtually same as electrum.

I would rather not give the user an option to enter his own seed (Electrum does not). Seed should be randomly generated. The user should print/save it as a backup to restore the wallet.

By the way, speaking of Electrum and password rules, for some accounts with the small amount of money that I used very often,  I only used 3 char password. It was convenient as I had to use it every day (to make payments to sellers) That's another thing I wouldn't have been able to do if there were passwords  rules, regardless if in this case I didn't really need it nor wanted it.

Generally speaking the seed (secret phrase) is always randomly generated for new users, but I like the current option for advanced users to create their own as mine is much longer than the standard.

The only reason I suggest simple password rules is protect new users, as if they a enter week pass their funds could be stolen if anyone get access to their wallet. I think rules should be set at whatever we deem to be secure enough not to be hacked easily vs annoyance. But the max annoyance for rules would be the standard web ones users are already used to (for example 8 min char, numbers + letters, upper case & lower case). 

I don’t think we should ever get rid of wallet password requirements completely, as new users might use password ‘123’ and when they transfer their wallet through gmail/drop box (as they will do) it would be very easy to be hacked.

Personally Eadeqa I think your case of ‘needing’ a short password is fairly rare, and would only take an extra split second to enter a few more digits to get to the min length password. However maybe there is an argument that these should be password suggestions but aren’t enforced.

I think a PBKF2 encrypted password of at least 16 char (8+8) would be safe enough for users to be a bit careless with their wallets, which in the real world they are going to be.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #130 on: August 04, 2014, 10:10:04 am »

Except when it is. Talk to Jean Luc, it is the way it is.

JL said nothing about about enforcing passwords rules on wallet.  He was talking about enforcing rules on Nxt secret phrase.  If we are going to enforce password rules anyway despite introducing wallet, we don't then need a wallet file.

I change my vote.  Lets move to something else as we don't need wallet as password rules are good enough, apparently.

There's a vote?

I never said it was decided. It will be decided, maybe by wesley alone or maybe by a group.

All I will say is that we will not release a system that's insecure.

I'll say it again: Since when did ease of use trump security when dealing with money?

Security related decisions will be made by myself and the collective security intelligence. I happily accept all input from people with knowledge of cryptography.

This statement excludes you from that group:

I only used 3 char password.

----

The only reason I suggest simple password rules is protect new users as if they a enter week pass their funds could be stolen if anyone get access to their wallet. I think rules should be set at whatever we deem to be secure enough not to be hacked easily vs annoyance. But the max annoyance for rules would be the standard web ones users are already used to (for example 8 min char, numbers + letters, upper case & lower case). 

This is my exact strategy. Priority 1. Security. Priority 2. Ease of use / memorability

The rules should be as loose as possible yet be sufficiently secure.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #131 on: August 04, 2014, 10:21:54 am »

I don’t think we should ever get rid of wallet password requirements completely, as new users might use password ‘123’ and when they transfer their wallet through gmail/drop box (as they will do) it would be very easy to be hacked.

We should get users some credit. They surely know" 123" is not good password, especially if there is money involved. A six character password (even without username) takes 9 years to crack with 10 ms delay, so it's not as if everyone who left a wallet file in dropbox is going to get hacked automatically.  It's still encrypted by default.

Forcing users to type 16 characters is way too high. You can'r even hack Nxt accounts with 16 character passwords.

Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #132 on: August 04, 2014, 10:25:40 am »

I agree 16 is too high, 3 is far too low.

I think maybe something like 8 or 10, at least. Many many websites require 8 characters.

This is your money.

Don't you realize that every single hacked account from a 'normal user' hurts nxt greatly in the long run?

The user should have to go out of their way to make it insecure. That's the best system.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #133 on: August 04, 2014, 10:40:14 am »

This is my exact strategy. Priority 1. Security. Priority 2. Ease of use / memorability

On hundredth time again:  the point of wallet file  to allow users to type smaller passwords instead of typing 12 random words, or 20+ char that are required  for Nxt secret phrase.

The "mnemonic"  that users have to memorize is out, as far as I am concerned.

Lets compromise; how about something like this? Must have at least one cap, one small letter, and one number, must be 8  characters (no special char requirement) ? That can't be brute forced with 10 ms delay

62^8 / 2 / 100 / 3600 / 24 / 365 = 34617 years.

« Last Edit: August 04, 2014, 10:42:54 am by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #134 on: August 04, 2014, 10:47:29 am »

16 chars was only based on prior discussion about pbkdf2 security.
If 6/8 chars was deemed to be secure enough (I cannot answer this) yes we should go with that as the minimum.

So username would be completely optional, and password a compulsory 8 char.

This is exactly the type of compromise we should be reaching weighing up security vs ease of use.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #135 on: August 04, 2014, 10:52:24 am »

16 chars was only based on prior discussion about pbkdf2 security.
If 6/8 chars was deemed to be secure enough (I cannot answer this) yes we should go with that as the minimum.

So username would be completely optional, and password a compulsory 8 char.

This is exactly the type of compromise we should be reaching weighing up security vs ease of use.

There's a good chance this could be sufficient. I'll let you know when I post my full proposal. (Even though it is technically out of the scope of my work and is part of Wesley's interface)
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #136 on: August 04, 2014, 10:55:13 am »

So username would be completely optional, and password a compulsory 8 char.

No, the username should not be optional. It can be anything thing though, even just 1 char. The username should be case insensitive, i.e Bob == bob 
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #137 on: August 04, 2014, 11:20:14 am »

So username would be completely optional, and password a compulsory 8 char.

No, the username should not be optional. It can be anything thing though, even just 1 char. The username should be case insensitive, i.e Bob == bob 

Not disagreeing but what is the reason for needing a non-blank username? I might have missed this in a prior post.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #138 on: August 04, 2014, 02:21:50 pm »

So username would be completely optional, and password a compulsory 8 char.

No, the username should not be optional. It can be anything thing though, even just 1 char. The username should be case insensitive, i.e Bob == bob 

Not disagreeing but what is the reason for needing a non-blank username? I might have missed this in a prior post.

It's not standard/weird to allow blank username. Usernames are easy to remember can strengthens the password. If anything we should drop the requirement to six char (if we even need the requirement). It's up to Wesley though.

 
« Last Edit: August 04, 2014, 02:25:57 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #139 on: August 04, 2014, 02:37:39 pm »

It's not standard/weird to allow blank username. Usernames are easy to remember can strengthens the password. If anything we should drop the requirement to six char (if we even need the requirement). It's up to Wesley though.

If I can strengthen the security enough 6 might work, 8 will work almost certainly.
If Wesley goes based on the math.

EDIT: It's a tradeoff. By using a lower password requirement we either sacrifice security or need to increase the difficulty to compensate, increasing the time it takes to open the wallet.
« Last Edit: August 04, 2014, 03:18:04 pm by HumanFractal »
Logged

CryptKeeper

  • Hero Member
  • *****
  • Karma: +78/-5
  • Offline Offline
  • Posts: 1235
    • View Profile
Re: Wallet.dat file
« Reply #140 on: August 04, 2014, 03:39:11 pm »



A completely different idea:

Let the user choose an arbitrary file for the pass phrase salt, like a family jpg or something like that. Would be very easy to implement in the client, needs a file open dialog from the browser and a function to create a hash from the file content to use as salt. I think this is a option in truecrypt and keepass, it's something you know + something you have.

That's fine if it's optional. It's pretty good for all the paranoids by the way who keep asking for 2FA. Just tell them to keep the jpeg in USB drive and not the hard drive :)
That is a good idea but is more focused towards advanced users, what we need now is basic wallet.nxt support so new average joes can use our software and be secure.

Advanced users already have the current brain wallet. Although this could an idea for future improvements to the login method.

I agree, but you will notice there are are a lot paranoid posters here who demand 2FA. It's not really 2FA (as jpeg is static) but it still will make some people "happier" if they don't store the keyfile on the hard drive.

Yes, we need simple wallet functionality (preferably identical to Electrum that only needs a seed to recreate the wallet in case file is deleted).

Agreed, ideally I might want to use jpeg method. But I think the focus now should be on something simple for new users.

Wouldn't the Nxt secret phrase be entered at the login giving the user the ability to create a new wallet.nxt? Virtually same as electrum.

It just came to my mind that even online wallets (like mynxt.info) could implement the arbitrary file approach. AFAIK all browsers on mobile phones and tablets allow to upload pictures as well, so this could be a security measure with a good scalability. Although the file should be hashed locally in javascript to avoid sending it out to the wallet server. Is this possible?
Logged
Follow me on twitter for the latest news on bitcoin and altcoins!
Vanity Accounts Sale :-)

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #141 on: August 04, 2014, 03:42:51 pm »

It just came to my mind that even online wallets (like mynxt.info) could implement the arbitrary file approach. AFAIK all browsers on mobile phones and tablets allow to upload pictures as well, so this could be a security measure with a good scalability. Although the file should be hashed locally in javascript to avoid sending it out to the wallet server. Is this possible?

To answer your question, yes, I believe so.

It is an interesting idea - nice job thinking outside of the box, I'll definitely keep that in mind. But as far as a system like this being viable for NXT I am not sure. Maybe.
Logged

colin012

  • Hero Member
  • *****
  • Karma: +65/-18
  • Offline Offline
  • Posts: 851
  • NXTOrganization Marketing
    • View Profile
Re: Wallet.dat file
« Reply #142 on: August 04, 2014, 04:34:56 pm »

Just to make it clear, whatever the Tech committee decides is the best course of action, I will add a 40 SentinelC Bounty to its development.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

Jack Needles

  • Full Member
  • ***
  • Karma: +25/-2
  • Offline Offline
  • Posts: 149
    • View Profile
Re: Wallet.dat file
« Reply #143 on: August 04, 2014, 05:07:17 pm »

It's great to see the lively discussion here.  If I may offer my input on the NXT platform in general.

One of the big advantages of NXT is the split client/server model.  A lightweight NXT client should be able to run on a multitude of devices, and the server can (and should) be made trustless.  A wallet file that is not easily transferrable between clients can be counterproductive -- implementation should be ubiquitous.  I have no answers for details, just the point to be made.
Logged

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #144 on: August 04, 2014, 05:40:57 pm »

I personally don't see any problem with a min 8 character password, as that is pretty standard across the web and work logins to have a min of 8 letter lower and uppercase and numbers included. So I don't think this would annoy many people.

Anything above a min 8 character password is not reasonable to ask of the user.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #145 on: August 04, 2014, 05:51:30 pm »

I personally don't see any problem with a min 8 character password, as that is pretty standard across the web and work logins to have a min of 8 letter lower and uppercase and numbers included. So I don't think this would annoy many people.

Anything above a min 8 character password is not reasonable to ask of the user.

I agree.
Logged

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #146 on: August 04, 2014, 06:23:17 pm »

It's great to see the lively discussion here.  If I may offer my input on the NXT platform in general.

One of the big advantages of NXT is the split client/server model.  A lightweight NXT client should be able to run on a multitude of devices, and the server can (and should) be made trustless.  A wallet file that is not easily transferrable between clients can be counterproductive -- implementation should be ubiquitous.  I have no answers for details, just the point to be made.
I agree the wallet should be portable.

I can't stand wallets that save your wallet.dat in user appdata only. An average user should never have to follow a guide on the Internet to locate their wallet hidden in appdata. There should definitely be option to save to where ever the user wants maybe with USB being a recommended option.

Because this is the official client whatever is chosen will be what all other clients will have to follow suit. But what ever is selected users will always have secret phrase that can be used any where without needing your wallet.nxt on you.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #147 on: August 04, 2014, 09:24:07 pm »



A completely different idea:

Let the user choose an arbitrary file for the pass phrase salt, like a family jpg or something like that. Would be very easy to implement in the client, needs a file open dialog from the browser and a function to create a hash from the file content to use as salt. I think this is a option in truecrypt and keepass, it's something you know + something you have.

That's fine if it's optional. It's pretty good for all the paranoids by the way who keep asking for 2FA. Just tell them to keep the jpeg in USB drive and not the hard drive :)
That is a good idea but is more focused towards advanced users, what we need now is basic wallet.nxt support so new average joes can use our software and be secure.

Advanced users already have the current brain wallet. Although this could an idea for future improvements to the login method.

I agree, but you will notice there are are a lot paranoid posters here who demand 2FA. It's not really 2FA (as jpeg is static) but it still will make some people "happier" if they don't store the keyfile on the hard drive.

Yes, we need simple wallet functionality (preferably identical to Electrum that only needs a seed to recreate the wallet in case file is deleted).

Agreed, ideally I might want to use jpeg method. But I think the focus now should be on something simple for new users.

Wouldn't the Nxt secret phrase be entered at the login giving the user the ability to create a new wallet.nxt? Virtually same as electrum.

It just came to my mind that even online wallets (like mynxt.info) could implement the arbitrary file approach. AFAIK all browsers on mobile phones and tablets allow to upload pictures as well, so this could be a security measure with a good scalability. Although the file should be hashed locally in javascript to avoid sending it out to the wallet server. Is this possible?

If mynxt.info implements it as online wallet, they can of course change the code and implement whatever passwords length rules they want. Anyone can put anything as online wallet. For example https://trade.secureae.com/ 

The point is no software forces you to pick specific passwords for things you are storing on your own hard drive. The decision is left to user (with a warning at most -- for example truecrypt).

« Last Edit: August 04, 2014, 09:28:36 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #148 on: August 04, 2014, 09:32:29 pm »

One of the big advantages of NXT is the split client/server model.  A lightweight NXT client should be able to run on a multitude of devices, and the server can (and should) be made trustless.  A wallet file that is not easily transferrable between clients can be counterproductive -- implementation should be ubiquitous.  I have no answers for details, just the point to be made.

This can be done with Electrum style wallet where wallet can be restored from a seed. Encryption password (which must be smaller, easier to type, protected by key derivation,) is only used to encrypt the seed.
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #149 on: August 19, 2014, 08:07:20 pm »


We need to get the committee to vote on this.

HumanFractal - How much is your bounty request for this project? Your last post stated 125k-150k, is this correct?
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #150 on: August 19, 2014, 08:54:44 pm »

We need to get the committee to vote on this.

HumanFractal - How much is your bounty request for this project? Your last post stated 125k-150k, is this correct?

This number was sent when the project was in the Core, in Java.

Since then the possibility has come up to implement these features mostly in JavaScript, in which case I can use my existing Local 2FA code and make it work for NXT wallet(s).

If we can go this route then the bounty request is instead 110k
This would also give NXT access to Local 2FA features as well as local wallet.dat features.

Here is a Live (Beta) demo of the 2FA technology I have built:

https://dgex.com/wallet/

Please excuse the quality and design of this beta, it's a bit rough around the edges but the underlying technology works.
If I implement it for NXT, the UI would be seamless with the current wallet style.

And before some of you mention it - Some of the cryptographic methods used there will be changing soon for better security.

Full technical whitepaper is included in the source code of two-factor.js

Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #151 on: August 19, 2014, 09:00:12 pm »

https://dgex.com/wallet/

There is a problem with that wallet. It won't let you delete your wallet and create a new one without clearing browser cache. Second problem, you can only create one wallet. That would make it unusable if two people use the same machine.

That's why wallet needs to be based on username and password system.

Overall I like the wallet, but Nxt users (unlike Bitcoin) don't need so many account IDs. The default should have 5 to 10 limit 
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #152 on: August 19, 2014, 09:22:36 pm »

I am aware that the wallet is not perfect, incomplete. I know these features are lacking - I did not have time to add them.

It's still in Beta, we'll be releasing a new version soon.
« Last Edit: August 24, 2014, 09:45:02 am by HumanFractal »
Logged

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #153 on: August 19, 2014, 09:37:28 pm »

We need to get the committee to vote on this.

HumanFractal - How much is your bounty request for this project? Your last post stated 125k-150k, is this correct?

This number was sent when the project was in the Core, in Java.

Since then the possibility has come up to implement these features mostly in JavaScript, in which case I can use my existing Local 2FA code and make it work for NXT wallet(s).

If we can go this route then the bounty request is instead 110k
This would also give NXT access to Local 2FA features as well as local wallet.dat features.

Here is a Live (Beta) demo of the 2FA technology I have built:

https://dgex.com/wallet/

Please excuse the quality and design of this beta, it's a bit rough around the edges but the underlying technology works.
If I implement it for NXT, the UI would be seamless with the current wallet style.

And before some of you mention it - Some of the cryptographic methods used there will be changing soon for better security.

Full technical whitepaper is included in the source code of two-factor.js

I tried the online wallet, it looks very clever! The online creation of the wallet confused me a bit, not knowing what part would be implemented into Nxt. Just the local 2FA part?

In the Nxt implementation I assume the creation of a local wallet.nxt can be saved anywhere on the users PC e.g. USB?
The local wallet.nxt can be encrypted by faux username+password?
wallet.nxt then optionally further secured by local 2FA?

Thanks
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #154 on: August 19, 2014, 09:45:44 pm »

I tried the online wallet, it looks very clever! The online creation of the wallet confused me a bit, not knowing what part would be implemented into Nxt. Just the local 2FA part?

In the Nxt implementation I assume the creation of a local wallet.nxt can be saved anywhere on the users PC e.g. USB?
The local wallet.nxt can be encrypted by faux username+password?
wallet.nxt then optionally further secured by local 2FA?

Thanks

Thanks  :)

The wallet storage technology behind it would be used (changed however necessary), but the interface will most likely be entirely different.

This will depend on what final decisions are made as far as how the login system will work.

Right now it's looking likely that the encrypted wallet data will be stored in the NXT DB, not in a file, but can be exported and imported at any time.

The wallet features themselves will be optional, and on top of that the 2nd factor will also be optional.
Logged

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #155 on: August 19, 2014, 09:59:02 pm »

How does the exporting and importing work?
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #156 on: August 19, 2014, 10:15:05 pm »

How does the exporting and importing work?

Due to the nature of the 2FA, the export data can only be encrypted using the 1st factor password.

It will most likely be in the form of a file export / import.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Wallet.dat file
« Reply #157 on: August 19, 2014, 10:59:05 pm »

I am aware that the wallet is not perfect, incomplete. I know these features are lacking - I did not have time to add them.

It's a Beta, the ball is in Graviton's court to pay me for what is already done and to continue development for this implementation.

At least let the user create a new wallet without clearing browser cache manually. That's basic usability issue
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #158 on: August 19, 2014, 11:42:29 pm »

At least let the user create a new wallet without clearing browser cache manually. That's basic usability issue

We'll be releasing a new version soon with this fixed, along with some other additions.
« Last Edit: August 24, 2014, 10:41:37 am by HumanFractal »
Logged

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #159 on: August 20, 2014, 07:29:57 am »

How does the exporting and importing work?

Due to the nature of the 2FA, the export data can only be encrypted using the 1st factor password.

It will most likely be in the form of a file export / import.
So the wallet lives in the database.

With this method would you be able to login using username and password only? As with DGEX it seemed to require login with hex (probably me getting confused)

For making a backup of the wallet you export the wallet to a wallet.nxt container? And for logining on to another machine I would import my wallet.nxt to a new db.

What is the security implications of the wallet being stored in the database? Can I remove the wallet from database after use?
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #160 on: August 20, 2014, 10:12:34 am »

So the wallet lives in the database.

With this method would you be able to login using username and password only? As with DGEX it seemed to require login with hex (probably me getting confused)

Yes, database is looking like the way it will be done.

The DGEX wallet logs in with just a password and only allows 1 wallet at a time, currently.

For NXT, it's looking like most people want Username / Password which will also allow multiple accounts.



For making a backup of the wallet you export the wallet to a wallet.nxt container? And for logining on to another machine I would import my wallet.nxt to a new db.

What is the security implications of the wallet being stored in the database? Can I remove the wallet from database after use?

Yes.

There are security implications that strongly rely on the security of the first and second factors.
I'd like to see what others think about whether or not there should be an easily-accessible "remove account" feature.

Logged

k_day

  • Full Member
  • ***
  • Karma: +12/-0
  • Offline Offline
  • Posts: 149
    • View Profile
Re: Wallet.dat file
« Reply #161 on: August 20, 2014, 03:58:27 pm »

HumanFractal we've chatted a bit off forum, but can you talk a little bit about how you envision wallet creation/import/export will work for thin clients hitting the json api, like most mobile apps will be doing? It is imperative that we get this right and design with mobile in mind.
Logged
NXT --> NXT-BY7Y-UB4X-6Z3C-8PP3V

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #162 on: August 20, 2014, 04:28:46 pm »

So the wallet lives in the database.

With this method would you be able to login using username and password only? As with DGEX it seemed to require login with hex (probably me getting confused)

Yes, database is looking like the way it will be done.

The DGEX wallet logs in with just a password and only allows 1 wallet at a time, currently.

For NXT, it's looking like most people want Username / Password which will also allow multiple accounts.



For making a backup of the wallet you export the wallet to a wallet.nxt container? And for logining on to another machine I would import my wallet.nxt to a new db.

What is the security implications of the wallet being stored in the database? Can I remove the wallet from database after use?

Yes.

There are security implications that strongly rely on the security of the first and second factors.
I'd like to see what others think about whether or not there should be an easily-accessible "remove account" feature.



I think a ‘remove account’ feature is a must, as if I logon to somebodies else machine briefly I don’t want them keeping a copy of my wallet.

I think for DGEX the method works very well for an exchange where user technical skill is quite high.  For implementation into Nxt I found the DGEX method a bit overkill in all the password options, and having to print off the QR code. Although I should imagine it would be easy to produce a stripped down version  :)

Eg: Nxter sets username & password, confirms username & password, they are logged in, options for export wallet.nxt in the client somewhere

I assume this wallet method works alongside the current secret phrase method as an alternative login method? So if a user forgets their wallet username & password or losses the wallet.nxt backup, they can still just login using the secret phrase method and create a new wallet with new username+password. In reality I would expect many users to only use the secret phrase as a backup to get into their account.

Good work so far.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #163 on: August 23, 2014, 01:25:36 am »

I think a ‘remove account’ feature is a must, as if I logon to somebodies else machine briefly I don’t want them keeping a copy of my wallet.

I agree. I was planning to make it easy to have multiple accounts, which would eliminate the need to clear accounts unless you really intend to remove the data.

I think for DGEX the method works very well for an exchange where user technical skill is quite high.  For implementation into Nxt I found the DGEX method a bit overkill in all the password options, and having to print off the QR code. Although I should imagine it would be easy to produce a stripped down version  :)

Thanks, I made this password generation UI to be an example of all the methods available. For NXT a custom password will be best possibly with some complexity requirements.

Eg: Nxter sets username & password, confirms username & password, they are logged in, options for export wallet.nxt in the client somewhere

Still not entirely sure the method NXT will use, part of the job will be figuring all these details out, coming up with the deterministic algorthm, etc. I'll need to have some talks with the other devs.


I assume this wallet method works alongside the current secret phrase method as an alternative login method? So if a user forgets their wallet username & password or losses the wallet.nxt backup, they can still just login using the secret phrase method and create a new wallet with new username+password. In reality I would expect many users to only use the secret phrase as a backup to get into their account.

Yes, you're correct, the wallet.dat features will be optional and you can still log on as always using a single secret phrase.

Good work so far.

Thanks ;D

Logged

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #164 on: August 23, 2014, 01:30:02 am »

HumanFractal we've chatted a bit off forum, but can you talk a little bit about how you envision wallet creation/import/export will work for thin clients hitting the json api, like most mobile apps will be doing? It is imperative that we get this right and design with mobile in mind.

I'll know all these details after the project is confirmed and I've drawn up the API.

I don't see any inbuilt problems with the system - mobile should work fine, but you're right it will need to be kept in mind during development.

Feel free to weigh in on this side of things, I'll let you know if this gets approved once I reach that point.
Logged

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #165 on: September 01, 2014, 08:20:50 pm »


HumanFractal we've chatted a bit off forum, but can you talk a little bit about how you envision wallet creation/import/export will work for thin clients hitting the json api, like most mobile apps will be doing? It is imperative that we get this right and design with mobile in mind.

I'll know all these details after the project is confirmed and I've drawn up the API.

I don't see any inbuilt problems with the system - mobile should work fine, but you're right it will need to be kept in mind during development.

Feel free to weigh in on this side of things, I'll let you know if this gets approved once I reach that point.

HumanFractal do you want to post your Nxt account and time scale for estimated completion, think those are the only aspects missing from the draft application template.

Committee members have you started voting on this proposal?
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #166 on: September 02, 2014, 10:53:32 am »

HumanFractal do you want to post your Nxt account and time scale for estimated completion, think those are the only aspects missing from the draft application template.

Committee members have you started voting on this proposal?

The ball is in my court to produce a clear proposal plan for these features. Some discussion has gone on that I haven't been brought in on about how these features will need to work and I'll need to chat with Jean Luc and maybe others so I can fully understand the requirements and produce a clear plan.

I have been quite busy and have not had time to do this.
Logged

LocoMB

  • Hero Member
  • *****
  • Karma: +101/-37
  • Offline Offline
  • Posts: 751
    • View Profile
Re: Wallet.dat file
« Reply #167 on: September 02, 2014, 12:26:35 pm »

HumanFractal do you want to post your Nxt account and time scale for estimated completion, think those are the only aspects missing from the draft application template.

Committee members have you started voting on this proposal?

The ball is in my court to produce a clear proposal plan for these features. Some discussion has gone on that I haven't been brought in on about how these features will need to work and I'll need to chat with Jean Luc and maybe others so I can fully understand the requirements and produce a clear plan.

I have been quite busy and have not had time to do this.

yeah me too. by the way, I have had a serious run-in with the bitcoin accounts feature when i coded the nxtbridge, this is a really sticky topic!
« Last Edit: September 02, 2014, 12:32:19 pm by l8orre »
Logged
TOX
90E54E5B5213290EE616D425CADC473038CFABFA53C913271AA8559D1937DC4AF3A354A9E4E5

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Wallet.dat file
« Reply #168 on: October 03, 2014, 08:00:07 am »


HumanFractal do you want to post your Nxt account and time scale for estimated completion, think those are the only aspects missing from the draft application template.

Committee members have you started voting on this proposal?

The ball is in my court to produce a clear proposal plan for these features. Some discussion has gone on that I haven't been brought in on about how these features will need to work and I'll need to chat with Jean Luc and maybe others so I can fully understand the requirements and produce a clear plan.

I have been quite busy and have not had time to do this.

HumanFractal have you had any spare time to work on this?
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

HumanFractal

  • Full Member
  • ***
  • Karma: +29/-2
  • Offline Offline
  • Posts: 148
  • Programming is 90% logic and 10% Magic.
    • View Profile
Re: Wallet.dat file
« Reply #169 on: October 06, 2014, 09:13:20 pm »

HumanFractal have you had any spare time to work on this?


Unfortunately I'm not able to commit to this project right now as I'm dealing with some personal issues.

I will most likely be taking a step back from the crypto world for a while.

Also, specific requirements need to be decided as to how wallet.dat will need to work.

Perhaps whoever is added to the NXT GUI team can handle this.
https://nxtforum.org/general-discussion/eta-on-v1-3/?all
Logged

Jack Needles

  • Full Member
  • ***
  • Karma: +25/-2
  • Offline Offline
  • Posts: 149
    • View Profile
Re: Wallet.dat file
« Reply #170 on: November 03, 2014, 01:00:16 am »

.
« Last Edit: January 16, 2016, 12:48:28 am by Jack Needles »
Logged

crimi

  • Hero Member
  • *****
  • Karma: +122/-11
  • Offline Offline
  • Posts: 863
    • View Profile
Re: Wallet.dat file
« Reply #171 on: November 05, 2014, 02:10:51 pm »

https://nxtforum.org/keystash/

Would be nice if some of you test it and give feedback.  :-\

Command line is also around the corner.. so you can run it on headless systems (raspberry pi etc).
Logged

anuhka78

  • Newbie
  • *
  • Karma: +0/-0
  • Offline Offline
  • Posts: 1
    • View Profile
Re: Wallet.dat file
« Reply #172 on: October 12, 2016, 12:52:29 pm »

I offer the help, to your forgotten password for BTC Wallet.dat
Also I can give you my script, under a condition not to use him in the illegal purposes.
Donations for my script I ask 1-BTC. A half of the sum at once, a half after your success.
In more detail youtube.com/watch?v=3hbs9Yl6cqE&feature=youtu.be)
Logged
Pages: 1 2 3 ... 9 [All]
 

elective-stereophonic
elective-stereophonic
assembly
assembly