SG
красиво!
Гугл прислал письмо, что после 21го июня в по истечении двух лет удалит файлы, которые вышли за рамки лимита.
Это ведь они так намекают, что пора бы убрать свои фоточки с их сервиса, верно?
Size: a a a
2020 December 09
D
O
Товарищи, у меня к вам внезапный вопрос - какие средства вы (или ваше безопасники) считают уместными для передачи каких-либо конфиденциальных данных? Начиная с документиков и заканчивая, скажем, какими-нибудь паролями\конфигами с паролями. Периодически же надо что нибудь такое коллеге переслать или куда нибудь на внешку, и становится немного больно и неоднозначно.
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
A
Товарищи, у меня к вам внезапный вопрос - какие средства вы (или ваше безопасники) считают уместными для передачи каких-либо конфиденциальных данных? Начиная с документиков и заканчивая, скажем, какими-нибудь паролями\конфигами с паролями. Периодически же надо что нибудь такое коллеге переслать или куда нибудь на внешку, и становится немного больно и неоднозначно.
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
Я как-то задавал тут этот вопрос. Не могу найти ветку. Меня люто коробило, что порой даже от адекватных людей прилетает форвард длиннющей переписки в почте со всеми кредами. И мне казалось что сервис, который бы позволял просто делиться и управлять доступами был бы полезен. Я даже провел некий кастдев… и понял что люди проблему просто не хотят даже признавать 🙂
VS
Товарищи, у меня к вам внезапный вопрос - какие средства вы (или ваше безопасники) считают уместными для передачи каких-либо конфиденциальных данных? Начиная с документиков и заканчивая, скажем, какими-нибудь паролями\конфигами с паролями. Периодически же надо что нибудь такое коллеге переслать или куда нибудь на внешку, и становится немного больно и неоднозначно.
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
Корпораты в последнее время шлют письма с архивами с паролями.
Пароль приходит отдельно от письма, либо в мессенджерах либо по СМС.
Пароль приходит отдельно от письма, либо в мессенджерах либо по СМС.
O
Корпораты в последнее время шлют письма с архивами с паролями.
Пароль приходит отдельно от письма, либо в мессенджерах либо по СМС.
Пароль приходит отдельно от письма, либо в мессенджерах либо по СМС.
Ну вот меня коробит даже от метода "вот тебе архив, в следующем письме пароль", а пароль там словарный и близок к "123123"
O
Реальная история месячной давности:(
Т
Данные по FTP передаете, а пароль в письме отправляете, изи)
VS
Ну вот меня коробит даже от метода "вот тебе архив, в следующем письме пароль", а пароль там словарный и близок к "123123"
Согласен.
Но еще в начале года слали просто документы с паролем в этом письме )
Но еще в начале года слали просто документы с паролем в этом письме )
A
у корпоратов мохровых наверняка есть сервисы типа секюрных обменников с ключами сертами и т.д. Но я не видел 🙂
DN
Товарищи, у меня к вам внезапный вопрос - какие средства вы (или ваше безопасники) считают уместными для передачи каких-либо конфиденциальных данных? Начиная с документиков и заканчивая, скажем, какими-нибудь паролями\конфигами с паролями. Периодически же надо что нибудь такое коллеге переслать или куда нибудь на внешку, и становится немного больно и неоднозначно.
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
Если бы у вас был инструмент, который позволяет небольшими движениями осуществлять шифрование пейлоада с передачей ключа отдельно неким стандартным путем с подтверждением личности получателя ключа, а пейлоад бы ходил так, как вам удобно. Ну то есть флоу был бы "зашифруй для вот этих получателей", потом зашифрованный пейлоад вы отправляете так как вам удобно (хоть почтой, хоть чем), а на стороне получателя этот получатель бы верифицировался неким сервисом на предмет того, что он тот, за кого себя выдает, после чего сервис отдавал бы ему ключ для расшифровки и собственно файлик бы расшифровывался.
Данные бы никогда не встречались с ключем в транзите, можно не доверять каналу передачи, да и хранилке ключей на предмет того, что она данные украдет, все равно у нее пейлоада нет, а просто ключи от каких-то идентификаторов и сами ключи были бы строго одноразовыми и не требовался бы предъобмен ими, а не как в gpg.
Подумали бы вы над использованием такой системы? Есть ли у вас необходимость в подобном? Переживаете ли вы от того, что в почте все почти в открытом виде путешествует, а мессенджеры и всякие дропбоксы видят пейлоад?
Данные почтой или любым мессенджером под паролем, а пароли через корпоративный Lastpass, но честно говоря у него интерфейс ни разу не человечный.
O
у корпоратов мохровых наверняка есть сервисы типа секюрных обменников с ключами сертами и т.д. Но я не видел 🙂
и я не видел
M
Ну вот меня коробит даже от метода "вот тебе архив, в следующем письме пароль", а пароль там словарный и близок к "123123"
Ну так пароль не в письме нужно посылать, а другим способом
Да и лучше делить на две части по разным каналам. Но удобного способа для этого и правда нет
Да и лучше делить на две части по разным каналам. Но удобного способа для этого и правда нет
VS
у корпоратов мохровых наверняка есть сервисы типа секюрных обменников с ключами сертами и т.д. Но я не видел 🙂
Ща узнаем у махровых корпоратов.
Вопрос в том, что они общаются с внешним миром, которых не всегда можно включить в их систему.
Вопрос в том, что они общаются с внешним миром, которых не всегда можно включить в их систему.
A
Ну так пароль не в письме нужно посылать, а другим способом
Да и лучше делить на две части по разным каналам. Но удобного способа для этого и правда нет
Да и лучше делить на две части по разным каналам. Но удобного способа для этого и правда нет
имхо человек не должен придумывать пароль. Это всегда путь к пиздецу
O
Данные почтой или любым мессенджером под паролем, а пароли через корпоративный Lastpass, но честно говоря у него интерфейс ни разу не человечный.
норм способ, но там как будто бы много телодвижений + не отправишь никому наружу + непонятно как контролировать кто в итоге открыл. Адресно шарить надо? И не понятно что делать если это не 1-1 данные, а на нескольких людей
M
есть самонаписаный сервис,
и есть gpg и немношк платного 1password
и есть gpg и немношк платного 1password
Т
Вы прикаклываетесь?
Работал в финансовой сфере с банками, все важное по FTP в папочку кладешь и пароль передаешь как удобно. Доступ к FTP только у нескольких человек или каждому свою папку
Работал в финансовой сфере с банками, все важное по FTP в папочку кладешь и пароль передаешь как удобно. Доступ к FTP только у нескольких человек или каждому свою папку
O
Ну так пароль не в письме нужно посылать, а другим способом
Да и лучше делить на две части по разным каналам. Но удобного способа для этого и правда нет
Да и лучше делить на две части по разным каналам. Но удобного способа для этого и правда нет
а хотелось бы удобный способ?