Topic: NXT :: descendant of Bitcoin - Updated Information - page 1374. (Read 2761645 times)
The strippers better kick azz in Miami Beach.... still in Chi airport for 90 more min. The material Nikel has is super solid... he's more prepared than I've been at previous conferences.
Quote
But he has aliases
Yes I have 13 of them
how long was your pass phrase?
11
Thats definitely not long enough. Should aim for at least 30 chars.
Great, there goes my NXT experience. Hope you all do well. I have myself to blame.
I have a 10 character password that has 100 Nxt in it, just letters and a # and it still hasn't been hacked. I think there is something going on here. Perhaps the same password used for something else?
My guess, they are wating for you to put a bit more nxt in there before they reveal that the acount is comprimised by draining
You have a little bit than 24h to upgrade to 0.5.10 or you will be left on a fork (http://info.nxtcrypto.org/client-update-0-5-10/).
I don't see many 0.5.10 online peers.
Just a reminder...
I don't see many 0.5.10 online peers.
Just a reminder...
Hardware wallets like the trezor are a big factor.
Ultimately your home-pc can always be compromised.
Would be awesome if we could get such a thing going for Nxt in the future
Ultimately your home-pc can always be compromised.
Would be awesome if we could get such a thing going for Nxt in the future
I create an new video about the Nxt with my friends.
http://i.youku.com/nextcoin
And I will continue to produce more videos about the other features or instructions of Nxt in order to promote Nxt forward.
http://i.youku.com/nextcoin
And I will continue to produce more videos about the other features or instructions of Nxt in order to promote Nxt forward.
Well done.
I have a 10 character password that has 100 Nxt in it, just letters and a # and it still hasn't been hacked. I think there is something going on here. Perhaps the same password used for something else?
Maybe because of that?
It seems like a good idea to me, maybe just set a default time between log-in attempts of 10-30 seconds. That will at least slow directed BF attacks down considerably. However, there is nothing to stop the attacker attacking multiple accounts simultaneously, switching between targets as it gets locked out.
This won't help. They do not brute-force it like this.
What matters is the amount of entropy in the passphrase.
It's even in principle possible to make a system where single word passwords like 'apple12' are safe, but key generation would be way too long.
That makes sense, I'm still locked into thinking about how an attack on a PC or client software works, rather than how attacks against the blockchains password database are implemented.
So the PBKDF2 function produces a derived key, using multiple (1000+) hashes of the original passphrase (+ optional salt phrase) which has the effect of massively ramping up the computing power needed to reverse engineer the hash and thus the password/phrase.
Am I getting closer here?
Quote
But he has aliases
Yes I have 13 of them
how long was your pass phrase?
11
Thats definitely not long enough. Should aim for at least 30 chars.
Great, there goes my NXT experience. Hope you all do well. I have myself to blame.
I have a 10 character password that has 100 Nxt in it, just letters and a # and it still hasn't been hacked. I think there is something going on here. Perhaps the same password used for something else?
Password needs are something that even bitcoin doesn't have truly figured out. But it is further ahead than we are.
Bitcoin just gives you your private account number and tells you to never share it. Even if someone doesn't password protect their wallet, their account is safe.
NXT is placing the responsibility of security at a sophisticated level on the hands of users. This will always be an issue and the source of very bad press.
What is the solution for this?
A client that has a "create account" button that generates a random password of either a fixed or random number of chars between 30 and 50 and tells the user this random password is the user's private NXT ID and advises the user to keep it somewhere safe?
This could also be referred to as their NXT private ID and the only thing they need to take away from a machine to another in order to access their account on the NXT network.
Any thoughts?
Bitcoin just gives you your private account number and tells you to never share it. Even if someone doesn't password protect their wallet, their account is safe.
NXT is placing the responsibility of security at a sophisticated level on the hands of users. This will always be an issue and the source of very bad press.
What is the solution for this?
A client that has a "create account" button that generates a random password of either a fixed or random number of chars between 30 and 50 and tells the user this random password is the user's private NXT ID and advises the user to keep it somewhere safe?
This could also be referred to as their NXT private ID and the only thing they need to take away from a machine to another in order to access their account on the NXT network.
Any thoughts?
some day it should be user-friendly - no person can handle a real 30+ random character password. for creating, well that is needed, but please make sure that the user gets a way (probably 2-Factor Securitized) Password for day to day usage
Luckily, this can be done client-side.
For example, SuperNXTWallet has the feature to either:
A) Generate a 30+ char password for the client based off of the username+password they input + random salt (perhaps stored in a wallet.dat file). However, this means that the user will have to use the same client and have the wallet.dat file ready in order to access his account. Or he can request the client to print out his true password (with a lot of warnings) and try to memorize that too.
B) (Advanced) Let the user define his own brainwallet password of 30+ chars. This should come with a lot of warnings, but this will allow the user, like right now, to use his wallet anywhere in the world and on any device that is a node.
And RS code will be implemented on top of this, providing protection of sending NXT to wrong accounts.
This really makes me sad
Hope the guys don't feel too bad and had a good day at the conference.
What happened?
Do they still get to speak?I hope they still got to spread the word about Nxt, and that was definitely not the last opportunity to attend a conference
Please read what PBKDF2 is.
It's even in principle possible to make a system where single word passwords like 'apple12' are safe, but key generation would be way too long.
It's even in principle possible to make a system where single word passwords like 'apple12' are safe, but key generation would be way too long.
I know what PBKDF2 is, I was replying to EvilDave, not to you.
i really think the solution is obvious. an optional user specified secondary password. or a manual salt. this would be a password that you could be sloppy with. upload it in plaintext to google drive for example. Store a second copy in plain text in a text file on your desktop. hell you could even post it here in this thread. even if every nxt user publicly broad-casted his second password, it would expand the total keyspace that brute forcers would need to search 15,000 times making brute forcing 1/15000th as profitable and it would be orders of magnitude more effective than that if they were sloppy with them but didn't actually post it publicly.
This could just be a modification to the client where it would display a second field under password that would be grayed out unless you checked a box saying that you wanted to use a secondary password. then the client could simply tack it on to the end of the first password behind the scenes. it really would be an almost totally superficial change to NRS that would cut the profitability of rainbow tables down to a fraction of what it is now.
This could just be a modification to the client where it would display a second field under password that would be grayed out unless you checked a box saying that you wanted to use a secondary password. then the client could simply tack it on to the end of the first password behind the scenes. it really would be an almost totally superficial change to NRS that would cut the profitability of rainbow tables down to a fraction of what it is now.
Is it possible to see a list of blocks your account has solved, the time it was created, and the nxt paid for that block?
yes. You want this? 
This really makes me sad
Hope the guys don't feel too bad and had a good day at the conference.
It seems like a good idea to me, maybe just set a default time between log-in attempts of 10-30 seconds. That will at least slow directed BF attacks down considerably. However, there is nothing to stop the attacker attacking multiple accounts simultaneously, switching between targets as it gets locked out.
This won't help. They do not brute-force it like this.
What matters is the amount of entropy in the passphrase.
It's even in principle possible to make a system where single word passwords like 'apple12' are safe, but key generation would be way too long.
It seems like a good idea to me, maybe just set a default time between log-in attempts of 10-30 seconds. That will at least slow directed BF attacks down considerably. However, there is nothing to stop the attacker attacking multiple accounts simultaneously, switching between targets as it gets locked out.
This won't help. They do not brute-force it like this.
What matters is the amount of entropy in the passphrase.
It's easy to defeat bruteforce.
Instead of using the password for account, use the password as an input for PBKDF2 with number of iterations inversely related to password's length.
The relation: one second for safe passwords, longer for unsafe, let's say it's 15 second for something like "apple".
This makes bruteforcing much harder even for short passwords.
It's possible to add a second simple field, even an user's real name, and use it as a salt. The combination would make bruteforcing almost impossible.
For compatibility with other accounts, it's enough to add a checkbox 'use older password system'.
I can implement this in JS. Jitted JS in new browsers is fast enough. I asked Jean-Luc if he would include this if I did (no point writing only for myself - I have a secure password) but he wasn't interested.
https://forums.nxtcrypto.org/viewtopic.php?f=17&t=557
Forgive me for not being all that technically brilliant.Instead of using the password for account, use the password as an input for PBKDF2 with number of iterations inversely related to password's length.
The relation: one second for safe passwords, longer for unsafe, let's say it's 15 second for something like "apple".
This makes bruteforcing much harder even for short passwords.
It's possible to add a second simple field, even an user's real name, and use it as a salt. The combination would make bruteforcing almost impossible.
For compatibility with other accounts, it's enough to add a checkbox 'use older password system'.
I can implement this in JS. Jitted JS in new browsers is fast enough. I asked Jean-Luc if he would include this if I did (no point writing only for myself - I have a secure password) but he wasn't interested.
https://forums.nxtcrypto.org/viewtopic.php?f=17&t=557
My understanding of what this idea translates to is a timeout in between each password log-in attempt, with the timeout period increasing for simpler passwords. Have I got the idea?
It seems like a good idea to me, maybe just set a default time between log-in attempts of 10-30 seconds. That will at least slow directed BF attacks down considerably. However, there is nothing to stop the attacker attacking multiple accounts simultaeneously, switching between targets as it gets locked out.
Someone, whose name I shall not mention, did float the idea of creating a hashcat(?)-based tool to carry out an automated bruteforce attack on the entire NXT blockchain, ie all accounts. Maybe this has been implemented.......we need to keep a very good watch out for hacking reports, and take them seriously.
This is exactly what I was asking myself - doesn't it take "seconds" to input password then login -> How is it then possible to brutforce with tons of passwords?
When the price drops 0,00005 btc?
It's easy to defeat bruteforce.
Instead of using the password for account, use the password as an input for PBKDF2 with number of iterations inversely related to password's length.
The relation: one second for safe passwords, longer for unsafe, let's say it's 15 second for something like "apple".
This makes bruteforcing much harder even for short passwords.
It's possible to add a second simple field, even an user's real name, and use it as a salt. The combination would make bruteforcing almost impossible.
For compatibility with other accounts, it's enough to add a checkbox 'use older password system'.
I can implement this in JS. Jitted JS in new browsers is fast enough. I asked Jean-Luc if he would include this if I did (no point writing only for myself - I have a secure password) but he wasn't interested.
https://forums.nxtcrypto.org/viewtopic.php?f=17&t=557
Forgive me for not being all that technically brilliant.Instead of using the password for account, use the password as an input for PBKDF2 with number of iterations inversely related to password's length.
The relation: one second for safe passwords, longer for unsafe, let's say it's 15 second for something like "apple".
This makes bruteforcing much harder even for short passwords.
It's possible to add a second simple field, even an user's real name, and use it as a salt. The combination would make bruteforcing almost impossible.
For compatibility with other accounts, it's enough to add a checkbox 'use older password system'.
I can implement this in JS. Jitted JS in new browsers is fast enough. I asked Jean-Luc if he would include this if I did (no point writing only for myself - I have a secure password) but he wasn't interested.
https://forums.nxtcrypto.org/viewtopic.php?f=17&t=557
My understanding of what this idea translates to is a timeout in between each password log-in attempt, with the timeout period increasing for simpler passwords. Have I got the idea?
It seems like a good idea to me, maybe just set a default time between log-in attempts of 10-30 seconds. That will at least slow directed BF attacks down considerably. However, there is nothing to stop the attacker attacking multiple accounts simultaeneously, switching between targets as it gets locked out.
Someone, whose name I shall not mention, did float the idea of creating a hashcat(?)-based tool to carry out an automated bruteforce attack on the entire NXT blockchain, ie all accounts. Maybe this has been implemented.......we need to keep a very good watch out for hacking reports, and take them seriously.
Jump to: