mgw

[antanst]

Each specific deposit is handled by one gateway and then swept into multisig, but any of the gateways can be selected for handling the deposit.

For deposits, my design is as vulnerable as a centralized exchange, but this is only for the brief time that a deposit is in transit.

Does it matter for how long? If there's a compromise, user's coins are going bye-bye, because you've placed the trust on a single gateway.

People can mitigate against this by splitting up their deposit into three and sending increments to all three.

Sure, but I thought the point was to make it easy. People can always mitigate against an exchange failure by depositing onto another exchange anyway.

Withdraw
1. user transfers DOGE or milliDOGE asset to the gateway (or DOGE asset issuer)
2. the selected gateway notices the withdraw request and posts an AM with the details

So up to now we have one asset transfer to an account of a gateway, plus a message to the gateway that says "Withdraw" and presumably contains the DOGE withdraw address as well?

And again, if the gateway gets compromised, the attacker can steal the assets? If have understood the whole process, there are three (and only three) gateways, and even if one of them gets compromised, there are time windows where the attacker can both steal the DOGE deposits to this gateway and the NXT assets used for withdrawals.

[jl777]

Each specific deposit is handled by one gateway and then swept into multisig, but any of the gateways can be selected for handling the deposit.

For deposits, my design is as vulnerable as a centralized exchange, but this is only for the brief time that a deposit is in transit.

Does it matter for how long? If there's a compromise, user's coins are going bye-bye, because you've placed the trust on a single gateway.

People can mitigate against this by splitting up their deposit into three and sending increments to all three.

Sure, but I thought the point was to make it easy. People can always mitigate against an exchange failure by depositing onto another exchange anyway.

Withdraw
1. user transfers DOGE or milliDOGE asset to the gateway (or DOGE asset issuer)
2. the selected gateway notices the withdraw request and posts an AM with the details

So up to now we have one asset transfer to an account of a gateway, plus a message to the gateway that says "Withdraw" and presumably contains the DOGE withdraw address as well?

And again, if the gateway gets compromised, the attacker can steal the assets? If have understood the whole process, there are three (and only three) gateways, and even if one of them gets compromised, there are time windows where the attacker can both steal the DOGE deposits to this gateway and the NXT assets used for withdrawals.

The withdraw address is set ahead of time, so it does not have to be sent with the withdrawal. If a new withdraw address is desired, it can be changed with an AM sent to the gateway. The moment any of the NXT assets are transferred without a corresponding validating transaction, alerts will be generated and all withdrawals of that asset will be frozen.

Two gateways would need to be compromised at the same time to get at the shared deposit acct due to the multisig. Deposits in transit at that gateway could be stolen, but the polling for deposits can be set to 50 milliseconds, so the window of opportunity is pretty small. The recommendation is to locate the server in a security hardened facility or use one of the secure amazon servers used for credit card processing.

We can also use cold multisig wallets when the shared multisig acct gets too big.

Granted, this is not perfect, but how does it compare to a centralized exchange? That is the key question isnt it?

James

Edit: do you have any suggestions on how to improve things?

[antanst]

Deposits in transit at that gateway could be stolen, but the polling for deposits can be set to 50 milliseconds, so the window of opportunity is pretty small.

That's where I'm focusing at. It doesn't matter if it's 50 ms or 5000 seconds. If the gateway is compromised, the attacker can steal the deposits destined to this gateway. In effect, you have secured the DOGE storage pool via multisig transactions, but since the deposits are vulnerable to a compromise while on transit, you don't gain anything security-wise.

Granted, this is not perfect, but how does it compare to a centralized exchange? That is the key question isnt it?

I believe the key question is if it can be used as a truly decentralized ALTCOIN<->NXT exchange, in which case it can't. It has a centralized point of failure.

Granted, building a decentralized cross-chain exchange is an extremely difficult problem, which I'm not sure if it's solvable with the current limitations of coin daemons and NXT AE.  Unfortunately, I do not have any suggestions right now, but I'll keep thinking about it. It's worth it, and you seem to be on the right path.

[jl777]

antanst, who is now the designated Evil Bob, has raised the issue of a gateway server being compromised.

I read about some security hardened servers somewhere, but I cant find the URL. It was setup so that the software running on it couldnt be changed, without some elaborate process. I am pretty sure amazon offered some such service. If anybody knows about this, please post.

