Topic: Как защищать приватные ключи на сервере? - page 2. (Read 1150 times)
От кого зашищать и зачем, не хватает паролей, кодировки. Создавай отдельный сервер, может поможет на первое время.
Поддерживаю, механика такая:
1. Во внутренней сети добавить спец компьютер, имеющий доступ к приватным ключам
2. На нем запущена специальная программа, умеющая подписывать транзакции
3. Доступ к этому компьютеру только по специальному протоколу и одному открытому порту. Программа, которая имеет к нему доступ закрытая - т е написана вами и не имеет в свободном доступе исходников
Профит: если веб сервер будет взломан, хакеры получат только закрытую программу, а не приватные ключи
1. Во внутренней сети добавить спец компьютер, имеющий доступ к приватным ключам
2. На нем запущена специальная программа, умеющая подписывать транзакции
3. Доступ к этому компьютеру только по специальному протоколу и одному открытому порту. Программа, которая имеет к нему доступ закрытая - т е написана вами и не имеет в свободном доступе исходников
Профит: если веб сервер будет взломан, хакеры получат только закрытую программу, а не приватные ключи
разбиваю все ваши теории.
Если будет взломан веб-сервер, взломавшему ничто не будет мешать сделать кучу поддельных запросов на перевод/вывод и все... как таковые приватные ключи и не будут его интересовать.
Но направление верное - дерзайте, дерзайте )))
Мне не понятно зачем вы хотите приватные ключи от кошельков держать на веб сервере?
Я бы для кошельков завел другой выделенный сервер во внутренней сети. Но и это надо лишь в том случае если вы делаете биржу или обменник, а для простого интернет магазина можно обойтись сторонним API, например с http://blockchain.info/ и через него узнавать о поступлении средств на ваш счет.
Я бы для кошельков завел другой выделенный сервер во внутренней сети. Но и это надо лишь в том случае если вы делаете биржу или обменник, а для простого интернет магазина можно обойтись сторонним API, например с http://blockchain.info/ и через него узнавать о поступлении средств на ваш счет.
Поддерживаю, механика такая:
1. Во внутренней сети добавить спец компьютер, имеющий доступ к приватным ключам
2. На нем запущена специальная программа, умеющая подписывать транзакции
3. Доступ к этому компьютеру только по специальному протоколу и одному открытому порту. Программа, которая имеет к нему доступ закрытая - т е написана вами и не имеет в свободном доступе исходников
Профит: если веб сервер будет взломан, хакеры получат только закрытую программу, а не приватные ключи
Мне не понятно зачем вы хотите приватные ключи от кошельков держать на веб сервере?
Я бы для кошельков завел другой выделенный сервер во внутренней сети. Но и это надо лишь в том случае если вы делаете биржу или обменник, а для простого интернет магазина можно обойтись сторонним API, например с http://blockchain.info/ и через него узнавать о поступлении средств на ваш счет.
Я бы для кошельков завел другой выделенный сервер во внутренней сети. Но и это надо лишь в том случае если вы делаете биржу или обменник, а для простого интернет магазина можно обойтись сторонним API, например с http://blockchain.info/ и через него узнавать о поступлении средств на ваш счет.
Поддерживаю, для всего ценного, сервер на FreeBSD, а уже за ним на винде все развернуто , если под FreeBSD не написать
. Ибо сначала идут танки, а за ними пехота. (ну по крайней мере такая тактика была во времена ВОВ когда еще "Корнетов" не было) На FreeBSD все серьезно, безопасность превыше всего, все порты по умолчанию закрыты.
это бесполезно тут как бабка надвое гадала . все зависит от контроля компа .вирусы не хапайте и все будет нормик)))
Никак вы не защитите.
Если вам надо подписывать транзакции автоматом - то приватный ключ
в какой-то момент есть в открытом виде.
Всякие разные варианты с аппаратными кошельками сводятся к тому,
что должен присутствовать живой оператор. А это, извините, уже не серверное решение.
Частичным решением может быть вариант с мультиподписью (это не обязательно
мультисигнатурный биткойн-адрес, я общий концепт рассказываю) - есть сервер
на котором ключи не хранятся. Есть еще два-три бэкенд сервера каждый из которых
не имеет полного доступа, но в сумме они могут подписать транзакцию.
Эти сервера физически разнесены и управляются разными людьми. Если
исключить возможность сговора - то может получиться. Но на мой взгляд это
излишнее усложнение.
Более-менее рабочим решением является просто холодный кошелек - бабки
у босса, а приватный ключ только у него (или лучше на мультисигнатурном кошельке
у трех учредителей). На сервере - только небольшая сумма, за которую отвечает админ
своей башкой. Если надо пополнить горячий кошелек сервера - учредители туда переводят.
Если на сервере скапливается много бабла - оно переводится в "холодный кошелек"
Если вам надо подписывать транзакции автоматом - то приватный ключ
в какой-то момент есть в открытом виде.
Всякие разные варианты с аппаратными кошельками сводятся к тому,
что должен присутствовать живой оператор. А это, извините, уже не серверное решение.
Частичным решением может быть вариант с мультиподписью (это не обязательно
мультисигнатурный биткойн-адрес, я общий концепт рассказываю) - есть сервер
на котором ключи не хранятся. Есть еще два-три бэкенд сервера каждый из которых
не имеет полного доступа, но в сумме они могут подписать транзакцию.
Эти сервера физически разнесены и управляются разными людьми. Если
исключить возможность сговора - то может получиться. Но на мой взгляд это
излишнее усложнение.
Более-менее рабочим решением является просто холодный кошелек - бабки
у босса, а приватный ключ только у него (или лучше на мультисигнатурном кошельке
у трех учредителей). На сервере - только небольшая сумма, за которую отвечает админ
своей башкой. Если надо пополнить горячий кошелек сервера - учредители туда переводят.
Если на сервере скапливается много бабла - оно переводится в "холодный кошелек"
Железные кошельки с API и подтверждением по PIN-коду, вставляются в raspberry pi, pi в vpn до сервера обработки транзакций на котором raw транзакции, рядом мальчик с дэшбордом запрошенных транзакций подтверждает вводом пин-кода каждую транзакцию. + (дневной) лимит на железные кошельки. Такой себе обменник из 90х Пары хмурых ребят со стволами на входе не хватает
Пары хмурых ребят со стволами на входе не хватает
да много разных способов есть - и мультиподписи и отдельная железяка с нестандартным апи и железом (допустим не tcp-ip) да и банальное разделение на очень холодные кошельки и очень горячие
Я худею над каментами... рар архив, блокчейниефо... Даж не знаю смеяться или плакать над такой бестпрактикс в ветке русских кодеров?
Просто из тех кто реально разбираются в вопросе - никто не счёл нужным зайти и отписаться здесь на этот вопрос. Вот потому и пишут те кто реально слабо представляю себе как решить проблему. Тут половина форума таких комментариев. 
Я худею над каментами... рар архив, блокчейниефо... Даж не знаю смеяться или плакать над такой бестпрактикс в ветке русских кодеров?
Что скажите о таком https://bitcore.io/guides/wallet-service/Не знаю. Меня стандартная кора устраивает.
Я худею над каментами... рар архив, блокчейниефо... Даж не знаю смеяться или плакать над такой бестпрактикс в ветке русских кодеров?
Что скажите о таком https://bitcore.io/guides/wallet-service/
Я худею над каментами... рар архив, блокчейниефо... Даж не знаю смеяться или плакать над такой бестпрактикс в ветке русских кодеров?
Мне не понятно зачем вы хотите приватные ключи от кошельков держать на веб сервере?
Я бы для кошельков завел другой выделенный сервер во внутренней сети. Но и это надо лишь в том случае если вы делаете биржу или обменник, а для простого интернет магазина можно обойтись сторонним API, например с http://blockchain.info/ и через него узнавать о поступлении средств на ваш счет.
Я бы для кошельков завел другой выделенный сервер во внутренней сети. Но и это надо лишь в том случае если вы делаете биржу или обменник, а для простого интернет магазина можно обойтись сторонним API, например с http://blockchain.info/ и через него узнавать о поступлении средств на ваш счет.
Приватные ключи смысла шифровать я не вижу - нужно построить грамотно веб-приложение без дыр и закрыть все ненужные порты,
сюда же закрыть порт на сервисы криптовалютных кошельков.
Следить за обновлениями софта.
Как вариант - можно вообще биткоин кошелек вынести на отдельный сервак и построить АПИ, которое будет контролировать
нетипичные запросы, например вывод всей суммы баланса на какой-то из криптоадресов.
Вести полный или максимальный аудит запросов, холдить вывод крипты на первых порах или в зависимости от сумм.
сюда же закрыть порт на сервисы криптовалютных кошельков.
Следить за обновлениями софта.
Как вариант - можно вообще биткоин кошелек вынести на отдельный сервак и построить АПИ, которое будет контролировать
нетипичные запросы, например вывод всей суммы баланса на какой-то из криптоадресов.
Вести полный или максимальный аудит запросов, холдить вывод крипты на первых порах или в зависимости от сумм.
Привет всем.
Интересует такой вопрос. Как надежно защищать приватные ключи на сервере некого сервиса, допустим web кошелек? С одной стороны нужно хорошо их зашифровать, а с другой стороны их нужно использовать часто и, что важнее, оперативно по запросу.
Какие технические решения можно и/или нужно использовать? Best practices?
winrar архив под паролемИнтересует такой вопрос. Как надежно защищать приватные ключи на сервере некого сервиса, допустим web кошелек? С одной стороны нужно хорошо их зашифровать, а с другой стороны их нужно использовать часто и, что важнее, оперативно по запросу.
Какие технические решения можно и/или нужно использовать? Best practices?
От кого защищать-то?
Кто будет сторожить сторожей?
Привет всем.
Интересует такой вопрос. Как надежно защищать приватные ключи на сервере некого сервиса, допустим web кошелек? С одной стороны нужно хорошо их зашифровать, а с другой стороны их нужно использовать часто и, что важнее, оперативно по запросу.
Какие технические решения можно и/или нужно использовать? Best practices?
Интересует такой вопрос. Как надежно защищать приватные ключи на сервере некого сервиса, допустим web кошелек? С одной стороны нужно хорошо их зашифровать, а с другой стороны их нужно использовать часто и, что важнее, оперативно по запросу.
Какие технические решения можно и/или нужно использовать? Best practices?
Jump to: