|
opticalcarrier
|
 |
March 10, 2014, 03:11:52 PM |
|
I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)
what will happen if the user has already sent a fund to this less-than-15-chars-passphrase account but the fund has not been conformed and shown up in the balance yet? Should not allow to create a less than 35 chars pass phrase in the first place. I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)
The first transaction of an account is always an incoming transaction and the secret for the recipient account is not needed for this first transaction. Thus, everytime NRS or a client would need a secret for an account and be able to reject it, it already does have at least one transaction. you 2 bring basically the same argument. We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out. I say the new clients should implement the restrictions I listed NOW. Then if the case you bring where the user creates an low-entropy passphrase then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions. Eventually the new clients will go widestream and security will improve. |
|
|
|
|
|
|
|
It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
Eadeqa
|
|
March 10, 2014, 03:12:27 PM |
|
Wesleyh, Good work on the nxtra.org client. I would like to be able to use my yubikey with a random static password that I append to a phrase. If the random number generator is required that may not be possible. Thoughts? I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)
Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded) Start page:  Can we get only "Login" and "Register" links here without the field to enter any random password as first option? I have no idea how a yubikey works, sorry. Huh? I never mentioned yubikey. I think that's for 2-factor authentication. It won't even work with Nxt as Nxt is local login to NRS. |
|
|
|
|
bitcoinpaul
|
|
March 10, 2014, 03:12:47 PM |
|
I have a question about this.
If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?
Yes, and now calculate the combinations and come back with the number  |
|
|
|
|
|
bitcoinpaul
|
|
March 10, 2014, 03:15:37 PM |
|
you 2 bring basically the same argument. We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out. I say the new clients should implement the restrictions I listed NOW. Then if the case you bring where the user creates an low-entropy passphrase then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions.
Eventually the new clients will go widestream and security will improve.
Guys, KISS (not literally). And don't force people. Make a big hint and if they still want to choose a short passphrase, then let it be. |
|
|
|
|
|
BrianNowhere
|
|
March 10, 2014, 03:24:38 PM |
|
I have a question about this.
If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?
Yes, and now calculate the combinations and come back with the number I have not the math skills to do even this. 1600 * 10 = 16,000 ok, I'm lost. I was just wondering if the security level is the same if you change the brute force method in this way or if it decreases at all. |
NXT: 4957831430947123625
|
|
|
|
bitcoinpaul
|
|
March 10, 2014, 03:24:46 PM |
|
Any suggestions about Parallel Chains? If not then I'll stick to BCNext's draft.
What is his draft exactly? Some of his suggestions wouldn't make sense now. |
|
|
|
|
ChuckOne
Sr. Member
 Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
March 10, 2014, 03:25:02 PM |
|
In the end, it would be an inconvenience for large stakeholders but for nothing.
TF is going ahead the way it was planned regardless so why not take these pointless discussions to a new topic? He requested information and I tried to give it to him. |
|
|
|
|
|
Meizirkki
|
|
March 10, 2014, 03:26:22 PM |
|
I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.
|
|
|
|
|
|
bitcoinpaul
|
|
March 10, 2014, 03:27:26 PM |
|
I have a question about this.
If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?
Yes, and now calculate the combinations and come back with the number I have not the math skills to do even this. 1600 * 10 = 160,000 ok, I'm lost. I was just wondering if the security level is the same if you change the brute force method in this way or if it decreases at all. We make it simple. Imagine each word is a character, as you suggested. But now, for every of the 12 characters we type, we can choose out of 1626 characters. First character (word): 1626 possibilities Second character (word): 1626 possibilities .... Now calculate. You can do it. Math is cool. |
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
March 10, 2014, 03:27:49 PM |
|
Any suggestions about Parallel Chains? If not then I'll stick to BCNext's draft.
Suggestion: - SCIP mechanism to count blocks in order to have snapshot every 1440 blocks Question: Will snapshots integrated for free? |
|
|
|
|
|
Eadeqa
|
|
March 10, 2014, 03:28:13 PM |
|
I have a question about this.
If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?
Yes, and now calculate the combinations and come back with the number Since it's open source, everyone knows the dictionary https://raw.github.com/spesmilo/electrum/master/lib/mnemonic.pyThe security shouldn't be based on "secrecy" . It's secure as 12 words from 1626 word choices is equal to 2^128 possible combination. |
|
|
|
|
bidji29
|
|
March 10, 2014, 03:29:03 PM |
|
I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.
But its really less confusing for newbie than Brainwallet / current wesley implementation |
|
|
|
|
bitcoinpaul
|
|
March 10, 2014, 03:30:05 PM |
|
I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.
But its really less confusing for newbie than Brainwallet / current wesley implementation No. |
|
|
|
|
|
wesleyh
|
|
March 10, 2014, 03:33:00 PM |
|
This good enough for a start page? Shown ONLY ONCE to the user (until the user has logged in), afterwards it's back to the secret phrase input box being shown by default.  |
|
|
|
|
|
Eadeqa
|
|
March 10, 2014, 03:33:37 PM |
|
I have a question about this.
If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?
Yes, and now calculate the combinations and come back with the number I have not the math skills to do even this. 1600 * 10 = 16,000 It's 12 words (not 10), so it's 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 * 1626 |
|
|
|
|
opticalcarrier
|
|
March 10, 2014, 03:33:44 PM |
|
you 2 bring basically the same argument. We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out. I say the new clients should implement the restrictions I listed NOW. Then if the case you bring where the user creates an low-entropy passphrase then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions.
Eventually the new clients will go widestream and security will improve.
Guys, KISS (not literally). And don't force people. Make a big hint and if they still want to choose a short passphrase, then let it be. I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.
you 2 do realize, that right now with no nxtwallet.dat file, AND a "big hint" the we currently have in all NRS clients that there are still people (yes morons, but what can we do) that are losing their NXT?" how is a .dat file confusing? the brainwallet function needs to be non-default; I consider it an advanced feature. No one can sanely argue this fact, given the big hints we give out but with idiots still ignoring the warnings. |
|
|
|
|
Damelon
Legendary
Offline
Activity: 1092
Merit: 1010
|
|
March 10, 2014, 03:34:21 PM |
|
I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)
Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded) Thoughts? Thoughts: Implement this ASAP, and sort out the wallet.dat discussion later. Do not get sidetracked into that discussion and then wait  It may not be *perfect* but it's WAY better than what we have. |
|
|
|
|
Eadeqa
|
|
March 10, 2014, 03:35:29 PM |
|
This good enough for a start page? Shown ONLY ONCE to the user, afterwards it's back to the secret phrase input box being shown by default. I think that's perfect. Lets integrate this with next NRS release as default client. |
|
|
|
|
opticalcarrier
|
|
March 10, 2014, 03:36:27 PM |
|
I vote for no wallet.dat as the default option. It's one of the things most confusing to bitcoin newbies.
But its really less confusing for newbie than Brainwallet / current wesley implementation No. you cant just come in here and say no and leave it at that. read my argument and refute it. that is if you want reasonable discourse, otherwise you get ignored. seriously tell us why "no". |
|
|
|
|
|
opticalcarrier
|
|
March 10, 2014, 03:37:21 PM |
|
I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)
Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded) Thoughts? Thoughts: Implement this ASAP, and sort out the wallet.dat discussion later. Do not get sidetracked into that discussion and then wait It may not be *perfect* but it's WAY better than what we have. I agree, keep main track as is while we discuss the nxtwallet.dat default method. |
|
|
|
|
|