Is it worth implementing 2 of 3 multisig for the transitory deposit accounts? Hmmm. Actually, I think we could avoid the sweep account entirely. The withdrawals would gather up unspent txouts from the required custom multisig accts. I could even make the user be one of the signers on the custom multisig acct, but not sure what utility that has. As people trade assets, their NXT AE balance will diverge from what they deposited. Then again, someone who deposits 10 BTC is a lot more likely to have significantly more NXT assets than someone who deposits 0.1 BTC

I cant rely on bitcoind to keep track of account deposits anymore and will need to correlate all NXT asset transfers with all deposits. But I do like having lots of multisig accts, it sure makes it much less of a target. I can even prioritize the withdrawals to even out the balances of all the multisig accts, that way each one will contain 1/N of the total deposits, at least as best as can be matched up with withdrawals.

antanst, I think you will be happy that the deposit 50 millisecond vulnerability will be gone. We will have realtime NXT asset reconciliations and mechanisms to immediately freeze any withdrawals if we detect anomalies.

How else can we improve this?

James

[antanst]

antanst, who is now the designated Evil Bob, has raised the issue of a gateway server being compromised.

The real issue isn't if (or rather when) a gateway is compromised and how one can secure it. It is the reliance on a single gateway.

I read about some security hardened servers somewhere, but I cant find the URL. It was setup so that the software running on it couldnt be changed, without some elaborate process. I am pretty sure amazon offered some such service. If anybody knows about this, please post.

