Как защищать приватные ключи на сервере?

[SolidBit]

Привет всем.

Интересует такой вопрос. Как надежно защищать приватные ключи на сервере некого сервиса, допустим web кошелек? С одной стороны нужно хорошо их зашифровать, а с другой стороны их нужно использовать часто и, что важнее, оперативно по запросу.

Какие технические решения можно и/или нужно использовать? Best practices?

[fruit]

Кто будет сторожить сторожей?

[Coin-1]

От кого защищать-то?

[Tyrion.L]

Привет всем.

Интересует такой вопрос. Как надежно защищать приватные ключи на сервере некого сервиса, допустим web кошелек? С одной стороны нужно хорошо их зашифровать, а с другой стороны их нужно использовать часто и, что важнее, оперативно по запросу.

Какие технические решения можно и/или нужно использовать? Best practices?

winrar архив под паролем

[Uniex]

Приватные ключи смысла шифровать я не вижу - нужно построить грамотно веб-приложение без дыр и закрыть все ненужные порты,
сюда же закрыть порт на сервисы криптовалютных кошельков.
Следить за обновлениями софта.

Как вариант - можно вообще биткоин кошелек вынести на отдельный сервак и построить АПИ, которое будет контролировать
нетипичные запросы, например вывод всей суммы баланса на какой-то из криптоадресов.

Вести полный или максимальный аудит запросов, холдить вывод крипты на первых порах или в зависимости от сумм.

[Jaga-Jaga]

Мне не понятно зачем вы хотите приватные ключи от кошельков держать на веб сервере?
Я бы для кошельков завел другой выделенный сервер во внутренней сети. Но и это надо лишь в том случае если вы делаете биржу или обменник, а для простого интернет магазина можно обойтись сторонним API, например с http://blockchain.info/ и через него узнавать о поступлении средств на ваш счет.

[kzv]

Я худею над каментами... рар архив, блокчейниефо... Даж не знаю смеяться или плакать над такой бестпрактикс в ветке русских кодеров?

[websalamander]

Я худею над каментами... рар архив, блокчейниефо... Даж не знаю смеяться или плакать над такой бестпрактикс в ветке русских кодеров?

Что скажите о таком https://bitcore.io/guides/wallet-service/

[kzv]

Я худею над каментами... рар архив, блокчейниефо... Даж не знаю смеяться или плакать над такой бестпрактикс в ветке русских кодеров?

Что скажите о таком https://bitcore.io/guides/wallet-service/

Не знаю. Меня стандартная кора устраивает.

[TwinTURBO2]

Я худею над каментами... рар архив, блокчейниефо... Даж не знаю смеяться или плакать над такой бестпрактикс в ветке русских кодеров?

Просто из тех кто реально разбираются в вопросе - никто не счёл нужным зайти и отписаться здесь на этот вопрос. Вот потому и пишут те кто реально слабо представляю себе как решить проблему. Тут половина форума таких комментариев.

[ToTheMoonClub]

да много разных способов есть - и мультиподписи и отдельная железяка с нестандартным апи и железом (допустим не tcp-ip) да и банальное разделение на очень холодные кошельки и очень горячие

[olegvg]

Железные кошельки с API и подтверждением по PIN-коду, вставляются в raspberry pi, pi в vpn до сервера обработки транзакций на котором raw транзакции, рядом мальчик с дэшбордом запрошенных транзакций подтверждает вводом пин-кода каждую транзакцию. + (дневной) лимит на железные кошельки. Такой себе обменник из 90х Пары хмурых ребят со стволами на входе не хватает

[amaclin1]

Никак вы не защитите.
Если вам надо подписывать транзакции автоматом - то приватный ключ
в какой-то момент есть в открытом виде.
Всякие разные варианты с аппаратными кошельками сводятся к тому,
что должен присутствовать живой оператор. А это, извините, уже не серверное решение.

