Для поля ввода паспорта:
<input type="text" required="" tabindex="2" class="std_textbox" placeholder="Enter your account password." id="pass" name="pass">
При изменении <input type="password"> на <input type="text"> Открывается пароль. Это может быть опасно в системах, которые сохраняли пароли или генерировались менеджерами паролей.
Можно ли использовать шифрование на стороне клиента здесь? Как это можно реализовать?
Как уже говорилось, наличие пароля во входном элементе позволит пользователю легко обнаруживать пароль.
... И как @Elyasin спрашивает, вы действительно должны сообщить нам, что ваш прецедент.
Будучи в неведении относительно вашего прецедента, позвольте предположить, что у вас есть веб-сайт, на который пользователи могут подписаться на плату, и вы не хотите, чтобы несколько пользователей, пользующихся одним человеком, могли обойти оплату абонентской платы.
Вы можете использовать аутентификацию cookie для проверки того, что пользователь подписался на ваш сайт.
Когда подписывается новый пользователь, отправьте им письмо с ссылкой на специальную страницу регистрации на вашем веб-сайте.
Когда пользователь следует этой ссылке, поместите файл cookie на компьютер пользователя, указав, что он действительный абонент.
Создайте целевую страницу на своем сайте. Эта целевая страница будет считывать файл cookie с пользовательского компьютера и проверять подлинность, что они действительно действительный абонент.
Все остальные страницы вашего сайта должны перенаправлять пользователей на целевую страницу, если у этих пользователей нет файла cookie, проверяющего.
Поскольку пользователи, не подписавшие подписку, могут быть перенаправлены на целевую страницу, вы можете предложить им стать подписчиками на целевой странице.
Если подписная подписная подписка истекла, вы принимаете cookie с (теперь отписку) пользовательского компьютера при следующем посещении вашего сайта. Как и любой пользователь без подписки, вы перенаправляете их на целевую страницу.
Хотя верно, что файлы cookie могут быть перехвачены или украдены, это обычно за пределами случайной способности пользователя делать это.
Если вам нужна дополнительная безопасность с помощью куки файлов, вы можете захватить IP-адрес пользователя, когда они сначала подписываются. Затем вы можете проверить, что у пользователя есть файл cookie для проверки, а также доступ с того же самого IP-адреса, из которого они первоначально подписались. Конечно, это ограничивает возможность подписки на использование только своего первоначального IP-адреса для доступа к вашему сайту.
Короткий ответ: Этого нельзя предотвратить, к сожалению. Это связано с тем, что весь клиентский код (JavaScript) модифицируется самим клиентом, что делает уязвимость системы безопасности на основе клиента.
Единственное работоспособное решение, о котором я могу думать, - хранить хешированное представление пароля вместо необработанного пароля. Это будет (если вы игнорируете атаки хеш-грубой силы), сохраните безопасный пароль.
Хэш представляет собой представление исходного текста и не обратимо. То есть исходная строка символов не может быть получена любым алгоритмом, используя только хэш. Примерами хешей являются MD5 и SHA. Этот метод обычно используется в маршрутизаторах, где пароль часто хранится в браузере.
Уточнение. Никогда не храните свои пароли в текстовом формате, и если вы хотите принять эту технику заранее введенного пароля; хеширование и/или шифрование должны выполняться на стороне сервера.
Я видел решения в разных ответах. Во всех из них просто сложнее увидеть пароль, но это не мешает кому-либо увидеть его.
Примечание. На клиентской стороне объекты JavaScript могут обрабатываться и проверяться. В решениях, представленных в других ответах, я мог бы легко доступ к информации о пароле.
Как и другие, вы не можете запретить пользователю просматривать пароль с помощью инструментов разработчика на стороне клиента.
Я не мог придумать пример использования, но вы упоминали о автоматическом заполнении формы и опции "Запомнить меня".
Автоматический заполнитель формы, насколько мне известно, является защищенным паролем. Они должны быть; Я бы не использовал его, если бы я не мог включить его или выключить надежно. В этом случае я обязан выходить из системы, когда я нахожусь в ситуации совместного использования компьютера.
Помните, что опция, которая часто рекламируется веб-сайтами, должна использоваться только тогда, когда это ваш персональный компьютер, и вы не ожидаете поделиться своим устройством с другим человеком. Не используйте его или убедитесь, что никто другой не использует вашу учетную запись. Опять же, это ваша ответственность.
Теперь вы все еще видите необходимость предотвратить такую атаку. Все, что я могу придумать, следующее:
Если вы используете шифрование, вы всегда можете расшифровать.
Это может помочь вам в следующем сценарии: всегда зашифровывать пароль. Они всегда должны совпадать. Однако, когда пользователь хочет изменить свой пароль, это будет чистый текст. Пользователь не может вводить его в зашифрованном виде. Вы должны решить это. Есть решения. Я уверен, что вы это поняли.
Если вы используете (зашифрованное) хеширование, то очень сложно взломать. Вы не можете расшифровать его.
Это может помочь вам в следующем сценарии: сервер отправляет только хешированную версию. Таким образом, злоумышленник не может использовать эту информацию. Вы должны спроектировать его соответствующим образом, но я думаю, вы тоже это понимаете.
Сказав это, я действительно не вижу приемлемого варианта использования для вашего требования.
Позвольте мне объяснить, почему. Вы хотите, чтобы злоумышленник не видел пароль, если пользователь помнит пароли или использует автоматический заполняющий форму. Ну, если злоумышленник может получить доступ к пользовательскому компьютеру, он сможет просто войти в систему, зачем беспокоиться о получении пароля?
Существует причина, по которой такие компании, как Google или Facebook, не в решении для вашего случая использования. Пошел еще один путь и попытался нажмите для повышения безопасности с помощью двухфакторной аутентификации
Если вы можете использовать это, сделайте это. Он не решает проблему полностью, но вы можете ожидать повышения ее безопасности. В частности, это сложнее для атакующего.
Как и для клиентов, нет реального способа предотвратить это. Что касается модели безопасности: мы не можем доверять клиенту. С другой стороны, однако, нет реального способа реализовать это по-другому без использования стороннего устройства.
Если вы согласны с тем, что стороннее устройство помогает в аутентификации: создайте веб-сайт и покажите случайное семя, попросите устройство запросить семя и пароль для генерации хеша и выполните проверку подлинности на сайт с использованием хэша. Конечно, хэш будет по-прежнему видимым, если вы используете веб-отладчик, но, по крайней мере, нет смысла его хранить/читать, поскольку хэш будет отличаться для каждого сеанса. Кстати, это не полностью безопасно, так как этот метод подвержен выбранной атаке открытого текста.
Престижность, если вы готовы пройти через все эти проблемы. Я полагаю, вы могли бы написать приложение для этого, чтобы иметь функцию смартфона в качестве стороннего устройства.
Абсолютно нет. Вы не можете запретить конечному пользователю манипулировать DOM из инструментов разработчика или firebug.
Использование любого трюка на стороне клиента не может помешать пользователю сделать это. До или если браузер не запретит этому делать.
Я полагаю, что проблема, с которой вы сталкиваетесь, - это несколько человек, использующих один и тот же компьютер, и если один пользователь сохраняет свой пароль на вашем сайте, то любой другой, который посещает сайт на том же ПК чтобы управлять полем, чтобы открыть пароль.
Один из способов предотвращения этого - отключить автозаполнение. autocomplete="off" Поместите этот код во входной элемент, и даже если пароль сохранен, он не должен отображаться. <input autocomplete="off" type="text" required="" tabindex="2" class="std_textbox" placeholder="Enter your account password." id="pass" name="pass">
Плюсы
Вам не нужно беспокоиться о том, что пользователи используют компьютеры, а пароли отображаются по большей части.
Минусы
Пользователи могут подумать, что их пароли сохранены (и они все еще могут сохранять пароли), но когда они попадут на ваш сайт, он не появится.
ПРИМЕЧАНИЕ. Это не полный способ предотвращения использования пользователями форм для обработки формы и получения паролей других пользователей.
В качестве примечания, если сайт не обновляется после ввода пароля и имени пользователя, веб-браузер не будет запрашивать пароль. Например, используя вызов ajax вместо формы submit.
Вы можете использовать JavaScript для стирания текста в поле пароля при загрузке страницы. Лучшим стилем будет добавление поля, когда страница загружается с помощью JavaScript следующим образом: var x = document.createElement( "INPUT" ); x.setAttribute( "тип", "пароль" );
Альтернатива автозаполнению = "off" альтернатива автозаполнения Она включает в себя создание имени из бэкэнд и использование его в качестве имени полей так что автозаполнение никогда не узнает, куда поместить ваших пользователей сохраненные данные.
Ну, с нынешней технологией это невозможно. Как и другие, вы все еще можете проверить весь код на стороне клиента и попытаться манипулировать DOM.
Другое решение - реализовать как банковский логин. Рандомизируйте последовательность паролей при каждом входе в систему. Например, если длина пароля равна 10, дайте пользователю три поля пароля, задайте последовательность паролей, например. 3-й, 5-й, 10-й. Это будет изменяться каждый раз, когда пользователь попытается войти в систему. И на стороне сервера вы их сравниваете.
Примечание. Я думаю, вам следует избегать этого, так как это нарушит основные функции браузера.
Но если вы настаиваете, вы можете сделать труднее, чтобы кто-то открыл пароль, "делегируя" ввод в другое поле ввода и заполняя поле пароля случайными символами.
Ниже приведен пример одного из способов сделать это. Имейте в виду, что это никоим образом не мешает кому-либо получить пароль из тела запроса напрямую или если вы найдете свой "скрытый" элемент делегата.
!function() {
var passwordEl, delegateEl;
function syncPassword() {
passwordEl.value =
Array(delegateEl.value.length + 1).join('*');
}
function createDelegate() {
delegateEl = document.createElement('input');
delegateEl.style.position = 'absolute';
delegateEl.style.top = '-9999px';
delegateEl
.addEventListener('keyup', syncPassword, false);
document.body.appendChild(delegateEl);
}
window.addEventListener('load', function() {
passwordEl = document.getElementById('passwordId');
createDelegate();
// steal the focus from the password input
passwordEl.addEventListener('focus', function(e) {
e.preventDefault();
delegateEl.focus();
}, false);
syncPassword(); // clear if was auto completed
}, false);
}();
Теперь у вас есть возможность повторного заполнения ввода пароля с правильным паролем в форме submit или просто чтобы ваш сервер ожидал, что пароль поступит из делегированного поля.
Если вам интересно, вы можете добавить соответствующий стиль в поле пароля, когда поле делегата будет сфокусировано, и, таким образом, дать пользователю впечатление, что они все еще сосредоточены на самом поле пароля.
Но не надо.
Вы можете использовать простой код Javascript для хранения значения пароля в переменной onblur, а затем восстановить его onfoucs или/и onsubmit.
Посмотрите следующий демо-код и его онлайн-демонстрацию здесь:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>JS Bin</title>
<script>
password = '';
function setPasswordBack(){
showPassword();
}
function hidePassword(){
p = document.getElementById('pass');
password = p.value;
p.value = '*********';
}
function showPassword(){
p = document.getElementById('pass');
p.type= "password";
p.value = password;
}
</script>
</head>
<body>
<form action="" method="get" onsubmit="setPasswordBack()">
<input type="password" value="" name="password" id="pass" onblur="hidePassword()" onfocus="showPassword()" />
<input type="submit" />
</form>
</body>
</html>
Понятно, что решение является зависимым от JavaScript решением, поэтому в случае отключения javascript вы можете использовать noscript запрос на браузер с поддержкой JavaScript.
Ну, вы не можете.
Но опять же. Существует один из способов, чтобы пользователь никогда не видел его с помощью консоли разработчика - никогда не отображать поле INPUT с паролем.
Альтернативой было бы эмулировать поведение поля, чтобы оно, кажется, было там, но это не так. Я не нашел технически обоснованного решения, но как это можно сделать, но вот один пример, как это можно сделать: (обновлено) http://jsfiddle.net/858kef4h/
В этом примере идея состоит в создании псевдополя, основанного на DIV, который выглядит как пароль INPUT и прослушивает нажатия клавиш от пользователя и сохраняет значение переменной JavaScript
<div class="pwField">
<div class="pwData"></div>
<div class="cursor"><div class="tfarea"></div></div>
</div>
В этом простом хаке есть три переменные состояния для пароля, состояния фокусировки и скрытой текстовой области
var pw = "", bHasFocus = false, tfArea;
Класс "курсор" переключается в/выкл с использованием JavaScript для эмуляции реального курсора
setInterval( function() {
$(".cursor").toggleClass("blink");
},600);
При нажатии на div создается текстовое поле в месте курсора и фокусируется на нем.
$(".pwField").on("click", function() {
// enable cursor and create element if needed
$(".pwField").addClass("active");
if(tfArea) { // if already created, just focus to the field
tfArea.focus();
bHasFocus = true;
return;
}
tfArea = document.createElement("textarea");
tfArea.value="";
$(".tfarea").append(tfArea);
tfArea.focus();
bHasFocus = true;
$(tfArea).on("blur", function() {
// disable cursor and exit
$(".pwField").removeClass("active");
bHasFocus = false;
});
});
Затем вы можете прослушивать клавиатуру/клавиатуру и записывать значения
$(document).keydown(function( ) {
if(!bHasFocus) return;
pw = tfArea.value;
// print asterisks
$(".pwData").html( asterisks( pw.length ) );
});
И когда вы готовы войти в систему, значение находится в переменной "pw".
Этот динамически созданный TEXTAREA может остаться незамеченным с помощью автоматических менеджеров паролей, потому что это не вид INPUT-полей, которые ожидаются видеть менеджеров паролей.
Пользователь, который редактирует поле, может, естественно, проверить значение этого элемента с помощью инструментов разработчика Chrome, но дело здесь в том, что если диспетчер PW не рассматривает это поле как поле пароля, он не заполняет его пароль предыдущего пользователя.
Я не рекомендую использовать это, это было просто сделано из любопытства. Идея заключалась в том, чтобы показать, что, хотя вы не можете помешать пользователю видеть эти элементы, вы все равно сможете скрыть результат от Менеджеров паролей. Но, как говорится в старой поговорке, "вы можете обмануть некоторых из них некоторое время, но не всех из них все время".
Пользовательский интерфейс отличается от стандартного ввода, но его можно улучшить. Одна из проблем заключается в том, что даже если вы хотите запретить отображение пароля, это может быть то, что действительно хотят пользователи. Они могут захотеть использовать Менеджер паролей. Но в этом случае вам все равно не повезло.
Также могут возникать проблемы с щелчком, фокусом и размытием в разных браузерах, возможно, они не работают с мобильными устройствами, как вы ожидаете. Если этот вид взлома всегда используется, вы должны тщательно протестировать его. Его можно использовать, если вы точно знаете, какие браузеры используют пользователи, и вы знаете, что у них включен JavaScript.
EDIT: Я протестировал подход с некоторыми мобильными устройствами, и он, похоже, несколько сработал, но с iPad, и заметил, что размещение скрытой текстовой области по-прежнему создает видимый курсор и изменяет масштаб, поэтому теперь скрытая текстовая область помещается внутри псевдокурсора DIV, и зум должен следовать за ней.
Вы не можете, и вы не должны. Это не проблема безопасности, которую вы должны решать на своем веб-сайте. Это позволяет пользователю безопасно хранить свои пароли. Если у меня есть возможность использовать консоль dev или иным образом внедрить javascript на вашу страницу, независимо от того, что вы делаете, пользовательские пароли все равно будут скомпрометированы.
Если пользователь выбирает сохранять свои пароли в своем браузере, то это зависит от них, чтобы они не попадали в чужие руки, и вы абсолютно ничего не можете сделать с этим на своем сайте. Фактически, если вы используете Chrome и сохраняете пароли, перейдите к chrome://settings/passwords и щелкните по некоторым полям пароля.
Другие ответы говорят о хеширующих паролях и т.д. Это то, что вам обязательно нужно делать, но на вашем сервере. Вы могли бы, конечно, хэш или зашифровать пароль перед отправкой его на ваш сервер (и вы тоже должны использовать https), но это совершенно другая проблема.
Предпосылка этого вопроса заключается в том, что клиентский компьютер скомпрометирован и используется кем-то, у кого не должно быть доступа. Предполагая, что администратор паролей используется (например, Chrome), который не требует мастер-пароля перед автоматическим заполнением формы входа, вы ничего не можете сделать, чтобы злоумышленник не получал доступ к учетным записям.
Вы пытаетесь решить проблему на уровне приложения, когда проблема доступа глубже.
Предположим, что Боб забыл выйти из своего компьютера. Нападающий (Ева) натыкается на свою открытую сессию Windows и хочет получить доступ к своей учетной записи PayPal. Боб использует диспетчер паролей для нескольких учетных записей, включая учетные записи Gmail, Paypal и Reddit. Предположим, PayPal приняла меры предосторожности на уровне приложения, чтобы предотвратить возможность обучения Евы от пароля Боба из автозаполнения менеджера паролей. Ева думает, что сможет контролировать аккаунт Bob PayPal только до тех пор, пока Боб не вернется. Но затем, Eve замечает функцию связи с паролем PayPal reset. Учетная запись Боба также скомпрометирована, потому что его пароль для нее также находится в диспетчере паролей. Имея доступ к учетной записи электронной почты Боба, Ева может reset любой из паролей Боба, которые она хочет. Она могла поддерживать доступ, установив кейлоггер на компьютер Боба.
В нижней строке, проблемы безопасности, которые вы пытаетесь решить, выходят за пределы вашей власти, чтобы обратиться (при условии обычной модели пароля имени пользователя). Даже не предполагая ничего о вашем приложении, Ева имеет физический доступ к компьютеру Боба, поэтому она могла бы скомпрометировать его множеством способов.
Если вы заставляете своих пользователей использовать двухфакторную аутентификацию (отправляйте им код через текстовое сообщение через Twilio), заставляйте их переносить аппаратный ключ usb и т.д.... вы повысите безопасность и избегаете проблемы с менеджером паролей.
Но в конечном счете, вы сталкиваетесь с компромиссом безопасности и удобства использования. Если Боб слишком ленив/забыв/апатичен/небрежен, чтобы выйти из своего ПК, никакое количество написанного вами JavaScript не сможет его спасти.
Что ж, в 2019 году есть хитрый способ... вы можете создавать формы с помощью JavaScript/jQuery поверх div, и вы можете помещать их только в READ. Если злоумышленник отключит JavaScript, то код gen не будет работать, тогда не будет никакой формы...
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="Generator" content="EditPlus®">
<title>Basic security for mr. Hacker</title>
</head>
<body>
<div id="ticketAF0122"></div><!-- it is assumed that id is generated every time !!! -->
<script src="https://code.jquery.com/jquery-3.3.1.js"></script>
<script>
$(document).ready(function(){
function readonly(){
$('div#ticketAF0122').html('My password<form method="post" action=""><input type="password" name="password"><input type="submit"></form>');
}
readonly()
$('div#ticketAF0122').bind("DOMSubtreeModified", function(){
readonly();
});
});
/*
Basicly you can load this part from an encoding external php file:
<script src="page.php?ticket=ticketAF0122">< /script>
and the php file generate something like:
$(document).ready(function(){
function readonly(){
$('div#ticketAF0122').html('My password<form method="post" action=""><input type="password" name="password"><input type="submit"></form>');
}
readonly()
$('div#ticketAF0122').bind("DOMSubtreeModified", function(){
readonly();
});
});
*/
</script>
</body>
</html>
я уже проверил это в xampp/windows 10 с помощью firefox и изменил с помощью инспектора с type = "password" на type = "text" скрипт снова "исправит" вещи
в EDGE работает с ошибками: когда с Inspector я изменяю этот материал, тогда вся форма является полосой, а затем вставляется над HTML-документ