I can set up a FreeBSD jail this way (it's like a VM). Files can be read only inside the VM. One can harden a server pretty much if convenience isn't a concern. But again, isn't the real issue.

[antanst]

Is it worth implementing 2 of 3 multisig for the transitory deposit accounts? Hmmm. Actually, I think we could avoid the sweep account entirely. The withdrawals would gather up unspent txouts from the required custom multisig accts. I could even make the user be one of the signers on the custom multisig acct, but not sure what utility that has. As people trade assets, their NXT AE balance will diverge from what they deposited. Then again, someone who deposits 10 BTC is a lot more likely to have significantly more NXT assets than someone who deposits 0.1 BTC

If you keep a 1 DOGE <-> 1 DOGENXTASSET analogy, why would you want to keep track of NXT AE balances? Unless there's a compromise, there will always be as many assets as DOGE's deposited, regardless of who has them.

[jl777]

Is it worth implementing 2 of 3 multisig for the transitory deposit accounts? Hmmm. Actually, I think we could avoid the sweep account entirely. The withdrawals would gather up unspent txouts from the required custom multisig accts. I could even make the user be one of the signers on the custom multisig acct, but not sure what utility that has. As people trade assets, their NXT AE balance will diverge from what they deposited. Then again, someone who deposits 10 BTC is a lot more likely to have significantly more NXT assets than someone who deposits 0.1 BTC

If you keep a 1 DOGE <-> 1 DOGENXTASSET analogy, why would you want to keep track of NXT AE balances? Unless there's a compromise, there will always be as many assets as DOGE's deposited, regardless of who has them.

Because I have to issue the max possible DOGE assets upon creation. So there are 1 billion DOGE assets, but without a matching deposit, we cannot let them into the wild. Even if we had assets that can be created incrementally, what is to stop an attacker from just creating more assets after the server is compromised.

So, my solution is to put AE asset balance auditing into nodecoin and all the gateways. If there is an unexpected discrepancy, all withdraws are stopped. If the compromised asset cant be reclaimed, then the plan is to do an emergency swap with a DOGENXTASSET.2. Everybody will get their old DOGE asset swapped for the new version based on verified balance. A total mess to say the least, but the alternative is to just let them take the asset and drain the deposit accts.

Also, by not having a sweep acct, I cannot just look at the deposit addrs unspent outputs to find unprocessed deposits. I need to correlate all prior AE transfers with matching deposits and any unmatched deposits needs to trigger the Asset issuance. It is a much more complicated thing, but as you say, reliance on single gateway isnt good enough.

I also want to add google authenticator option for withdrawals.

James

[jl777]

antanst, aka Evil Bob impersonator, has raised a security weak spot in the current gateway design.
Each gateway currently generates a custom deposit address and when a deposit comes in, it immediately sweeps it to the main multisig acct. The duration of exposure is less than a second (could be set to 50 milliseconds), but it is exposure.

So, I am changing things so that there is no sweeping into a main account. All custom deposit addresses will be 2 of 3 multisig. This will require a fair amount of internal changes, but it eliminates the in transit deposit exposure. Now, all deposits will go directly into a multisig account and stay there until a withdraw request needs the funds.

The multigateway isnt perfect, but I will do everything possible to make sure it is as safe as I can make it.

Does anybody know how to setup google authenticator? I think it works by having a seed value associated with each user. I can put the encrypted value of this seed in the AM response to the user. Then for people who choose to activate this feature, they would need to go to a webpage, input their NXT acct # and authenticator token

With such a setup, can anybody think of how Evil Bob can attack the gateway? All I can think of it a spite DDos attack that would just slow things down, but no money lost. Any other attack vectors? Can someone forge the NXT acct # in the "sender" field in a confirmed AM transaction?

James

[jl777]

10000 NXT BOUNTY for google authenticator help


I am announcing a 10000 NXT bounty for someone to help me integrate google authenticator to the gateway. It will be paid when the gateway passes the community created test plan for multigateway.

I need someone that can do the webpages needed for account # and token input and the server side code that properly correlates that. along with whatever other help I need. Especially making sure the process is secure.

James

Edit: I need someone to host a webpage for users to put in their acct# and token and also a mechanism for gateway code interact with the webpage. Ultimately, the webpage will be moved to the gateway

[antanst]

Ultimately, the webpage will be moved to the gateway

That's bad security. You don't want to host the website on the gateway. The gateway should not run services that take arbitrary inputs.

The only thing that should run there is your software, and it would take it's input from NRS and dogecoind. You don't need any other input right? Only those two daemons plus internal communication between the gateways. So, not even dogecoind or nrs should run on the same machine/VM, it would just remotely communicate through RPC/JSON with them.

[jl777]

I guess the webpage is pretty isolated from any TOTP calculations, so it stays on a separate site.

I had thought that it somehow had to be passing sensitive info over the internet.

Looking at the code Ciyam gave me https://github.com/ciyam/ciyam/blob/master/src/crypt_stream.cpp#L173
it seems that if I have the secret for the user, I can generate the token needed.

I think I need C functions that I can call that will:

1. Generate acceptable random password to use, maybe just `openssl rand -base64 50` and then encrypt it with gateway's private key.

gateway publishes this in the AM response that binds the deposit address to NXT acct.

2. A function that takes as input the encrypted data and gateways private key and returns the TOTP

Then we need some sort of way for the website to send a request to the gateway with NXT acct# and user input token. If it is good, then the withdraw request is marked as approved. If error, this gets relayed back to webpage


James

[jl777]

Ultimately, the webpage will be moved to the gateway

That's bad security. You don't want to host the website on the gateway. The gateway should not run services that take arbitrary inputs.

The only thing that should run there is your software, and it would take it's input from NRS and dogecoind. You don't need any other input right? Only those two daemons plus internal communication between the gateways. So, not even dogecoind or nrs should run on the same machine/VM, it would just remotely communicate through RPC/JSON with them.

I am still in the mode of creating all the modules and once they are done, then we probably want to put one process per VM? I am assuming that once all the modules are done, isolating each of them is just a matter of installing things properly and setting up the firewalls to only allow the one task that each VM is doing.

I still have a horrible shortcut of invoking dogecoind via system("./dogecoind <args>") I am pretty sure that isnt the best way of doing it, but just havent had the chance to do the RPC thing. I am parsing the JSON output, so all that would stay the same. Though, my hardcoded parsing is also probably not the best way of doing things.

I also use a linear list for just about everything. At small numbers of transactions, its not a problem, but it wont scale with thousands of accounts. I am isolating all searches, so we can always replace it with a more efficient method.

This started out as a proof of concept, so it could use a refactoring by someone who knows all the best techniques.

For now, I will work on the control flow and ignore these issues until we have fully functioning gateway.

James

Edit: If my code just serves as a spec and has to be totally refactored, I am ok with that, in fact I would prefer that. I was thinking we could run the refactored version on one of the gateways and then we have two independent implementations so any bug in one wouldnt be replicated on all the gateways. Maybe we need two independent refactorings?

[antanst]

I think I need C functions that I can call that will:

1. Generate acceptable random password to use, maybe just `openssl rand -base64 50` and then encrypt it with gateway's private key.

You mean public key, right? What's the password needed for? I think I still haven't grasped the architecture you have in mind.

2. A function that takes as input the encrypted data and gateways private key and returns the TOTP

Then we need some sort of way for the website to send a request to the gateway with NXT acct# and user input token. If it is good, then the withdraw request is marked as approved. If error, this gets relayed back to webpage

It's been a long time since I dabbled in C, and I avoid anything that requires manual memory management like a plague. Nowadays I only deal with Python and Javascript.

So, I can quickly throw code in Python if it's acceptable to you. I believe the best and most simple way for some processes to communicate is via  JSON requests, like NRS does.

What does TOTP stand for? The lore of those acronyms eludes me.

In any case, we'll need a clear layout of the workflow and the separate parts. What exactly will the web UI ask for the user, what inputs and outputs do you want from this UI. What are the modules you are implementing, what function will each one perform, and it's inputs and outputs.

[jl777]

I think I need C functions that I can call that will:

1. Generate acceptable random password to use, maybe just `openssl rand -base64 50` and then encrypt it with gateway's private key.

You mean public key, right? What's the password needed for? I think I still haven't grasped the architecture you have in mind.

2. A function that takes as input the encrypted data and gateways private key and returns the TOTP

Then we need some sort of way for the website to send a request to the gateway with NXT acct# and user input token. If it is good, then the withdraw request is marked as approved. If error, this gets relayed back to webpage

It's been a long time since I dabbled in C, and I avoid anything that requires manual memory management like a plague. Nowadays I only deal with Python and Javascript.

So, I can quickly throw code in Python if it's acceptable to you. I believe the best and most simple way for some processes to communicate is via  JSON requests, like NRS does.

What does TOTP stand for? The lore of those acronyms eludes me.

In any case, we'll need a clear layout of the workflow and the separate parts. What exactly will the web UI ask for the user, what inputs and outputs do you want from this UI. What are the modules you are implementing, what function will each one perform, and it's inputs and outputs.

1. I just want to use the blockchain as a reliable redundant storage of the user's magic number. I am pretty sure I need to encrypt it with a private key that only the gateway(s) know. That way, on startup, the gateways scan the blockchain and load each users magic number.

My understanding is that the google authenticator algorithm generates a time dependent token that is purely based on a user specific magic number combined in some way with the website. This token is called a TOTP.

JSON is fine. I can setup a port that waits for { "acct":"45372594753443", "TOTP":"123456" }
I will just return { "result":"user visible string" }

So there will be a webpage on your server that just asks for the NXT acct # and google authenticator token. You send it to the gateway, which returns a success or error string.

What the gateway will do when it gets a packet from your website is that it will look up the acct and extract the magic number, generate the TOTP and if they match, mark the withdrawal as approved.

I still have to figure out how to encrypt and decrypt and generate the magic number. I think the website will need to generate and display a QR code that the user can take a picture with to initialize google authenticator. It would be great if you can figure out how to integrate google authenticator to a website

James

[antanst]

Ok, I figured this out. Stay tuned, hopefully tomorrow I'll have something ready :-)

[oldnbold]

antanst, who is now the designated Evil Bob, has raised the issue of a gateway server being compromised.

I read about some security hardened servers somewhere, but I cant find the URL. It was setup so that the software running on it couldnt be changed, without some elaborate process. I am pretty sure amazon offered some such service. If anybody knows about this, please post......

James

Is this what you have in mind?

If not I'll do some more searching.

Deep Security as a Service delivers a complete set of security capabilities for Amazon Web Services including intrusion detection and prevention, firewall, anti-malware, web reputation and integrity monitoring. The service runs on AWS for rapid deployment and security can be elastically added to instances for instant protection from a centrally managed security console.

http://www.trendmicro.com/us/business/saas/deep-security-as-a-service/index.html

There's a 30 day free trial

I found the above site linked from the following

Over the past weeks we have been reviewing the top 10 tips for securing instances running on Amazon Web Services. We walked through the critical controls as part of the AWS shared security model. As noted in these tips, host-based security capabilities such as intrusion detection and prevention, anti-malware, and integrity monitoring are critical for protecting your applications and data.

While some of these recommended tips involve configuring and tuning AWS itself, some require the use of third-party tools....

http://cloud.trendmicro.com/5-questions-aws/

[mcjavar]

I´m glad there is some activity here. Let me know if I can do anything for you, guys.

[jl777]

antanst, who is now the designated Evil Bob, has raised the issue of a gateway server being compromised.

I read about some security hardened servers somewhere, but I cant find the URL. It was setup so that the software running on it couldnt be changed, without some elaborate process. I am pretty sure amazon offered some such service. If anybody knows about this, please post......

James

Is this what you have in mind?

If not I'll do some more searching.

Deep Security as a Service delivers a complete set of security capabilities for Amazon Web Services including intrusion detection and prevention, firewall, anti-malware, web reputation and integrity monitoring. The service runs on AWS for rapid deployment and security can be elastically added to instances for instant protection from a centrally managed security console.

http://www.trendmicro.com/us/business/saas/deep-security-as-a-service/index.html

There's a 30 day free trial

I found the above site linked from the following

Over the past weeks we have been reviewing the top 10 tips for securing instances running on Amazon Web Services. We walked through the critical controls as part of the AWS shared security model. As noted in these tips, host-based security capabilities such as intrusion detection and prevention, anti-malware, and integrity monitoring are critical for protecting your applications and data.

While some of these recommended tips involve configuring and tuning AWS itself, some require the use of third-party tools....

http://cloud.trendmicro.com/5-questions-aws/

This isnt exactly what I saw, but it does look highly relevant. Can you dig up some objective reviews about this service, especially how it compares to other similar services? Once we find one, we can find all its competitors and then choose the best one for our needs

Thanks for the legwork, it saves me time hour for hour!

James

[antanst]

Google authenticator works this way:

There's a secret key (a random string) that leads deterministically to the TOTP token, depending only on time. Both the server (the web site) and the client (user) should know this key, so usually the server shows this secret key to the user via a QR code and the user scans this to his Google Authenticator app (on his phone).

The user afterwards generates the TOTP and gives it back to the server. The server compares the given TOTP with his own TOTP, and if they match, the user is verified. This must be done within 30 seconds, because afterwards the TOTP changes value and it must be sent again.

If you want to verify a user from your gateway as well, we should somehow share the secret key.

I've made a test web site in Python (using Flask) that once a user visits the site, the server sends to the gateway this command  (the names are purposefully descriptive):

Code:

{"command":"request_doge_address_and_authenticator_key"}

and waits for the following:

Code:

{"doge_multisig_address_for_deposit":"...", "user_secret_key_for_authenticator":"..."}

It then renders the web site where the user enters his NXT address, and authenticates via Google Authenticator (a QR code of the secret key is presented). The DOGE address to which he should make his deposit is also shown with QR code.

When the user submits the form, the following is sent to the gateway:

Code:

{"user_NXT_account":"...","user_secret_key_for_authenticator":"..."}

After this, you have all you need to associate the user's secret key with the DOGE multisig address and his NXT account. You can use AES encryption to encrypt this data before you put it in the blockchain.

All this is just for locally testing the whole concept, of course. Relying on Google Authenticator as the sole method of authentication is like asking for trouble. We'll find many more issues on the way I guess, but at least we can begin testing.

Look at README.txt for instructions on how to run it.

https://mega.co.nz/#!Vd0lzT5b!zJSagQT743QhAkUMzvGU-2YM_p8WXDq1adeZ5z0lFzA

[jl777]

Google authenticator works this way:

There's a secret key (a random string) that leads deterministically to the TOTP token, depending only on time. Both the server (the web site) and the client (user) should know this key, so usually the server shows this secret key to the user via a QR code and the user scans this to his Google Authenticator app (on his phone).

The user afterwards generates the TOTP and gives it back to the server. The server compares the given TOTP with his own TOTP, and if they match, the user is verified. This must be done within 30 seconds, because afterwards the TOTP changes value and it must be sent again.

If you want to verify a user from your gateway as well, we should somehow share the secret key.

I've made a test web site in Python (using Flask) that once a user visits the site, the server sends to the gateway this command  (the names are purposefully descriptive):

Code:

{"command":"request_doge_address_and_authenticator_key"}

and waits for the following:

Code:

{"doge_multisig_address_for_deposit":"...", "user_secret_key_for_authenticator":"..."}

It then renders the web site where the user enters his NXT address, and authenticates via Google Authenticator (a QR code of the secret key is presented). The DOGE address to which he should make his deposit is also shown with QR code.

When the user submits the form, the following is sent to the gateway:

Code:

{"user_NXT_account":"...","user_secret_key_for_authenticator":"..."}

After this, you have all you need to associate the user's secret key with the DOGE multisig address and his NXT account. You can use AES encryption to encrypt this data before you put it in the blockchain.

All this is just for locally testing the whole concept, of course. Relying on Google Authenticator as the sole method of authentication is like asking for trouble. We'll find many more issues on the way I guess, but at least we can begin testing.

Look at README.txt for instructions on how to run it.

https://mega.co.nz/#!Vd0lzT5b!zJSagQT743QhAkUMzvGU-2YM_p8WXDq1adeZ5z0lFzA

Great stuff!

The google authenticator is the second authentication. All withdraw requests, actually all requests, verify that the NXTaddr matches the sender of the AM. So, only the one who controls the NXTaddr should be able to set/change the withdraw address.

Nervous about sharing secrets. Maybe there is no need to? All the gateway really needs is a second approval before releasing a withdrawal. maybe include withdrawal address and amount in the data that is gathered? then I can match it up with any withdraws in the queue