CfB

Did you miss my post aboutp the client automatically generating maximum entropy private keys? Do you think jean-luc will generate 1234 as a private key

Why all this resistance. I am not hearing valid objections to my proposed solution. Don't you want the option for people to be able to add second layer of security?

James

I am very good at creative solutions to so called impossible problems. I have extensive software expertise. I am trying to make nxt the most secure crypto at the architectural level. I am not proposing any new cryptographic algorithms, just using standard public private key in a way that has not been done before

Maybe i am totally offbase on this, but until i get a clear explantion about how this is wrong, i am apt to believe it is possible to add second layer of security to nxt

Why do you want me to stop?

James

That is why i specified that once you do this to an acct, it cannot be changed
This is why it needs protocol level support and not just client side
Like an alias belongs to first acct, sendmoney public key cannot be changed once it is set

People who want to secure their acct could set this up before they put big money into it

How could the hacker set sendmoney public key before the acct is fully funded?

James

I am not a cryptographer and at airport without access to src code, so i can only describe in general terms

I want to be able to make an acct required to encrypt all sendmoney calls. By broadcasting public key via alias type mechanism all nodes will be able to decrypt transactions. Since hacker who stumbled onto nxt acct key wont have send money private key, he cant sendmoney even with nxt acct password

What part doesnt make sense?

James

Please confirm that this means that i was right when i said that we could add a second layer of security even though nxt is a distributed system. We achieved the impossible, yes?

James

Jean-luc

Assuming we had the above two api calls, how hard would it be to add a second layer of security to sendmoney in the client?

I am assuming we will get a handy button to generate a max entropy private key to use, both for nxt acct and second layer key

Another feature for down the road that would be cool is a fragmented wallet. If we can automatically generatea one set of keys, why not 10? Then we can compartmentalize oure nxt holdings to eliminate total loss in case one acct is compromised. A higher level view that just shows the combined totals would make it almost transparent that there are many subwallets. All is is for later, just wanted to get the idea out there while we are in a security conscious mode

James

CfB

Will you add the following api calls?
Set sendmoney public key
Encrypted sendmoney

I think it would be easiest to just make it so that if an account ever sets a sendmoney public key all send money transactions for that acct are encrypted and all nodes can decrypt using public key that is put into a special alias of the form (acct number).(public key)

I think this adds meaningful second layer of security without needed emails, sms
It is decentalized, all nodes can decrypt

Most importantly, even with the current hacked client, if these calls were in place, even a weak private key woild have created a large obstacle to the password thief. Using a high entropy key would make it pointless to even bother trying to decrypt unless the account you stumbled onto had millions of nxt

Please confirm or deny if my approach would have prevented any losses from current password thief

By making it a onetime activation it does mean that if you lose the private key, you woild have to spend all the nxt in the acct buying aliases and generally spending it on services, but this i think would be an acceptable tradeoff

James

"Maybe"!!! There is hope, I am glad it wasn't the usual "impossible" response.

Forgive me if I am getting the details wrong as I have not studied the source code yet, but presumably we can guard sending of NXT with an optional authentication step. This would have to be made at the core level as hackers wouldn't be using the secure clients. Each account that wants to enable authentication would need to have an alias that relates <acct#> and <public key>, this way all nodes can do public private key so whichever node forges a block, would have access to all public keys.

There would be many possibilities if we can have a "centralized" processing done by the forging node to implement authentication. One way would be for the transaction details to be signed using a client generated private key independent from the account's passphrase and submitting the blob of bits and account# as the method for sending NXT.

The forging node would process all the encrypted blobs by retrieving the public key alias and decrypting the encrypted blob of bits

Using this approach, only a single change needs to be made to the core, namely support for accepting the  authentication encrypted send NXT commands. Also some client changes, but mostly just generating high entropy private keys. A hacker could stumble upon the passphrase for a NXT account but all he gets then is a chance to crack a public/private key that is unique to each account. Since parallel mining goes out the door and the odds of cracking two independent keys for a single account would make it so nobody would even bother.

I also think we could then make the bold (but true) claim that NXT is the most secure crypto (by far). If something, anything, like this can be done, it would go straight to the top of the requested features list. By far. I know it is probably overkill, but that is what people will want. Overkill amount of security.

Crazy or not so crazy?

James

P.S. For the truly paranoid, they can dynamically change their public key alias (say to match google authenticator) within the client software before submitting sending NXT. After sending, they can change their alias to an invalid key so no sending is possible. Of course this now opens the door for requiring securely updating aliases, but I haven't had my coffee yet and about to go offline.

I think we all agree PaulyC should be made whole as he was the first to report this. Usually bounties are for the first, not sure what the feeling is about newcn's being second. There is value in confirmation, so maybe half credit?

We can't make a policy out of this, but I feel that during this critical time it is important to show the world what the NXT community is.

There are the payment fees that doesn't currently have, nor do I expect will have a team that can make a realistic claim to have added value to that feature. This creates a certain amount of the community fund that would be discretionary. The actual process of collection and disbursement of the community fund has not been completed yet, but as soon as this year gets into full gear I expect that the kinks will be worked out.

Since I seem to be the only one pushing this idea, I guess it is up to me to make discretionary calls, but I want to get people's feedback on the bounty for newcn's confirmation of this hack.

