Pages:
Author

Topic: Abrir exchange de Bitcoins (Read 4814 times)

member
Activity: 81
Merit: 10
March 23, 2014, 12:38:56 PM
#27
E uma sala de poker a BTC? Igual a sealsclub? O que acham do negócio? tem futuro?

bom... pra mim se vale um centavo a rodada de truco, poker ( não sei jogar) ou dominó... enfim qualquer jogo de azar, eu não jogo. Jogo somente na esportiva.

Mas esse sou eu... e não perco o meu dinheiro em apostas... somente no mercado de compra e venda de btc que pelo menos eu tenho uma previsão do que vai dar e normalmente eu tenho lucro nas operações.

Mas até onde eu percebo, tem vários camaradas meus bem viciados em poker.

Acredito que poderia funcionar.

Mas teria que ser um esquema muito bem bolado para não ficar com cara de site de phising.









Valeu pela resposta.    Smiley
sr. member
Activity: 378
Merit: 250
Step into a world!! A P2P world!
March 21, 2014, 11:31:42 AM
#26
E uma sala de poker a BTC? Igual a sealsclub? O que acham do negócio? tem futuro?

bom... pra mim se vale um centavo a rodada de truco, poker ( não sei jogar) ou dominó... enfim qualquer jogo de azar, eu não jogo. Jogo somente na esportiva.

Mas esse sou eu... e não perco o meu dinheiro em apostas... somente no mercado de compra e venda de btc que pelo menos eu tenho uma previsão do que vai dar e normalmente eu tenho lucro nas operações.

Mas até onde eu percebo, tem vários camaradas meus bem viciados em poker.

Acredito que poderia funcionar.

Mas teria que ser um esquema muito bem bolado para não ficar com cara de site de phising.





member
Activity: 81
Merit: 10
March 20, 2014, 03:17:53 PM
#25
E uma sala de poker a BTC? Igual a sealsclub? O que acham do negócio? tem futuro?
sr. member
Activity: 378
Merit: 250
Step into a world!! A P2P world!
March 17, 2014, 04:37:47 AM
#24
Discussão super bacana  Grin.
[...]
Usando um 2AF, como o google authenticator, não incrementaria ainda mais a segurança, tornando uma obrigação declarar a chave gerada pelo 2AF?
[...]
...
Mas não há como impedir que o usuario cometa erros e inadvertidamente entregue suas senhas e demais dispositivos para um ladrão, como ilustração até posso contar um ocorrido recente onde conheci um caso onde o ladrão após conseguir acesso remoto a conta bancaria de uma vitima, ligou pra criatura e pediu o numero que aparece no token de segurança (alegando ser checagem de segurança do banco), ao que foi atendido prontamente, e claro efetivou o roubo.  Grin
Isso acontece com sistema bancário tradicional, imagina com Bitcoin onde quase ninguem entende a tecnologia ...  Roll Eyes
Nosss.. a pessoa que passou o número pro assaltante não era curitibana.... kkkk Desconfiometro zero!

Quote
Acho que o maior problema atual com os sites de Bitcoin é que eles inevitavelmente anunciam falência por "roubo" da Hot Wallet, o que já está se tornando um padrão sinistro.
Não poderia ser utilizado uma espécie de sand box tbm? Como resultado, todo o fluxo de dados que vai pra memória seria digamos criptografado. Caso alguém chegue lá, tem algo quadrado escrito com letras gregas... kkk

Quote
O sistema ainda estaria vulnerável a ameaças internas, como funcionários e fornecedores que eventualmente tenham acesso fisico ao CronServer.
Não existe milagre tbm... a menos que você fosse o único funcionário. Fato que seria extremamente desgastante.

Quote
Outras partes do sistema não foram mencionadas, como o Time Lock Vault, que é uma cold wallet que tem horário marcado de abertura, e precisa de um esforço computacional gigantesco para ser aberto, o que garante o horário da abertura.
Tem que verificar a capacidade de liquidez do mercado. Se for realizado muita especulação, como com o dogecoin no cryptsy, precisa ter moedas disponíveis  Wink

