Anton
Мы все под колпаком :)
Vadim
И часто эта переменная стоит?
Vadim
(реально интересно)
Vadim
Эх, для кейлоггера рут не нужен, для снифера не нужен
Vadim
Артем
Вывод - галочка "запомнить" - зло!!!
Артем
Если под одним системным юзером несколько людей, то как нефиг делать. Прописал в автозапуск и любой входящий запускает и кейлоггер и сниф автоматом
Anton
Однозначно не увидет. Т.к. не могут два юзера за одним компом работать в одно и тоже время
Vadim
Я не спец винды, но разве на одной машине одновременно можно несколько юзеров? Сервер не в счет
Артем
Я не спец винды, но разве на одной машине одновременно можно несколько юзеров? Сервер не в счет
А почему нет? Один комп в семье и у каждого свой профиль системный...
Папа/мама/ребенка
Vadim
Vadim
Так не, ну какие тогда нажатия от второго юзера
Vadim
(все всё поняли))
Anton
Блин, но клава одна...
Anton
Разве можно одновременно за одним компом работать?
Артем
Антон, ты не ответил - Вася и Петя входят в систему с персональными учетками или могут юзать одну? Не учетку проги, а учетку компа.
Anton
Предполагаю что одну
Anton
Один человек, но несколько учёток в проге
Артем
Тогда убирай галку нафиг и смотри в сторону шифрования... А лучше вообще плюнь и не трать время ибо изначально ситуация дырявая и незащитимая даже от дурака ))
Anton
И у каждого свой инкапсулированый процесс?
Артем
Если в одной системной учетке могут оказаться разные люди, то любой из них может прописать в автозапуск кейлоггер или троян и этого хватит, чтобы получить все, что угодно про других людей, работающих в этой же учетке.
Это изначально тупиковый вариант защиты )
Артем
Все дальнейшие способы защиты локальных данных любого софта обречены на провал даже от начинающего кулхацкера
Anton
Тогда что либо шифровать безсмыслено
Anton
Логично, а то я уж подумал... Как парное программирование :)
Артем
Шифрование помогает только там, где можно получить сохраненные данные (скопировать файлы), но не там, где можно "внедриться" в область выполнения кода
Anton
Не, там такого не будет
Vadim
Пиши пароль в файлик на рабочем столе
Vadim
И юзай его, делая запросы по http
Vadim
На каждый запрос, желательно через бесплатный прокси
Vadim
Обожаю когда кидаються в крайности)
Anton
Я для себя уже вариант придумал. (В ходе обсуждения) но для меня дискуссия была познавательная
Vadim
Vadim
И хорошо бы озвучить, обещаю тапками кидаться больше не будем)
Артем
И хорошо бы озвучить, обещаю тапками кидаться больше не будем)
да вроде тапки-то были тряпочные, до сандалей и резиновых дело не дошло, человек понятливый попался =))) в особенно упертых мы кирзачами швыряемся
Vadim
IfonYa
подскажите. запускаю окно через loadURL, удаленного сайта. получается, что доступа к render процессу нет. можно ли как-либо встроить скрипт в render. или подключить модуль node из main процесса. executeJavaScript сразу отметаем, поскольку кода многа с подключением модулей.
Артем
насколько я понял - это что-то типа вашего "executeJavaScript" только из файла
Артем
подскажите. запускаю окно через loadURL, удаленного сайта. получается, что доступа к render процессу нет. можно ли как-либо встроить скрипт в render. или подключить модуль node из main процесса. executeJavaScript сразу отметаем, поскольку кода многа с подключением модулей.
mainWindow = new BrowserWindow({
webPreferences: {
preload: path.join(__dirname, 'renderer.js')
}
});
IfonYa
насколько я понял - это что-то типа вашего "executeJavaScript" только из файла
спс. голова уже деревянная. под носом ответ был. читал же. совсем из головы вылетело.
Anton
А... Та на здоровье, я же всегда 'за' когда она по делу.
Anton
В локалсторедже будет две записи. Первая запись с текущим токеном юзера, вторая userSettings в котором будет лежать объект с настройками всех юзеров. Key - токен юзера: object - сами настройки. И соответственно буду брать настройки по текущему токену.
Артем
юзер перелогинился и его токен поменялся, настройки тю-тю =(
Артем
если авторизация по OAuth - то в принципе по токену всегда можно получить инфу юзера, как минимум логин... может лучше в настройках по нему разделять?
Anton
Все же есть мысль видоизменять токен, что бы не хранить в открытом виде. Достаточно примитивно. Куда то поставить рандомный текст, к примеру. Пока ещё не решил как
Anton
юзер перелогинился и его токен поменялся, настройки тю-тю =(
Его текущий токен изменился. Юзер сеттингс никуда не пропадают
Артем
Его текущий токен изменился. Юзер сеттингс никуда не пропадают
не понимаю =)))
- юзер vasya залогинился и получил токен aaaaa
- записались его настройки в сеттингсах по токену aaaaa
- закончил работу и разлогинился, токен удалился (вопрос сразу, как его настройки сохранятся, по старому токену?)
- утром юзер vasya снова залогинился и получил токен bbbbb (второй вопрос, как система узнает, что юзер vasya в прошлый раз юзал токен aaaaa и загрузит настройки из него)
Anton
если авторизация по OAuth - то в принципе по токену всегда можно получить инфу юзера, как минимум логин... может лучше в настройках по нему разделять?
Может не понятно написал.
Localstote:
currentToken: "TokenUser1",
userSettings: {
TokenUser1: some data,
TokenUser2: some data
}
Артем
если память не подводит, обычно токен - это base64 от какого-то набора данных, среди которой есть всегда логин юзера
Anton
не понимаю =)))
- юзер vasya залогинился и получил токен aaaaa
- записались его настройки в сеттингсах по токену aaaaa
- закончил работу и разлогинился, токен удалился (вопрос сразу, как его настройки сохранятся, по старому токену?)
- утром юзер vasya снова залогинился и получил токен bbbbb (второй вопрос, как система узнает, что юзер vasya в прошлый раз юзал токен aaaaa и загрузит настройки из него)
У меня бэк всегда отдает один и тот же токен
Артем
Может не понятно написал.
Localstote:
currentToken: "TokenUser1",
userSettings: {
TokenUser1: some data,
TokenUser2: some data
}
все понятно написано, не поняли сути... токен юзера при перелогинивании МЕНЯЕТСЯ... и сегодня Вася с токеном aaaa, завтра получит токен bbb, а послезавтра будет ababa
Артем
У меня бэк всегда отдает один и тот же токен
ээээ... смысле токена тогда??? если он не изменяется при перелогинивании, то это не дыра, это просто дырища =))) токен авторизации - должен меняться при каждом входе, в идеале вообще иметь "время жизни"
Anton
У меня бэк всегда отдает один и тот же токен
А вот и нет. Соврал. В токене есть айдишник юзера.
Anton
Меняем токен в схеме на айди и все поедет
Артем
вот по ID-шнику и делайте в сторедже секции =)
Артем
а я про что и говорю =))) а то "токен да токен" =)))
не, в этом чате совсем "без тапок" не бывает ;)
su
А я не согласен,
Я считаю, что браузер в electron - это чистый view, да со своими артефактами в виде localStorage, причем лучше будет сделать его stateless, ничего не хранить во view, все данные получать извне, по сети, а хранить тоже во все, на файловом хранилище, при этом, не нужно заморачиваться на шифрование, а использовать средства операционной системы, вот и все, не усложнять все до невозможности, браузер - не операционная система (не crome OS, пока что), так что не надо делать из мухи слона, храните все в json, настройки пользователя шифровать не обязательно, если что там секретное, просто не храните, загружайте по сети и нигде не сохраняйте.
По авторизации. есть много разных схем, включая токены сессии, временные токены для получения обновления постоянного токена, в общем, схем множество. все схемы обьединяет то, что они не пресистентны, то есть зайдя один раз по токену, повторить это уже не удастся, поэтому теряется смысл его кражи, как и использования в качестве защищенного ключа хранилища. А токен обновления, можно спокойно хранить в профиле пользователя, если надо, все равно в схеме с авторизацией по логину и паролю, этот токен получается заново и служит для обновления постоянного токена (который нигде не хранится, кроме памяти), и использовать файловое хранилише sqlite, на диске пользователя, а шифрование использовать со стороны внешшнего сервера авторизации, то есть на клиенте хранить ключ дешифрования, и использовать ассимметричное шифрование, на эллиптических кривых, если уж у кого-то встала такая задача., но как я думаю, все это избыточные схемы.
Самое главное,
- view = stateless
- шифрование - только данные, только на удаленном сервере (при необходмости)
- локально хранить в sqlite, вне приложения,
- не хранить постоянные токены, использовать авторизацию по паролю, а для ресурсов - авторизацию на основе временного токена, обновляемого по мере использования
Артем
А я не согласен,
Я считаю, что браузер в electron - это чистый view, да со своими артефактами в виде localStorage, причем лучше будет сделать его stateless, ничего не хранить во view, все данные получать извне, по сети, а хранить тоже во все, на файловом хранилище, при этом, не нужно заморачиваться на шифрование, а использовать средства операционной системы, вот и все, не усложнять все до невозможности, браузер - не операционная система (не crome OS, пока что), так что не надо делать из мухи слона, храните все в json, настройки пользователя шифровать не обязательно, если что там секретное, просто не храните, загружайте по сети и нигде не сохраняйте.
По авторизации. есть много разных схем, включая токены сессии, временные токены для получения обновления постоянного токена, в общем, схем множество. все схемы обьединяет то, что они не пресистентны, то есть зайдя один раз по токену, повторить это уже не удастся, поэтому теряется смысл его кражи, как и использования в качестве защищенного ключа хранилища. А токен обновления, можно спокойно хранить в профиле пользователя, если надо, все равно в схеме с авторизацией по логину и паролю, этот токен получается заново и служит для обновления постоянного токена (который нигде не хранится, кроме памяти), и использовать файловое хранилише sqlite, на диске пользователя, а шифрование использовать со стороны внешшнего сервера авторизации, то есть на клиенте хранить ключ дешифрования, и использовать ассимметричное шифрование, на эллиптических кривых, если уж у кого-то встала такая задача., но как я думаю, все это избыточные схемы.
Самое главное,
- view = stateless
- шифрование - только данные, только на удаленном сервере (при необходмости)
- локально хранить в sqlite, вне приложения,
- не хранить постоянные токены, использовать авторизацию по паролю, а для ресурсов - авторизацию на основе временного токена, обновляемого по мере использования
тут как бы никто и не против данной схемы и в принципе все про удаленное хранения и говорили, только иногда случается так, что есть определенные рамки, в которые нужно вписаться... и вариант "если не так, как правильно, то вообще никак" не подходит =)
su
Но опять же. Это не спасет от того что писал random
он слишком много чего отписал, короче я не понял, от чего не спасет предложенная схема, и потом я написал минимально простую схему для приложения с мультиюзерами
Anton
От кейлогера и просмотра сетевых запросов. Но мне это и не нужно. У меня нет там данных кредиток...
Артем
От кейлогера и просмотра сетевых запросов. Но мне это и не нужно. У меня нет там данных кредиток...
оччень зря, надо с юзеров такие данные собирать и потом использовать в личных бесстыжих целях! =)
su
От кейлогера и просмотра сетевых запросов. Но мне это и не нужно. У меня нет там данных кредиток...
просмотр сетевых запросов не получится, если у тебя https, и ты не подмениваешь сертификаты
su
от кейлоггера защищаются выключением питания, потому что винда сама кейлоггер, теперь еще и убунта, и вообще все, включая маки, имеется ввиду нештатные отладчики, но для этого нужны права администратора, а если вас уже взломали, то вообще думать о защите приложения в такой среде - это удел самых отъявленных помешанных на безопасности гиков, по идее
su
блажен кто верует, удачи
Артем
для того, чтобы гарантировано защититься, берете паяльник, микросхемы, программируете микрочипы, свою операционку и т.д. - да и то "термальный криптоанализатор" любые файрволы обойдет ;)
Vadim
для того, чтобы гарантировано защититься, берете паяльник, микросхемы, программируете микрочипы, свою операционку и т.д. - да и то "термальный криптоанализатор" любые файрволы обойдет ;)
Первое правило безопасности: не изобретай свое шифрование. Отсюда, вероятно, творение всей жизни будет одной дырой)
su
Что проверил, протоколы https ломаются только в локальной сети
su
тогда ты не вкурил, вообще, о чем я толкую, прежде чем ваставлять свои 5 копеек. я говорил о взаимодействии с удаленным серверои, и ничего там не взламывается, уверяю тебя
Vadim
Я думаю тему пора закрывать? Хорошо? Желающие го в отдельный чат.
su
su
я же говорил в контексте своей модели приложения, а не локальной, там пост есть
Vadim
Ребят, хватит, это уже явный оффтоп
Bohdan
Ребят, подкажите плиз, где хранить токен? Я так понимаю бэк не может проставить куку в случае с электроном
Andrey
Bohdan
почему не может?
хз, пробовали - если собирать просто аппку - все ок, если электрон - куки нет
Andrey
хз, пробовали - если собирать просто аппку - все ок, если электрон - куки нет
если запрос из рендерера, емнип все пашет из коробки, ровным счетом, как в браузере