Тогда вычеркните этот пункт)
Остальные остаются. И то, что вы не пользуетесь онлайн-сервисами, вовсе не означает, что ними за вас не воспользуется кто-то другой.
В ресторанах всегда требуете, чтобы снятие с карты происходило при вас? Всегда внимательно смотрите на терминал на кассе или в руках официанта на предмет доустановки накладок-снифферов на щель считывателя?
Ну и т.п. Подтверждение транзакции по СМС в таких случаях спасает, но несет некоторый геморрой, да и редкие банки такое поддерживают. Частично спасает СМС-информирование плюс дневной лимит и лимит на операцию — при любой несанкционированной транзакции можно заблокировать карточку «до выяснения»(опять же -потом гемор с перевыпуском будет).
Это просто пример того, что дополнительный геморрой в любой криптосистеме(то, от чего вы пытаетесь избавиться по вашим словам) как правило будет оправдан.
Ну так ясен пень — keyword-то нужно где-то хранить как минимум. Хоть в ресурсах/исходниках самой программы.
А вам так принципиально воспринимать заголовок буквально?
Если даже взять общий «принцип узнавания» и научить сервер задавать вам задачки, которые сможете именно так решить только вы, ему(серверу) все-равно что-то придется у себя хранить — условия задачек, список вопросов и т.п. Тут придираться можно бесконечно )
Подозреваю, что это все только до тех пор, пока речь не идет о банковских картах, счетах, кредитах, накоплениях, сексе с женой, вещах на работе, напрямую связанных с размером зарплаты и штрафных санкциях, доступом к вашему жилищу и тому подобных )
Простите, какой именно идеи это провал? Идеи генерить приложенной программой пароли себе самому или идеи использовать этот алгоритм на конкретном сервере для генерации паролей пользователям принудительно?
В первом случае вам vk2 ответил, как можно самому себе разнообразить пароли, введя дополнительную известную «соль» в исходные данные.
Во втором случае можно привязывать генерацию пароля не к логину, а к чему-то еще, что можно для пользователя поменять безболезненно. Например в кортеже(строке БД) пользователя в таблице пользователей можно добавить поле salt с рандомной строкой, и в алгоритме исходной строкой использовать не «keyword+sitename+login», а «keyword+sitename+login+salt». В случае надобности генерим юзеру новую «соль» и его пароль меняется автоматически, а старый уже не действует.
«криптомодуль — черный ящик» здесь имеется в виду больше все-таки о защите мастер-ключа либо базы паролей. С точки зрения самого алгоритма конечно «идеальный криптомодуль» — «открытый криптомодуль».
>> они от меня практически неотчуждаемые
В том-то и засада — спертый пароль сменить не сложно(если успеть), да и сперт он будет только с одного ресурса.
А вот сменить спертый отпечаток уже немножечко сложнее )
То, о чем вы пишете, все верно. Но это не должно быть узким местом системы. И уж точно не может являться критикой текущей статьи. Защита сервака и его криптодвижка — это отдельная песня.
Если можно увести из базы пароли, то, как правило, можно увести и всю базу, и скорее всего ее можно и грохнуть(про бекапы речь отдельная).
Поэтому в обоих случаях неплохо иметь демон на соседнем серваке, к которому есть доступ только по одному порту, который занимается аутентификацией. На него же можно повесить и контроль количества неверных попыток. В таком случае криптомодуль для злоумышленника будет черным ящиком, и сможет защитить сервер даже в большинстве случаев безалаберности программиста, «изобретшего» очередной кривой алгоритм.
Я это к чему — обычно на сервер с веб-мордой сайта вломиться гораздо проще, чем на отдельно-стоящий демон аутентификации. Если веб-проектов масса, одного такого сервака с демоном достаточно для обслуживания туевой хучи проектов. Вероятно поэтому у автора хеш генерится из составной фразы «keyword+sitename+login».
Кроме того, если вы еще раз посмотрите на код в статье, там есть только функция convert(), которую мы как бы и обсуждаем — упаковка хеша. Как этот хеш изначально получается — дело десятое. Хоть в результате шифрования с открытыми-закрытыми ключами. Главное, чтобы при получении логина очередного желающего войти на сервер юзера, сервер мог автоматом в памяти сгенерить его пароль для сравнения.
То есть фактически я говорю только о паре строк кода, не обсуждая остальное и связанные с ним проблемы — иначе это будет долгий неуникальный разговор, скорее всего к тому же непродуктивный вследствии регулярности подобных разговоров в коментах всех похожих тем )))
Вы скорее всего не очень поняли. Программа, о которой идет речь в посте — просто демо, не более. Вы ее можете использовать для генерации паролей самому себе, используя свой несложный запоминаемый мастер-пароль, если вам так угодно. Кстати, как обычный юзерский пароль, генерит оно вполне нормально, 32 символа, пусть даже с ограниченным алфавитом — это вполне неплохо. Если у целевого сайта есть защита от быстрого перебора — задолбутся брутфорсить.
Если же реализовывать этот же алгоритм на сервере — мастер-пароль можно делать каким-угодно, хоть несколькокилобайтным файлом, никакой пользователь мастер-пароля знать не будет, не должен и не может. Пользователь будет знать только свой логин и конечную сгенеренную последовательность.
У автора однозначно есть сильный косяк в понимании происходящего, обсуждаемый выше вокруг цитаты «Но надежность пароля все равно оставляет желать лучшего» и далее про HEX-представление. Это серьезный косяк, ибо в неисправленном виде может повлиять на безопасность его(автора) дальнейших разработок. С этим не вижу смысла спорить, с этим я согласен на все сто.
Но сам код данного поста, если правильно понимать его предназначение и функционал, собран в общем-то без ошибок.
А функционал его заключается только в упаковке неудобоваримого длинного хеша в более человечески запоминаемую последовательность для конечного юзера. Да — упаковка хеша с потерей данных. Да — понижение устойчивости ключа. Но сами подумайте — на большинстве сайтов большинство пользователей делают себе еще более короткие пароли(явно менее 32 символов) приблизительно с таким же алфавитом.
То есть текущий выхлоп программы можно сократить еще в два-четыре раза, потеряв конечно же дополнительно в устойчивости ключа, и только тогда мы приблизимся к устойчивости большинства обычных самопридуманных паролей, таких как на большинстве сайтов. Да и то, с оговоркой, что у нас пароли будут наиболее защищенными среди подобных, ибо у нас-то вряд ли будет множество последовательностей типа «12345», «qwerty», «masha1985» и т.п.
То есть по сути мы имеем генератор юзерских коротких паролей(да, с их недостатками, но с однозначным исключением атаки с использованием социнженерии), только без необходимости хранить БД паролей на сервере.
Добавьте к этому алгоритму со стороны сервера защиту от перебора по таймеру или количеству попыток на логин, а так же автовыбор длины пароля в разумных пределах, и все будет хорошо.
Зачем нужен автовыбор длины? Усложнение работы брутфорсеру. Если длина пароля одна везде, то условия для настройки программы брутфорса упрощаются, например выставляем длину 16 символов, и программе не придется перебирать комбинации из 6-15 символов и т.п. А тут количество вариантов увеличивается )
Для keyword можно взять несколько килобайт рандомных данных. Как будете ломать?
Может вы не до конца поняли алгоритм? keyword используется только сервером(возможно даже только отдельным сервером аутентификации). Пользователь не знает keyword.
Длина результата хэш-функции более чем предостаточна для пароля. Но надежность пароля все равно оставляет желать лучшего. Каждый символ такого пароля может принимать только одно 16-ти значений, так как результатом хэш-функции является строка чисел в шестнадцатеричном представлении.
Да, тут у автора косячок, ибо его алгоритм как раз таки уменьшает надежность исходного хеша как пароля.
Это не Base64 и не переход между системами счисления. Base64 увеличивает длину входной строки приблизительно на треть. Здесь же длина строки — один к одному. Под длиной входной строки здесь понимается хеш в 32 бинарных байта на выходе из Sha256, а не в два раза большее его hex-представление.
При этом и Base64, и конвертация между системами счисления не теряют данные — исходная строка восстановима вместе со всей ее устойчивостью к перебору. Здесь же мы видим фактическую упаковку хеша Sha256 с потерей данных, что означает, что для брутфорса взлом прямым перебором будет на порядки быстрее, особенно если знать алфавит. То есть данным алгоритмом, так или иначе, снижается надежность Sha256, превращая его фактически в Sha63 или что-то вроде того.
Аналогично можно было просто взять каждый четный или каждый нечетный символ хеша и сократить длину пароля в 2 раза, оставшись на выходе в пределах hex набора символов(что еще более снизит устойчивость к брутфорсу — Sha16 в эквиваленте). Можно и в данном алгоритме на выходе брать четные или нечетные символы, сокращая длину пароля, результат будет тождественен.
Обычно пароли для пользователей так и генерируют — алгоритмами, похожими на алгоритм в статье. Только отличие в том, что принято генерить такие пароли, используя генератор (псевдо-)случайных чисел.
Но все это не важно, т.к. статья по тексту и названию никак не претендует на усиление криптозащиты. И ее(криптозащиты) реализация может быть любой. По поводу того же брутфорса можно долго теоретизировать о том, что на многих сайтах, где вам дают выбрать самому себе пароль, прямо в правилах практически явно указывается алфавит и длина("… не менее 6 символов, можно использовать строчные и прописные латинские буквы и цифры..."), о том, что мало кто сам себе придумывает пароли длиннее 8 символов, и что защита от брутфорса делается не в алгоритме генерации пароля, а в движке сайта(блокировка после N попыток, капча и т.п.), о том, что частенько сайты ломаются не подбором паролей в лоб, да и вообще в обход механизмов аутентикации, ну и много еще о чем.
Как я понял, главный посыл статьи: идея реализовать аутентификацию без хранения базы паролей. То, что нельзя конкретному юзеру сменить пароль, обходится ведением базы разрешенных логинов — просто меняем юзеру в базе логин(соответственно и этот несохраняемый пароль тоже сменится).
Идея сама по себе не нова, но ее мало кто использует из-за определенных неудобств:
Невозможность смены пароля конкретному логину;
Невозможность выбора пароля самим пользователем;
Приходится прятать мастер-пароль как можно дальше и как можно глубже, желательно вообще на другую машину с очень сильно ограниченным доступом, т.к. мастер-пароль является ключем ко всему.
То есть, область применения этой идеи достаточно ограничена ее же условностями.
Итого: за напоминание забываемой в последнее время идеи ставлю плюс с натяжкой. Натяжка только потому, что идея не нова и в общем-то не блещет плюсами гибкости для пользователя. Хотя какая нафиг она забываемая — регулярно ее изобретают заново, и так же регулярно от нее отказываются. Значит отсавлю плюс за то, что автор не накосячил в коде своей реализации. Обычно те, кто ее изобретают в очередной раз, косячат тут же в реализации процентах в 90 случаев.
Раньше такие вещи, типа EEEPC были популярны — разобрать, воткнуть в мультимедиапанель и вот уже автокомпьютер, навигация и т.п.
Как переносная дешевая печатная машинка тоже сойдет, кому по профилю деятльности подходит.
Здесь вопрос только в том, насколько часто вы ездите «в походы». Я слово «поход» и здесь, и в предыдущем каменте, намеренно беру в кавычки. То есть имеется в виду любой походный режим, а не сам поход как его принято понимать(Если ездите на машине, то проще орагнизовать питание/дозарядку через прикуриватель или напрямую от автоаккумулятора).
Если это редкость, пару раз в год максимум, то и покупка внешнего аккумуляторного блока, и покупка запасных батарей — не очень оправдана, т.к. большинство времени это будет валяться где-то у вас в ящиках стола, и вряд ли вы будете за ним следить и ухаживать, дозаряжая каждые три месяца минимум до 70% заряда и проводить прочие процедуры обслуживания, необходимые для того, чтоб аккумуляторы тупо не сдохли вследствии саморазряда.
Это общая проблема резервных источников питания — они отбивают свои деньги только в случае относительно частого и регулярного использования. Даже те пользователи, которые знают, как продлить жизнь батареям, при редком их использовании банально забывают или забивают на необходимые, пусть и не сложные, процедуры обслуживания.
Но если надобность в использовании таких источников питания наступает достаточно часто, если это обеспечивает вам ваш хлеб или ваше хобби — уже есть смысл пошаманить и сделать «как правильно» — балансиры, безопасность, надежность и т.п.
Еще к примеру: знаете, почему в детских игрушках практически не используют литий? Именно из-за безопасности мы вынуждены либо постоянно ставить на зарядку пальчиковые аккумуляторы пачками, или покупать такие же батарейки ящиками.
Единственная литиевая химия на данный момент из ширпотребных, которая для детских игрушек дает сравнительно похожий уровень безопасности — LiFePO4.
Выше AYrm дал ссылку на hobbyking. Там можно подобрать.
Такие же батареи с дилэкстрима будет брать стремновато — LiPo-шки некачественные если жахнут, то мало не покажется.
Хоббикинг конечно тоже стопроцентной гарантии качества не даст, но они стараются откровенное УГ не продавать, так что вероятность нарваться снижается на порядки.
Кроме того, есть еще такой непредсказуемый фактор, как зарядник со стороны ноута — если он паршивый, то и хороший аккумулятор может в «неправильные» режимы вогнать. В лучшем случае он вздуется и потеряет емкость.
На замену батареи я хотел то же самое приблизительно предложить. Заменить штатный на большую емкость само просится, это да.
Но «для походов» я бы так не делал — не особо удобно. Если посмотреть на фотки нижней части, можно увидеть наклейку с параметрами питалова ноута в целом: 9 вольт, 2 Ампера. Можно внешний аккумуляторный блок подходящий подобрать, оставив внутренней батарее функцию бесперебойника.
Еще лучше(но это уже будет DIY) — найти подходящую LiFePO4 сборку или наколхозить самому, и взять к ней плату зарядника с балансиром, типа вот такой(они бывают и трехбаночные и на другие количества).
Можно и обычные полимерки или Li-Ion юзать, даже однобаночные с бустером до 9 вольт, но LiFePO4 все-таки побезопасней будет.
>> Кстати, кто мне подскажет, где точно такие же аккумуляторы можно купить и где о них почитать?
Это судя по всему двухбаночная LiPo-шка. 2 банки по 3.7 вольта номиналом последовательно. Емкость каждой банки на бумажке написана(при последовательном соединении это же будет емкостью всей сборки). Судя по тому, что проводков 2 — без балансира.
Вам не обязательно точно такой же искать. Любой двухбаночный подходящий по габаритам и емкости сойдет.
Нарисуйте габариты этого аккумулятора, я скажу, что можно подобрать подходящего.
Остальные остаются. И то, что вы не пользуетесь онлайн-сервисами, вовсе не означает, что ними за вас не воспользуется кто-то другой.
В ресторанах всегда требуете, чтобы снятие с карты происходило при вас? Всегда внимательно смотрите на терминал на кассе или в руках официанта на предмет доустановки накладок-снифферов на щель считывателя?
Ну и т.п. Подтверждение транзакции по СМС в таких случаях спасает, но несет некоторый геморрой, да и редкие банки такое поддерживают. Частично спасает СМС-информирование плюс дневной лимит и лимит на операцию — при любой несанкционированной транзакции можно заблокировать карточку «до выяснения»(опять же -потом гемор с перевыпуском будет).
Это просто пример того, что дополнительный геморрой в любой криптосистеме(то, от чего вы пытаетесь избавиться по вашим словам) как правило будет оправдан.
А вам так принципиально воспринимать заголовок буквально?
Если даже взять общий «принцип узнавания» и научить сервер задавать вам задачки, которые сможете именно так решить только вы, ему(серверу) все-равно что-то придется у себя хранить — условия задачек, список вопросов и т.п. Тут придираться можно бесконечно )
В первом случае вам vk2 ответил, как можно самому себе разнообразить пароли, введя дополнительную известную «соль» в исходные данные.
Во втором случае можно привязывать генерацию пароля не к логину, а к чему-то еще, что можно для пользователя поменять безболезненно. Например в кортеже(строке БД) пользователя в таблице пользователей можно добавить поле salt с рандомной строкой, и в алгоритме исходной строкой использовать не «keyword+sitename+login», а «keyword+sitename+login+salt». В случае надобности генерим юзеру новую «соль» и его пароль меняется автоматически, а старый уже не действует.
В том-то и засада — спертый пароль сменить не сложно(если успеть), да и сперт он будет только с одного ресурса.
А вот сменить спертый отпечаток уже немножечко сложнее )
Если можно увести из базы пароли, то, как правило, можно увести и всю базу, и скорее всего ее можно и грохнуть(про бекапы речь отдельная).
Поэтому в обоих случаях неплохо иметь демон на соседнем серваке, к которому есть доступ только по одному порту, который занимается аутентификацией. На него же можно повесить и контроль количества неверных попыток. В таком случае криптомодуль для злоумышленника будет черным ящиком, и сможет защитить сервер даже в большинстве случаев безалаберности программиста, «изобретшего» очередной кривой алгоритм.
Я это к чему — обычно на сервер с веб-мордой сайта вломиться гораздо проще, чем на отдельно-стоящий демон аутентификации. Если веб-проектов масса, одного такого сервака с демоном достаточно для обслуживания туевой хучи проектов. Вероятно поэтому у автора хеш генерится из составной фразы «keyword+sitename+login».
Кроме того, если вы еще раз посмотрите на код в статье, там есть только функция convert(), которую мы как бы и обсуждаем — упаковка хеша. Как этот хеш изначально получается — дело десятое. Хоть в результате шифрования с открытыми-закрытыми ключами. Главное, чтобы при получении логина очередного желающего войти на сервер юзера, сервер мог автоматом в памяти сгенерить его пароль для сравнения.
То есть фактически я говорю только о паре строк кода, не обсуждая остальное и связанные с ним проблемы — иначе это будет долгий неуникальный разговор, скорее всего к тому же непродуктивный вследствии регулярности подобных разговоров в коментах всех похожих тем )))
Если же реализовывать этот же алгоритм на сервере — мастер-пароль можно делать каким-угодно, хоть несколькокилобайтным файлом, никакой пользователь мастер-пароля знать не будет, не должен и не может. Пользователь будет знать только свой логин и конечную сгенеренную последовательность.
У автора однозначно есть сильный косяк в понимании происходящего, обсуждаемый выше вокруг цитаты «Но надежность пароля все равно оставляет желать лучшего» и далее про HEX-представление. Это серьезный косяк, ибо в неисправленном виде может повлиять на безопасность его(автора) дальнейших разработок. С этим не вижу смысла спорить, с этим я согласен на все сто.
Но сам код данного поста, если правильно понимать его предназначение и функционал, собран в общем-то без ошибок.
А функционал его заключается только в упаковке неудобоваримого длинного хеша в более человечески запоминаемую последовательность для конечного юзера. Да — упаковка хеша с потерей данных. Да — понижение устойчивости ключа. Но сами подумайте — на большинстве сайтов большинство пользователей делают себе еще более короткие пароли(явно менее 32 символов) приблизительно с таким же алфавитом.
То есть текущий выхлоп программы можно сократить еще в два-четыре раза, потеряв конечно же дополнительно в устойчивости ключа, и только тогда мы приблизимся к устойчивости большинства обычных самопридуманных паролей, таких как на большинстве сайтов. Да и то, с оговоркой, что у нас пароли будут наиболее защищенными среди подобных, ибо у нас-то вряд ли будет множество последовательностей типа «12345», «qwerty», «masha1985» и т.п.
То есть по сути мы имеем генератор юзерских коротких паролей(да, с их недостатками, но с однозначным исключением атаки с использованием социнженерии), только без необходимости хранить БД паролей на сервере.
Добавьте к этому алгоритму со стороны сервера защиту от перебора по таймеру или количеству попыток на логин, а так же автовыбор длины пароля в разумных пределах, и все будет хорошо.
Зачем нужен автовыбор длины? Усложнение работы брутфорсеру. Если длина пароля одна везде, то условия для настройки программы брутфорса упрощаются, например выставляем длину 16 символов, и программе не придется перебирать комбинации из 6-15 символов и т.п. А тут количество вариантов увеличивается )
Может вы не до конца поняли алгоритм? keyword используется только сервером(возможно даже только отдельным сервером аутентификации). Пользователь не знает keyword.
Да, тут у автора косячок, ибо его алгоритм как раз таки уменьшает надежность исходного хеша как пароля.
При этом и Base64, и конвертация между системами счисления не теряют данные — исходная строка восстановима вместе со всей ее устойчивостью к перебору. Здесь же мы видим фактическую упаковку хеша Sha256 с потерей данных, что означает, что для брутфорса взлом прямым перебором будет на порядки быстрее, особенно если знать алфавит. То есть данным алгоритмом, так или иначе, снижается надежность Sha256, превращая его фактически в Sha63 или что-то вроде того.
Аналогично можно было просто взять каждый четный или каждый нечетный символ хеша и сократить длину пароля в 2 раза, оставшись на выходе в пределах hex набора символов(что еще более снизит устойчивость к брутфорсу — Sha16 в эквиваленте). Можно и в данном алгоритме на выходе брать четные или нечетные символы, сокращая длину пароля, результат будет тождественен.
Обычно пароли для пользователей так и генерируют — алгоритмами, похожими на алгоритм в статье. Только отличие в том, что принято генерить такие пароли, используя генератор (псевдо-)случайных чисел.
Но все это не важно, т.к. статья по тексту и названию никак не претендует на усиление криптозащиты. И ее(криптозащиты) реализация может быть любой. По поводу того же брутфорса можно долго теоретизировать о том, что на многих сайтах, где вам дают выбрать самому себе пароль, прямо в правилах практически явно указывается алфавит и длина("… не менее 6 символов, можно использовать строчные и прописные латинские буквы и цифры..."), о том, что мало кто сам себе придумывает пароли длиннее 8 символов, и что защита от брутфорса делается не в алгоритме генерации пароля, а в движке сайта(блокировка после N попыток, капча и т.п.), о том, что частенько сайты ломаются не подбором паролей в лоб, да и вообще в обход механизмов аутентикации, ну и много еще о чем.
Как я понял, главный посыл статьи: идея реализовать аутентификацию без хранения базы паролей. То, что нельзя конкретному юзеру сменить пароль, обходится ведением базы разрешенных логинов — просто меняем юзеру в базе логин(соответственно и этот несохраняемый пароль тоже сменится).
Идея сама по себе не нова, но ее мало кто использует из-за определенных неудобств:
То есть, область применения этой идеи достаточно ограничена ее же условностями.
Итого: за напоминание забываемой в последнее время идеи ставлю плюс с натяжкой. Натяжка только потому, что идея не нова и в общем-то не блещет плюсами гибкости для пользователя. Хотя какая нафиг она забываемая — регулярно ее изобретают заново, и так же регулярно от нее отказываются. Значит отсавлю плюс за то, что автор не накосячил в коде своей реализации. Обычно те, кто ее изобретают в очередной раз, косячат тут же в реализации процентах в 90 случаев.
Как переносная дешевая печатная машинка тоже сойдет, кому по профилю деятльности подходит.
Если это редкость, пару раз в год максимум, то и покупка внешнего аккумуляторного блока, и покупка запасных батарей — не очень оправдана, т.к. большинство времени это будет валяться где-то у вас в ящиках стола, и вряд ли вы будете за ним следить и ухаживать, дозаряжая каждые три месяца минимум до 70% заряда и проводить прочие процедуры обслуживания, необходимые для того, чтоб аккумуляторы тупо не сдохли вследствии саморазряда.
Это общая проблема резервных источников питания — они отбивают свои деньги только в случае относительно частого и регулярного использования. Даже те пользователи, которые знают, как продлить жизнь батареям, при редком их использовании банально забывают или забивают на необходимые, пусть и не сложные, процедуры обслуживания.
Но если надобность в использовании таких источников питания наступает достаточно часто, если это обеспечивает вам ваш хлеб или ваше хобби — уже есть смысл пошаманить и сделать «как правильно» — балансиры, безопасность, надежность и т.п.
Еще к примеру: знаете, почему в детских игрушках практически не используют литий? Именно из-за безопасности мы вынуждены либо постоянно ставить на зарядку пальчиковые аккумуляторы пачками, или покупать такие же батарейки ящиками.
Единственная литиевая химия на данный момент из ширпотребных, которая для детских игрушек дает сравнительно похожий уровень безопасности — LiFePO4.
Такие же батареи с дилэкстрима будет брать стремновато — LiPo-шки некачественные если жахнут, то мало не покажется.
Хоббикинг конечно тоже стопроцентной гарантии качества не даст, но они стараются откровенное УГ не продавать, так что вероятность нарваться снижается на порядки.
Кроме того, есть еще такой непредсказуемый фактор, как зарядник со стороны ноута — если он паршивый, то и хороший аккумулятор может в «неправильные» режимы вогнать. В лучшем случае он вздуется и потеряет емкость.
Но «для походов» я бы так не делал — не особо удобно. Если посмотреть на фотки нижней части, можно увидеть наклейку с параметрами питалова ноута в целом: 9 вольт, 2 Ампера. Можно внешний аккумуляторный блок подходящий подобрать, оставив внутренней батарее функцию бесперебойника.
Еще лучше(но это уже будет DIY) — найти подходящую LiFePO4 сборку или наколхозить самому, и взять к ней плату зарядника с балансиром, типа вот такой(они бывают и трехбаночные и на другие количества).
Можно и обычные полимерки или Li-Ion юзать, даже однобаночные с бустером до 9 вольт, но LiFePO4 все-таки побезопасней будет.
Это судя по всему двухбаночная LiPo-шка. 2 банки по 3.7 вольта номиналом последовательно. Емкость каждой банки на бумажке написана(при последовательном соединении это же будет емкостью всей сборки). Судя по тому, что проводков 2 — без балансира.
Вам не обязательно точно такой же искать. Любой двухбаночный подходящий по габаритам и емкости сойдет.
Нарисуйте габариты этого аккумулятора, я скажу, что можно подобрать подходящего.