Quote
E também tenho uma ideia ainda não testada que seria implementar carteiras rotativas, onde o saldo ficaria transitando de uma a outra continuamente, e cujo destino seria computado a partir de um PRNG, portanto não haveria uma forma simples de saber em qual servidor estão as coins.
Eu acho que a rotatividade de carteiras se encaixa bem para a  carteira BTC 0.9 beta, onde comentaram que realizaram melhorias para evitar ataques de maleabilidade da rede. Hote tem transações que levam quase 6 horas pra acontecer por causa do maldito ataque a rede p2p.

Quote
Enfim, ideias não faltam, estou só aguardando o dia que alguem queira colocar tudo isso em pratica e ter um exchange padrão bancário Cheesy
Ultimo desafio é saber se todo o gasto está compreendido na tarifa de 0,3% de BTC da negociação realizada. Caso todo o processo consuma muita energia, vc poderia estar no preju ou quase não ter lucro.

 Grin

hero member
Activity: 882
Merit: 1000
It's got electrolytes
March 16, 2014, 11:08:03 PM
#23
Discussão super bacana  Grin.
[...]
Usando um 2AF, como o google authenticator, não incrementaria ainda mais a segurança, tornando uma obrigação declarar a chave gerada pelo 2AF?
[...]

Confesso que no meu sistema não inclui nenhuma segurança individual para o usuario, só pensei a segurança no sentido da Hot Wallet.
Penso que no aspecto da segurança individual deve-se usar o padrão tecnologico atual mesmo, SSL, Login Token, 2AF, frase secreta, cartao de senhas, etc.

Mas não há como impedir que o usuario cometa erros e inadvertidamente entregue suas senhas e demais dispositivos para um ladrão, como ilustração até posso contar um ocorrido recente onde conheci um caso onde o ladrão após conseguir acesso remoto a conta bancaria de uma vitima, ligou pra criatura e pediu o numero que aparece no token de segurança (alegando ser checagem de segurança do banco), ao que foi atendido prontamente, e claro efetivou o roubo.  Grin
Isso acontece com sistema bancário tradicional, imagina com Bitcoin onde quase ninguem entende a tecnologia ...  Roll Eyes

Acho que o maior problema atual com os sites de Bitcoin é que eles inevitavelmente anunciam falencia por "roubo" da Hot Wallet, o que já está se tornando um padrão sinistro.

Pensando nisso eu projetei um sistema que fosse realmente a prova de ladrões externos, sendo praticamente impossivel roubar as coins, mesmo com acesso root ao site.

O sistema ainda estaria vulnerável a ameaças internas, como funcionarios e fornecedores que eventualmente tenham acesso fisico ao CronServer.

Outras partes do sistema não foram mencionadas, como o Time Lock Vault, que é uma cold wallet que tem horário marcado de abertura, e precisa de um esforço computacional gigantesco para ser aberto, o que garante o horário da abertura.

E também tenho uma ideia ainda não testada que seria implementar carteiras rotativas, onde o saldo ficaria transitando de uma a outra continuamente, e cujo destino seria computado a partir de um PRNG, portanto não haveria uma forma simples de saber em qual servidor estão as coins.

Enfim, ideias não faltam, estou só aguardando o dia que alguem queira colocar tudo isso em pratica e ter um exchange padrão bancário Cheesy



sr. member
Activity: 378
Merit: 250
Step into a world!! A P2P world!
March 16, 2014, 08:59:19 AM
#22
Discussão super bacana  Grin.

É fácil ver os volumes de BTC circulando pra lá e pra cá, mas por trás dos panos.....

No caso do esquema do Algorista, é considerado o sistema com o usuário somente logando via navegador?

Usando um 2AF, como o google authenticator, não incrementaria ainda mais a segurança, tornando uma obrigação declarar a chave gerada pelo 2AF?

Por exemplo: Para a transação acontecer, seria gerado um par que seria a chave privada do usuário + chave 2AF que troca a cada 10 segundos.

Se o que eu falei acima funcionar, uma das condições para abrertura da conta no site da exchange, seria ter um 2AF obrigatoriamente, pois é de dinheiro que estamos falando!

