Well, I was checking NXT wiki, and it have a really neat problem solver for not having to transmit passwords over the wire.
By using a public key, that is generated in the client side using your passphrase, everytime you submit a request using the public key instead of the passphrase, the server returns a raw hex encoded data so that the client, without ever sending anything to the server, then you can sign the payload using your privatekey (in this case, the curve from the passphrase) then send it back for broadcasting.
I was thinking how NEM could have something like this. This would make a "browser indexed db only" wallet feasible.
In NEM passwords won't have to be passed over the wire anyway since it uses local wallets.
I also see no reason why the password would have to be sent over the wire in NXT as the whole blockchain is available locally and your keys are generated from your passphrase.
Maybe I'm missing something though.
If you want to move your wallet to a portable browser for example, that's when you'd need your password. Creating a minimal (no blockchain download or anything, even without downloading NIS / NCC) wallet that gets stored on localStorage for example
check https://trade.secureae.com/ for example, you can provide your password (if you pick "Nxt Client Login" on the sign in modal), but it's never sent to the server, but you can still access your wallet without needing to download the whole blockchain from NXT
basically it means it recreates your private key on-the-fly on the browser, and can do stuff with it without ever downloading a wallet software (NRS in this case). How could this become true to NEM? Makes integrating with online solutions really a breeze.
If you want to move your wallet to a portable browser for example, that's when you'd need your password. Creating a minimal (no blockchain download or anything, even without downloading NIS / NCC) wallet that gets stored on localStorage for example
check https://trade.secureae.com/ for example, you can provide your password (if you pick "Nxt Client Login" on the sign in modal), but it's never sent to the server, but you can still access your wallet without needing to download the whole blockchain from NXT
basically it means it recreates your private key on-the-fly on the browser, and can do stuff with it without ever downloading a wallet software (NRS in this case). How could this become true to NEM? Makes integrating with online solutions really a breeze.
Secureae works without downloading the chain because they have it stored on their server and since you do everything on their site you don't need to download anything. It recreates your keys in the browser yes, that's exactly what all nxt clients do since NXT uses a brainwallet where keys are created with your passphrase. NEM doesn't use a brainwallet. The passphrase is used to en/decrypt the wallet file.
I'm sure there would be some way to do this with NEM but it won't be as easy to implement because they keys can't be derived from the passphrase.
Well, I was checking NXT wiki, and it have a really neat problem solver for not having to transmit passwords over the wire.
By using a public key, that is generated in the client side using your passphrase, everytime you submit a request using the public key instead of the passphrase, the server returns a raw hex encoded data so that the client, without ever sending anything to the server, then you can sign the payload using your privatekey (in this case, the curve from the passphrase) then send it back for broadcasting.
I was thinking how NEM could have something like this. This would make a "browser indexed db only" wallet feasible.
Can you share a link to the wiki page?
here http://wiki.nxtcrypto.org/wiki/Nxt_API
If a publicKey parameter is supplied as a hex-encoded byte array, the transaction will be prepared by the server and returned in the JSON response as transactionBytes. This byte array can now be signed by the client, and then sent back to the server for broadcasting using the broadcastTransaction API.
here http://wiki.nxtcrypto.org/wiki/Nxt_APIIf a publicKey parameter is supplied as a hex-encoded byte array, the transaction will be prepared by the server and returned in the JSON response as transactionBytes. This byte array can now be signed by the client, and then sent back to the server for broadcasting using the broadcastTransaction API.
We actually have an API like this in NIS (transaction/prepare), but, in general, it is discouraged from use. Any approach like this requires a trusted server (NRS or NIS) AND https (which secureae apparently doesn't have).
Given the happy path, everything works fine:
1. Client sends JSON request to Server
2. Server converts JSON request to binary payload
3. Server sends binary payload to Client
4. Client signs binary payload
5. Client sends signature back to Server
However, this is prone to attack if there is either (1) a malicious server, or (2) not https.
Attack vector 1: malicious server
1. Client sends JSON request to Server
2. Server decides it would prefer to transfer all of the Client's balance to itself
3. Server sends binary payload (of modified transfer) to Client
4. Client signs away its entire balance :(
Attack vector 2: http
1. Client sends JSON request to Server
1a. Malicious intermediary intercepts request and changes the transfer to credit itself
2. Server converts JSON request to binary payload
3. Server sends binary payload to Client
4. Client signs a transfer to the malicious intermediary :(
If you want to move your wallet to a portable browser for example, that's when you'd need your password. Creating a minimal (no blockchain download or anything, even without downloading NIS / NCC) wallet that gets stored on localStorage for example
check https://trade.secureae.com/ for example, you can provide your password (if you pick "Nxt Client Login" on the sign in modal), but it's never sent to the server, but you can still access your wallet without needing to download the whole blockchain from NXT
basically it means it recreates your private key on-the-fly on the browser, and can do stuff with it without ever downloading a wallet software (NRS in this case). How could this become true to NEM? Makes integrating with online solutions really a breeze.
With NEM, private keys can stay completely local and never have to leave the client's machine. Of course, this is a choice. Private keys can also be hosted in the cloud via a service (ala Coinbase). Of course, this requires trusting the service in exchange for convenience.
But, this is no different than trusting that the secureae folks don't decide to steal your password.
If you want to move your wallet to a portable browser for example, that's when you'd need your password. Creating a minimal (no blockchain download or anything, even without downloading NIS / NCC) wallet that gets stored on localStorage for example
check https://trade.secureae.com/ for example, you can provide your password (if you pick "Nxt Client Login" on the sign in modal), but it's never sent to the server, but you can still access your wallet without needing to download the whole blockchain from NXT
basically it means it recreates your private key on-the-fly on the browser, and can do stuff with it without ever downloading a wallet software (NRS in this case). How could this become true to NEM? Makes integrating with online solutions really a breeze.
With NEM, private keys can stay completely local and never have to leave the client's machine. Of course, this is a choice. Private keys can also be hosted in the cloud via a service (ala Coinbase). Of course, this requires trusting the service in exchange for convenience.
But, this is no different than trusting that the secureae folks don't decide to steal your password.
Everything on secureae is signed locally as far as I know. I read somewhere that they couldn't access passwords even if they wanted to. Supposedly just as safe as running the nrs software yourself. Think they do use https aswell..
@Jaguar0625 everything is done client side, the password in secureae is never transmitted. But I can see the attack surface is big enough to be dangerous. But assuming a fair https website with good intentions, like a merchant selling products, it would be easy enough to implement without having to going to your wallet to transfer funds and "disrupting" the checkout process, like happens with credit cards.
All you'd need is your private key THAT would be stored locally on your browser, and would never be sent anywhere.
Another thing, the binary payload would need to have a checksum to prevent tampering, then the two problems would be gone
But assuming a fair https website with good intentions, like a merchant selling products, it would be easy enough to implement without having to going to your wallet to transfer funds and "disrupting" the checkout process, like happens with credit cards.
All you'd need is your private key THAT would be stored locally on your browser, and would never be sent anywhere.
I agree with that.
Another thing, the binary payload would need to have a checksum to prevent tampering, then the two problems would be gone
If the server generates, the checksum, all the same problems exist.
If the client generates the checksum, all the problems are solved. But, if the client can generate the checksum, it muse be able to generate the payload too. And, if it can generate the payload, it really doesn't need the server to prepare anything :).
If the server generates, the checksum, all the same problems exist.
If the client generates the checksum, all the problems are solved. But, if the client can generate the checksum, it muse be able to generate the payload too. And, if it can generate the payload, it really doesn't need the server to prepare anything :).
And why couldn't it? [url=https://github.com/bitcoinjs/bitcoinjs-lib#creating-a-transaction]Bitcoinjs do something like that, but of course, needs a server connected to the P2P network to broadcast the transaction, but everything is signed client-side. This would make adoption as payment processing really smooth.
If the server generates, the checksum, all the same problems exist.
If the client generates the checksum, all the problems are solved. But, if the client can generate the checksum, it muse be able to generate the payload too. And, if it can generate the payload, it really doesn't need the server to prepare anything :).
And why couldn't it? [url=https://github.com/bitcoinjs/bitcoinjs-lib#creating-a-transaction]Bitcoinjs do something like that, but of course, needs a server connected to the P2P network to broadcast the transaction, but everything is signed client-side. This would make adoption as payment processing really smooth.
It can do it, and that's how I hope NEM JS-based clients will work
Awesome to know 
@pocesar - are you planning to have your client be compatible with the NCC wallet format or are you going to come up with your own wallet format and/or forego wallets altogether?
for the starters, I just want to make the wallet easier to use for non tech savvy people, and I'm using NCC entirely (UI and everything). Just wrapping around a "portable browser" that is node webkit.
my other open source that will be in https://github.com/pocesar/node-nem-api will have the refined, isolated from DOM bits from NCC ui, plus all NIS APIs