SS
шарим в 1pass или lastpass, когда надо "быстро и грязно" - в Слаке, потом сообщение стираем. "дай ключ - на! - удалил"
а инженеры слака сидят и ржут 😂
Size: a a a
2020 December 09
AR
а инженеры слака сидят и ржут 😂
вместе с инженерами saleforce ;)
AR
ваще есть надежный мессенджер. tox называется
С
ваще есть надежный мессенджер. tox называется
Я как-то раз попытался его скачать, stable version, получил 500 на их сайте и решил, что если это стабильная версия, то какая же нестабильная? И передумал им пользоваться.
A
Я как-то раз попытался его скачать, stable version, получил 500 на их сайте и решил, что если это стабильная версия, то какая же нестабильная? И передумал им пользоваться.
зато ни один пароль не утек, правда?
С
зато ни один пароль не утек, правда?
ну да
SS
С
Решалось это так - пароль отправляется в архиве с паролем по почте, а пароль к архиву - в личке в слаке
A
Решалось это так - пароль отправляется в архиве с паролем по почте, а пароль к архиву - в личке в слаке
ого, извращенцы
IV
Товарищи, у меня к вам внезапный вопрос - какие средства вы (или ваше безопасники) считают уместными для передачи каких-либо конфиденциальных данных? Начиная с документиков и заканчивая, скажем, какими-нибудь паролями\конфигами с паролями. Периодически же надо что нибудь такое коллеге переслать или куда нибудь на внешку, и становится немного больно и неоднозначно.
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
GL
нужен gpg для такого
GL
и заранее встретиться обменяться ключами офк
D
service as a service?
AR
service as a service?
надо подумать над этим )
D
такой мета-сервис
M
ну вон яндекс подписка и сбер
AR
ну вон яндекс подписка и сбер
не, ну это уже не кажется странным
A
что не может быть as a service? )
товарищ майор