Talvez eu esteja somente viajando...  Grin
hero member
Activity: 882
Merit: 1000
It's got electrolytes
March 16, 2014, 08:37:47 AM
#21
Algorista, os robôs de fita ainda existem em datacenters novinhos em folha...
[...] e de tempos em tempos os robôs davam cabeçada um no outro, pois um deles era enviado para um endereço que estava após o segundo robô... e olha que considerando a velocidade com que eles se movem, era uma senhora cacetada.

Adriano

Eu já vi muito isso acontecer, e é muito divertido de ver, pra quem não é o responsável pelo funcionamento das pestinhas claro kkkk.

 Grin

Eu jurava que esses robots não existiam mais, pois já faz mais de uma década que não vejo um.

staff
Activity: 1286
Merit: 1085
March 15, 2014, 09:48:55 PM
#20
PS: HEHEEHEHEUHEHEHU Eu sei, doideira a ideia do robô, mas ela me agrada.

Com certeza sua ideia é de longe a mais interessante de todas  Grin



Em datacenters antigos tinha aqueles robots de troca de fita DAT, e aquilo era divertido de ver.  Roll Eyes





Algorista, os robôs de fita ainda existem em datacenters novinhos em folha... e estão bem moderninhos, coisa linda de se ver quando estão a todo vapor.

A algum tempo vi uma situação inusitada: Era uma sala de fitas com dois robôs (braços mecânicos) em cada corredor, de acordo com a fita que era necessária o software calculava qual o braço que estava mais próximo (considerando a fila de requisições) e comandava o robô para pegar determinada fita. Acontece que uma atualização de microcódigo inseriu um bug no sistema e de tempos em tempos os robôs davam cabeçada um no outro, pois um deles era enviado para um endereço que estava após o segundo robô... e olha que considerando a velocidade com que eles se movem, era uma senhora cacetada.

Adriano
member
Activity: 81
Merit: 10
March 15, 2014, 12:16:32 PM
#19
up
member
Activity: 81
Merit: 10
March 14, 2014, 03:01:53 AM
#18
Pessoal, o que acham da ideia de ao invés de negociar diretamente BTC, o cliente da exchange negociar uma espécie de vale? Eai quando quiser pode trocar por BTC reais que ficam por sua vez guardados no servidor frio. E o que acham da ideia do sistema de braço robotico no servidor?
member
Activity: 81
Merit: 10
March 14, 2014, 12:58:26 AM
#17
PS: HEHEEHEHEUHEHEHU Eu sei, doideira a ideia do robô, mas ela me agrada.

Com certeza sua ideia é de longe a mais interessante de todas  Grin



Em datacenters antigos tinha aqueles robots de troca de fita DAT, e aquilo era divertido de ver.  Roll Eyes






EHUEHUEHUEUEUEHUEHU Sim, mas o robô seria bem simples, eu falo robô e tal mas não é nada mais do que um servo motor ou um motor de passo que faz o serviço de esticar ou retrair o braço que tem na sua ponta o cabo de rede. Smiley
hero member
Activity: 882
Merit: 1000
It's got electrolytes
March 14, 2014, 12:35:06 AM
#16
PS: HEHEEHEHEUHEHEHU Eu sei, doideira a ideia do robô, mas ela me agrada.

Com certeza sua ideia é de longe a mais interessante de todas  Grin



Em datacenters antigos tinha aqueles robots de troca de fita DAT, e aquilo era divertido de ver.  Roll Eyes



member
Activity: 81
Merit: 10
March 14, 2014, 12:17:31 AM
#15
rsrs essa do Robo foi boa, mais se sua intenção é colocar a maquina na rede e depois desconectar a mesma não é mais fácil rodar o script que de tempos em tempos da um up ou down na interface de rede?


Exato, eu pensei nisso, mas o meu medo é que o fio vai ficar conectado lá e nunca podemos saber o que vai acontecer. Então eu ficaria mais tranquilo se o fio estivesse a uns 10 CM no mínimo de distância do servidor frio.