For anybody that wants to directly contribute to the community fund, all donations are welcome. I couldn't get any volunteers to deal with the logistics of all this, so I will coordinate it for now. I will disclose all contributions and disbursements. For now just post your contribution to the community fund and I will confirm receipt or if you want to do it anonymously, PM me your contribution and your contribution will be listed as from anonymous. If you want your contribution to be spread over a period of time, please state the time period.

James

P.S. The more in the community fund, the more people like wesleyh, ferment, nexern, etc. will be rewarded and this in turn will get more and more people improving NXT instead of working OT at their real jobs

rickyjames,

I wasn't saying we should cover it up, I was saying that the feature to broadcast messages to all NXT clients is not there yet.

James

Now that we seem to have figured out this breach, we need to warn anybody that downloaded that version, but I guess we can't broadcast message yet...

Still there will be concerns about the offline parallel attack. I am still waiting for CfB's answers on my architecture question. We don't need an immediate solution as long as there is a clear roadmap to higher security. both perceived and actual.

If the hacker has to search a space 2^256, then even with petahashes it will take a long time. However, I am worried about clustering especially with user selected passwords without maximum entropy. Realistically, if anybody uses alphanumeric passwords of a short length or just combines common words, a hacker running a simple brute force search of these combos will unlock all these accounts pretty quickly. Our opponents will intentionally use reasonable looking but weak passwords to intentionally get hacked and give us black PR.

I want to proactively attack this issue. How does NXT security compare to BTC or to Ripple security? These are critical questions for mass adoption of NXT. I want to hear that NXT is better than all the rest, but what I need is an independent cryptographic expert to analyze this objectively.

Not sure how much this will cost, but it will go a long ways toward eliminating this as an issue if indeed NXT is as secure or more secure than BTC (and Ripple). Does anybody know how much it will cost to get an independent cryptographic analysis?

James

P.S. also maybe a bounty to PaulyC of 7808 NXT for finding this?

didn't the download of the tainted version come from a page made by the accused thief?

James

notsoshifty

OK, change "same software" to "software that uses the same protocol"

My question is still unanswered

James

NXT has a single node each time a block is forged. Why can't all "centralized" actions be done by that lucky node?

With thousands of transactions, it might have to do a lot of work, but if the node that forges the block is responsible for validating all the transactions, then we can have a centralized action in a decentralized system.

I understand it will still require some pretty complicated code to implement, but doesn't this move it from "impossible" to "difficult"?

James

CfB

Architecture question.

All nodes run the same software, each maintaining synchronized copy of blockchain
Your reflex objection to any secondary authentication is that it can only be implemented using some sort of centralized method, defeating the robustness gained from the distributed nature.

I have been thinking about this at a high level this afternoon, so I am sure not all the details are right, but conceptually if we can implement a "centralized" type of action when all the nodes are running the same software and replicating the same dataset, then authentication could be implemented in a distributed context.

Correct or incorrect?

James

offline mining of all NXT accounts in parallel
problem gets worse the more NXT accounts there are
this attracts more hackers the more NXT is worth
This will create an equilibrium effect like a boat anchor to a hot air balloon. The more NXT succeeds, the more it will be hacked.

CfB, tell me there is a solution that is more effective than the user needs to not be unlucky

James

Can someone test potential passwords locally without going out to the network if he has the latest blockchain?

James

CfB

all the nodes would have to cryptographically store all the seeds for all accounts in a way that each node can reconstruct the desired output, without knowing the actual seed. Probably close to impossible, but not actually provably impossible. Maybe even a nice challenge for BCNext?

We don't need to use google authenticator, we just need some system that is distributed that achieves the desired result. That's a pretty open requirement and I doubt you can prove it is impossible. If it is not impossible, then it can be done.

I would like better minds than mine to figure out how to do this. I know mathematically it is probably the same odds of being hacked, but requiring an orthogonal step even after finding an account whose password you stumbled into would make everybody feel much safer.

As it is now a monkey typing random keys on the keyboard can stumble into an acct.

James

P.S. I understand why the current localhost will disappear, it has to so clients can add the new layer of security. Enforcing passwords that are strong enough is a good first step, but longer term please open your mind to the possibility of the "impossible", it will make a huge difference in NXT valuation

CfB

If the client runs all the authentication software, where is the centralization?
Nxt is java running on each node, if that node ran all the authentication software, how is that centralized? Pop3 and smtp are not so much to add into client is it? I cant imagine adding support for google authenticator in the client is impossible. The part i can't figure out is how to have an api that enforces the additional security, at worst all the nodes would have to run google authenticator verification on all transactions. Difficult, but not impossible.

Ok, sms probably not good to have a zillion verification texts senta to your cellphone, but google authenticator has a dynamically changing code for each acct, if there was a authenticator alias for an acct could that be used by all nodes to enable validation before sending of funds?

James

 Hackers cannot easily target specific accts, but they automatically target all accounts at once
It is like parallel mining of btc and nmc at the same time, but it is parallel mining of all nxt accts, so the more nxt accts the higher the probability of getting a hit.

The only defense against this i can see, other than additional security in the client and or core, is to split up your funds into tiny amounts across many accts. of course this just increases the hackers chances that much more, but at least you only lose a small percentage of what you have instead of all

This is a SERIOUS issue and responses like get a stronger password are not responsive. We need an actial solution to this problem, BCNext you are our only hope!

James