Частичным решением может быть вариант с мультиподписью (это не обязательно
мультисигнатурный биткойн-адрес, я общий концепт рассказываю) - есть сервер
на котором ключи не хранятся. Есть еще два-три бэкенд сервера каждый из которых
не имеет полного доступа, но в сумме они могут подписать транзакцию.
Эти сервера физически разнесены и управляются разными людьми. Если
исключить возможность сговора - то может получиться. Но на мой взгляд это
излишнее усложнение.

Более-менее рабочим решением является просто холодный кошелек - бабки
у босса, а приватный ключ только у него (или лучше на мультисигнатурном кошельке
у трех учредителей). На сервере - только небольшая сумма, за которую отвечает админ
своей башкой. Если надо пополнить горячий кошелек сервера - учредители туда переводят.
Если на сервере скапливается много бабла - оно переводится в "холодный кошелек"

[direktormira]

это бесполезно тут как бабка надвое гадала . все зависит от контроля компа .вирусы не хапайте и все будет нормик)))

[poddubnuy]

Мне не понятно зачем вы хотите приватные ключи от кошельков держать на веб сервере?
Я бы для кошельков завел другой выделенный сервер во внутренней сети. Но и это надо лишь в том случае если вы делаете биржу или обменник, а для простого интернет магазина можно обойтись сторонним API, например с http://blockchain.info/ и через него узнавать о поступлении средств на ваш счет.

Поддерживаю, для всего ценного, сервер на FreeBSD, а уже за ним на винде все развернуто , если под FreeBSD не написать . Ибо сначала идут танки, а за ними пехота. (ну по крайней мере такая тактика была во времена ВОВ когда еще "Корнетов" не было) На FreeBSD  все серьезно, безопасность превыше всего, все порты по умолчанию закрыты.

[Vtools]

Мне не понятно зачем вы хотите приватные ключи от кошельков держать на веб сервере?
Я бы для кошельков завел другой выделенный сервер во внутренней сети. Но и это надо лишь в том случае если вы делаете биржу или обменник, а для простого интернет магазина можно обойтись сторонним API, например с http://blockchain.info/ и через него узнавать о поступлении средств на ваш счет.

Поддерживаю, механика такая:
1. Во внутренней сети добавить спец компьютер, имеющий доступ к приватным ключам
2. На нем запущена специальная программа, умеющая подписывать транзакции
3. Доступ к этому компьютеру только по специальному протоколу и одному открытому порту. Программа, которая имеет к нему доступ закрытая - т е написана вами и не имеет в свободном доступе исходников

Профит: если веб сервер будет взломан, хакеры получат только закрытую программу, а не приватные ключи

[virtus]

Поддерживаю, механика такая:
1. Во внутренней сети добавить спец компьютер, имеющий доступ к приватным ключам
2. На нем запущена специальная программа, умеющая подписывать транзакции
3. Доступ к этому компьютеру только по специальному протоколу и одному открытому порту. Программа, которая имеет к нему доступ закрытая - т е написана вами и не имеет в свободном доступе исходников

Профит: если веб сервер будет взломан, хакеры получат только закрытую программу, а не приватные ключи

разбиваю все ваши теории.
Если будет взломан веб-сервер, взломавшему ничто не будет мешать сделать кучу поддельных запросов на перевод/вывод и все... как таковые приватные ключи и не будут его интересовать.
Но направление верное - дерзайте, дерзайте )))

[criptoguruBEST]

От кого зашищать и зачем, не хватает паролей, кодировки. Создавай отдельный сервер, может поможет на первое время. 

[amaclin1]

разбиваю все ваши теории.
Если будет взломан веб-сервер, взломавшему ничто не будет мешать сделать кучу поддельных запросов на перевод/вывод и все... как таковые приватные ключи и не будут его интересовать.

+1

[ferumflex]

Даже если будет оператор, как оператору вычислить что этот запрос сформировал пользователь и у него есть эти деньги, либо же хакер себе накрутил в базе +1000000?