PS: HEHEEHEHEUHEHEHU Eu sei, doideira a ideia do robô, mas ela me agrada.
newbie
Activity: 28
Merit: 0
March 13, 2014, 11:58:50 PM
#14
rsrs essa do Robo foi boa, mais se sua intenção é colocar a maquina na rede e depois desconectar a mesma não é mais fácil rodar o script que de tempos em tempos da um up ou down na interface de rede?
member
Activity: 81
Merit: 10
March 13, 2014, 11:49:41 PM
#13
Também vale lembrar que o mercado pra exchanges que operam exclusivamente com criptomoedas já está saturado, e operam em nível mundial e não nacional.

O que os brasileiros demandam nesse momento são empresas para atuar primariamente com R$, e pra esse tipo de empresa, tantos exchanges quanto gateways de pagamentos estão com alta demanda.

Também existe a questão da segurança juridica, portanto será preciso de mecanismos que proteja ambos os lados, exchange e usuario.

É preciso pensar também no tempo de aceitação do seu produto, pois para receber depositos será preciso primeiro estabelecer a reputação.

Você pediu pra não falar em segurança dos acessos, mas acho isso o ponto central de qualquer negocio baseado em criptomoedas, e nisso posso te dar uma sugestão de arquitetura.
O ano passado eu projetei esse rascunho abaixo, que seria a minha visão de um exchange seguro (contra roubo de moedas).
É um rascunho bem basico e ainda precisa melhorar muitas coisas, mas deixo como sugestão.



O legal dessa minha arquitetura é que é praticamente impossível ter acesso as moedas entrando pelo webserver, e o servidor das carteiras (cronserver) poderia ficar em qualquer lugar, inclusive em um datacenter pequeno, não demanda muita internet ou processamento, só precisa ser mantido em segredo e com boa segurança física e logica.
Inclusive no projeto estão previstas as proteções contra depósitos forjados, saques inválidos, saldos fraudulentos, e clonagem de operações de mural.




Nossa, cara, muito bacana seu esquema, gostei muito. Obrigado por postar. Só uma coisa, eu não disse para não falarem de segurança, apenas disse para não se atentarem só a isso, segurança é importante demais sim, mas é que senão ficaríamos presos só a esse tema, abraços.

Vendo o que disse o "person" eu ia fazer um sistema bem digamos assim, "tempos das cavernas" pois o sistema seria manual.
Seria da seguinte forma: Os usuários do site fariam os depósitos de seus BTC, porém após os depósitos serem feitos no exchange e confirmados, a carteira seria enviada para dois HD´s encriptados (Eu já possuo esses dois HD´s, como eu disse, eu tenho várias peças de PC´s por aqui, por isso a vontade de montar meu próprio servidor) um dos HD´s seria o principal e o outro um backup. Esses HD´s seriam ligados a uma placa mãe, enfim, em um computadorzinho bem vagabundinho, porém o serviço dele seria apenas pegar as carteiras novas e enviar aos HD´s e após isso, cortar a conexão com a  rede. Não sei se vocês entenderam, mas seria basicamente assim, quando uma nova carteira é criada no servidor principal, ele envia ao servidor frio (Que é esse dos HD´s) uma requisição, uma espécie de senha, após isso,  o servidor frio se conectaria com a rede, então ele rapidamente faria o envio das carteiras para o HD 1 e depois de desconectaria da rede. Então o PC se encarregaria de enviar um backup ao HD2.

Mas o problema dessa minha ideia é o fato de que de qualquer forma o computador teria que estar conectado na rede e isso dá medo. Não importa se a conexão seria fechada ou não. Porém pensando nisso, eu tive até uma ideia maluca hoje a tarde:


PS: A ideia é bem doida, eu sei:

