|
2 AAron
>PS. Что интересно, люди работающие на MS SQL просто на порядок терпимее тех, кто на ОРАКЛЕ :)
Это ты наверное с дедом маздаем не знаком, он один всех нас перевешивает в смысле терпимости. Вот прийдет и восстановит справедливость.
2 aag
>1. Есть такое понятие - криптостойкость. Оная обеспечивается реалицией математических алгоритмов. И рассуждения, что сто лет - маловато будет, надо .... - все это детские, извините, рассуждения. Если я сделаю пароль "1" в Оракле - его что труднее сломать, чем в MSSQL? Потому что там-де логин не виден?
Да, именно так, в реальнй ситуации его труднее сломать именно потому, что не виден зашифрованый пароль. Потому что если зашифрованный пароль не виден, то есть один способ - перебор, причем каждый раз нужно делать попытку логина. Такую активность можно отследить и пресечь. Когда мы зашифрованный пароль знаем, как в случае с MSSQL, то его можно расшифровывать, например тем же перебором, сравнивать результат с известным у себя на машине и если совпало, то смело логинится.
>Смешно. А если вы хотите высокую защищенность - ради бога, заставьте пользователей вводить не меньше n символов и пр.
Действительно смешно. Защищенность не зависит от длинны введенного пароля. По внешнему виду "правильно" шифрованного пароля нельзя определить первоначальную пароля, поэтому расшифровка пароля длины 1 теоретически не легче расшифровки пароля длины n>1. С точностью до известных алгоритмов конечно.
Кроме того, криптостойкость реальной системы в целом зависит не только от алгоритмов шифрования, но и от архитектуры системы и многих других вещей. В WW2 англичане сломали енигму из-за того, что немецкий радист один раз забыл прокрутить колеса шифровальной машины. Хотя в смысле прямой расшифровки надежд не было никаких.
2 SergSuper
>В MS SQL поле passwords обычный юзер не видит! Ни явное, ни зашифрованное.
Как же не видит, представление syslogins видна по умолчанию группе паблик (MSSQL7), в нем есть поле passwords. Но вопрос не в этом, третий раз повторяю. Вопрос в том, на кой туда вообще включать это поле. Есть таблица sysxlogins, там живет пароль (или хеш, не важно), пусть там и живет, в представлении, которое видят пользователи он ни к чему.
>А вобще ну ты же пишешь примитивные вещи. Ну странно слышать что храниться зашифрованный пароль. Там храниться хэш паролей, который в принципе невозможно расшифровать(даже зная алгоритм и все ключи).
Никак тебе не угодишь. Не цитирую документацию - тебе не нравится, цитирую - опять не нравится. Это не я пишу, это мелкософт. Вот тебе цитата из документации, я ее приводил пару дней назад:
In SQL Server Authentication, when a login ID is added or a password is changed, the password encryption algorithm takes the supplied password and generates a numeric representation, which is stored in the syslogins table.
Никаких хешей тут не видно, есть цифровое представление пароля, полученное на выходе "password encryption algorithm", что не совсем одно и то же. Если у тебя есть более точные данные, выложи здесь или дай ссылку, я почитаю.
Может мы просто хешем называем разные вещи. Хеш в общем случае вычисляется с потерей информации. Значит нескольким паролям будет соответствовать одинаковый хеш. Значит несколько паролей будут ошибочно считаться законными. А где тогда живет настоящий? Или я чего-то не понял?
>Ну и к тому же современные методы шифрования с закрытым ключом не позволяют расшифровывать - пароль узнать можно только полным перебором.
Неверно. Верное утверждение звучит так: на сегодняшний день не доказано существование алгоритмов, эффективно (обычно под этим понимается за полиномиальное время) расшифровывающих ... (тут идет название способа шифрования). Но это не значит, что самый эффективный известный алгоритм - перебор. Могут быть другие, более эффективные, чем перебор, но не полиномиальные.
Никто так и не ответил на вопрос, зачем было путем дополнительных усилий искусственно уменьшать защищенность MSSQL7 в регистронезависимой конфигурации? Есть у кого-нибудь разумное объяснение?
|