Eu tenho uma certa experiência com automação, eletrônica e tal, não sou nenhum gênio, mas me viro bem, então como eu também tenho uns motores de passo aqui, eu iria criar uma espécie de robô, algo simples, apenas um braço que estica e contrai. Na ponta do braço ficaria a ponta do cabo de rede (Nada, absolutamente nada WiFi) e ele ficaria preso em uma espécie de esteira para não ter o problema de não acertar o alvo, enfim, isso é o de menos. Quando uma nova carteira fosse criada, o servidor principal enviaria para o robô um alerta, o robô então seria ativado e conectaria o cabo de rede a placa de rede do servidor frio (Sabem aquela cabecinha que prende o plug de rede? Ela seria retirada pois ela daria trabalho), o servidor frio então começaria seu serviço e quando não houvesse mais nada ou quando se esgotasse um certo tempo (Bem pouco tempo) o servidor frio enviaria o seu sinal ao robo e esse se contrairia. Sei que é esquisito, mas é o que eu pensei hehehehe. Agora, essa minha ideia esbarra no problema de vamos supor a exchange se tornar grande demais.

Uma coisa, quando a negociação, o esquema seria simples, os usuários negociariam tickets e não os BTC´s em si. Eles só teriam acesso a moeda quando quisessem sacar, dando assim mais segurança. E o saque seria automático, feito por robôs.
hero member
Activity: 882
Merit: 1000
It's got electrolytes
March 13, 2014, 11:40:35 PM
#12
Adiciona uma ideia que um dia imagino implementar pra testar...

1. O usuario assina a operacao de compra e venda na maquina dele e manda para a exchange (pode ser browser-based como a wallet do blockchain.info).
2. O servidor registra essa transacao completa (com assinatura)
3. Uma maquina fica lendo um feed dessas transações e exibe um QR code na tela
4. Uma outra maquina do outro lado da sala fica com uma camera apontada para essa tela, lendo os QR Codes (air gap)
5. Essa outra maquina verifica a assinatura e o conteudo da transacao e processa (ou descarta).

Se alguem invadir o servidor, só vai conseguir modificar registros de transacao ou gerar QRs errados... mas a assinatura vai ser invalida...

Essa sua ideia do air gap é muito sinistra Grin kkk - eu gostaria de ver isso um dia.

Quanto a parte do root access e da falsificação dos Login Tokens, é justamente pra isso que projetei o sistema de dois servidores, com acesso unidirecional, e com todas as validações no CronServer, portanto ele gera os tokens, e só ele tem a chave privada pra gerar.

Imagine que um usuario faz um login valido, então é gerado um registro no webserver, logo o cronserver entra e preenche esse registro com um Login Token, mas antes ele confere o hash da senha informada (senha que não existe no webserver).
Esse token é então registrado em todas as operações do usuario e será conferido pela auditoria no cronserver.
Portanto um usuario não consegue se passar por outro, mesmo com acesso root no webserver.

Pra gerar tokens validos é preciso primeiro ganhar acesso root no CronServer, e acho que esse acesso só se consegue com o ataque da barra de ferro  Grin

Eu não conseguiria perpetrar tal ataque, mas um cara com braço forte conseguiria kkk  Roll Eyes

sr. member
Activity: 315
Merit: 250
March 13, 2014, 10:51:23 PM
#11
Muito bacana a arquitetura. Eu acrescentaria mais 2 coisas:

1- um firewall dedicado entre o webserver e o cronserver que permite conexões TCP apenas em uma direção (do cronserver para o webserver).
2- colocaria dois níveis de carteiras, uma sem a chave privada que seria usada apenas para conexão com a internet, e outra, fora da internet com conexão apenas para a carteira do primeiro nível via interface de rede dedicada, essa sim contendo as chaves. Assim você isola da internet TOTALMENTE a carteira que contem as chaves, ficando praticamente impossível hackear as carteiras. (com o custo de ter um servidor a mais)

O item 1 não tem como ser implementado pois a ideia é o webserver não saber o IP do cronserver de forma nenhuma, nem mesmo inspecionando os pacotes. Por isso sugeri conexão por VPN e unilateral por SSH redirecionando a porta do BD (MySQL possivelmente).

O item 2 achei uma ideia espetacular, vou adicionar ao projeto arquitetonico, ideia muito boa mesmo, pois evita até um ataque bruto na carteira.  Wink

Adiciona uma ideia que um dia imagino implementar pra testar...

1. O usuario assina a operacao de compra e venda na maquina dele e manda para a exchange (pode ser browser-based como a wallet do blockchain.info).
2. O servidor registra essa transacao completa (com assinatura)
3. Uma maquina fica lendo um feed dessas transações e exibe um QR code na tela
4. Uma outra maquina do outro lado da sala fica com uma camera apontada para essa tela, lendo os QR Codes (air gap)
5. Essa outra maquina verifica a assinatura e o conteudo da transacao e processa (ou descarta).

Se alguem invadir o servidor, só vai conseguir modificar registros de transacao ou gerar QRs errados... mas a assinatura vai ser invalida...


sr. member
Activity: 315
Merit: 250
March 13, 2014, 10:46:39 PM
#10
Legal o desenho algorista - já pensei em arquiteturas assim mas se o saque de coins for automatico, então não encontrei uma proteção nessa arquitetura sua contra forjar compras/vendas diretamente no server.

Exemplo:
1 Alguem abre uma conta na exchange (possivelmente documentos falsos)
2 Transfere 1 BTC por exemplo pra lá
3 Ganha acesso ao webserver
4 Altera o book order direto no banco retirando todas as ordens de venda e todas de compra e faz as seguintes operacoes:
5 Cadastra uma ordem de venda igual ao valor total de todo o dinheiro disponivel nas contas de cada um
6 Cadastra ordens de compra pra gastar o dinheiro de todo mundo comprando aquele 1 BTC
7 Cadastra uma ordem de compra usando o dinheiro todo e valor do BTC a R$ 0.00000001
8 Cadastra ordens de venda de todos os BTCs em saldo
9 Pede uma retirada do saldo total da conta...


Como para o CronServer todas essas são operações 'validas' de compra e venda  (saldo total de R$ e BTC está valido) ele vai processar as ordens todas e liberar os BTCs...

Você descreveu um ótimo exemplo de ataque que poderia ser implementado com um SQL Injection bem elaborado.
Pensei num cenário de conseguir privileged access mesmo. Basicamente root access.

Mas acredito que na minha arquitetura ele seria barrado no CronServer já na etapa 4 (pois suas operações de exclusão de ordens não estariam conectadas a um token valido de login, necessário para cada usuario alterar as proprias ordens)

Com acesso direto ao BD, se o token estiver no servidor, o atacante pode usar os tokens na geração das ordens.
Então não para nessa etapa. Só seria dificultado se fosse um processo de token externo (um RSA card ou um serviço terceiro) mas é fácil, com acesso total, direcionar o trafego de check desse servico terceiro por um mock que retorna sempre 'OK'.

Caso o invasor altere as ordens diretamente no BD do webserver, ou ainda tente registrar novas ordens (etapa 5,6,7,8), o BD se tornaria diferente da copia incremental presente no cronserver e o sistema inteiro se desativa, acionando o alarme de invasão.

Para a exchange funcionar, voce precisa permitir o usuario alterar as ordens de compra e venda. Se estou simulando essas novas ordens de compra e venda (ou simulando o cancelamento delas) o CronServer vai interpretar como um update do usuario e atualizar sua cópia local.
Então não para aqui também...


Mas caso o invasor consiga forjar tokens de login, e consiga registrar exclusão de ordens e adicionar novas ordens, então ele ainda seria barrado na etapa 6, pois o mesmo BTC não poderia ser vendido mais de uma vez, pois a auditoria automatica é executada antes de cada ordem, e cuidaria disso, impedindo o ataque e bloqueando a conta.

Citei como exemplo 1 BTC colocado a venda mas todas as ordens de compras seriam feitas por valores absurdos (mas válidos) como por exemplo: 0.00000001 BTC por R$ 10.350,00 (o valor total de saldo da conta de um cliente por exemplo).

No final dessa etapa e da etapa 7, a quantidade total de BTC na exchange continua igual a original. A unica diferenca é que todos os BTCs estão concentrados agora em uma única conta de usuário.
Repare que nesse ataque está sendo simulado EXATAMENTE uma operação de mercado... como se todo mundo estivesse vendendo tudo e alguem comprando tudo. Então a nao ser que o CronServer tenha um esquema de circuit-breaker que interrompa inclusive a negociacao do site, todas as transacoes sao validas.

E se ainda assim o cara seja um Hacker Ninja Super Sayajin e consiga burlar esse sistema inteiro, ele ainda esbarraria nos limites de saques automaticos, que fracionam os grandes valores em saques menores transferidos em períodos espaçados de tempo

Se alguem consegue root access, consegue chegar aqui. Sabendo dos limites de saque, o maximo que a pessoa ia conseguir era sair com aquele limite...

Eu não conseguiria invadir o meu sistema, mesmo conhecendo ele em detalhes mínimos.

Acho que agora voce consegue... Smiley


Claro que se você conhecer o dono da exchange, sempre tem uma forma mais tradicional.... Cheesy
hero member
Activity: 882
Merit: 1000
It's got electrolytes
March 13, 2014, 10:37:00 PM
#9
Muito bacana a arquitetura. Eu acrescentaria mais 2 coisas:

1- um firewall dedicado entre o webserver e o cronserver que permite conexões TCP apenas em uma direção (do cronserver para o webserver).
2- colocaria dois níveis de carteiras, uma sem a chave privada que seria usada apenas para conexão com a internet, e outra, fora da internet com conexão apenas para a carteira do primeiro nível via interface de rede dedicada, essa sim contendo as chaves. Assim você isola da internet TOTALMENTE a carteira que contem as chaves, ficando praticamente impossível hackear as carteiras. (com o custo de ter um servidor a mais)

O item 1 não tem como ser implementado pois a ideia é o webserver não saber o IP do cronserver de forma nenhuma, nem mesmo inspecionando os pacotes. Por isso sugeri conexão por VPN e unilateral por SSH redirecionando a porta do BD (MySQL possivelmente).

O item 2 achei uma ideia espetacular, vou adicionar ao projeto arquitetonico, ideia muito boa mesmo, pois evita até um ataque bruto na carteira.  Wink

legendary
Activity: 2296
Merit: 1170
Advertise Here - PM for more info!
March 13, 2014, 10:23:53 PM
#8
Também vale lembrar que o mercado pra exchanges que operam exclusivamente com criptomoedas já está saturado, e operam em nível mundial e não nacional.

O que os brasileiros demandam nesse momento são empresas para atuar primariamente com R$, e pra esse tipo de empresa, tantos exchanges quanto gateways de pagamentos estão com alta demanda.

Também existe a questão da segurança juridica, portanto será preciso de mecanismos que proteja ambos os lados, exchange e usuario.

É preciso pensar também no tempo de aceitação do seu produto, pois para receber depositos será preciso primeiro estabelecer a reputação.

Você pediu pra não falar em segurança dos acessos, mas acho isso o ponto central de qualquer negocio baseado em criptomoedas, e nisso posso te dar uma sugestão de arquitetura.
O ano passado eu projetei esse rascunho abaixo, que seria a minha visão de um exchange seguro (contra roubo de moedas).
É um rascunho bem basico e ainda precisa melhorar muitas coisas, mas deixo como sugestão.

[...]

O legal dessa minha arquitetura é que é praticamente impossível ter acesso as moedas entrando pelo webserver, e o servidor das carteiras (cronserver) poderia ficar em qualquer lugar, inclusive em um datacenter pequeno, não demanda muita internet ou processamento, só precisa ser mantido em segredo e com boa segurança física e logica.
Inclusive no projeto estão previstas as proteções contra depósitos forjados, saques inválidos, saldos fraudulentos, e clonagem de operações de mural.




Muito bacana a arquitetura. Eu acrescentaria mais 2 coisas:

1- um firewall dedicado entre o webserver e o cronserver que permite conexões TCP apenas em uma direção (do cronserver para o webserver).
2- colocaria dois níveis de carteiras, uma sem a chave privada que seria usada apenas para conexão com a internet, e outra, fora da internet com conexão apenas para a carteira do primeiro nível via interface de rede dedicada, essa sim contendo as chaves. Assim você isola da internet TOTALMENTE a carteira que contem as chaves, ficando praticamente impossível hackear as carteiras. (com o custo de ter um servidor a mais)
Pages:
Jump to: