Я имел в виду не брать хеш от случайного числа, а именно генерировать случайную строку. То есть, иными словами, генерить число в 62-ричной системе (если используем алфавит A-Za-z0-9). Таким образом, если хеш, как сейчас, будет 40 байт, то различных вариантов будет 62^40. Согласитесь, это больше чем RAND_MAX :-)
Прикол не в том, чтобы хранить половину у себя, а в том, чтобы не хранить ключ целиком у себя. Представьте такую ситуацию: хакеру удалось проникнуть в систему, он смог восстановить зашифрованные данные из базы. Теперь ему нужен ключ. Если бы мы отдавали весь ключ целиком клиенту, его можно было бы вытащить, к примеру, из access-логов сервера. А так хакеру потребуется приложить больше усилий для взлома.
Как известно, в таких ситуациях решающим фактором является цена информации и цена усилий для её получения. Если вторую цену мы поднимем достаточно высоко, то он скорее плюнет и бросит эту дурацкую затею.
Удаление действительно нельзя считать достаточно надёжным, но примите во внимание то, что в базе хранятся зашифрованные данные. Если злоумышленнику удастся восстановить удалённые данные, то он получит лишь кусок мусора. Для расшифровки нужен ключ, а в базе хранится только его часть.
Гарантию, конечно, обеспечить сложно. Можно предложить человеку пользоваться несколькими независимыми каналами передачи данных, одним из которых может стать secureshare. Например, если Вы передаёте реквизиты доступа к серверу по ssh, то логин можно передать в письме или смс, а хост и пароль — в одноразовой ссылке.
Вы совершенно правы, генерировать хеш или случайную строку — в данном случае всё равно. Теоретически, если генерировать строку той же длины из б0льшего алфавита (не 0-9a-f, а, скажем, A-Za-z0-9), то возможных сочетаний получается больше и вероятность случайно угадать хеш снижается. Но на практике оба этих варианта обеспечивают достаточную устойчивость к перебору.
чтобы ваша простейшая регулярка поместилась на экран, надо уменьшить масштаб браузера по ctrl+- :-)
там сейчас такая логика, что изменения в textarea отменяются при потере фокуса. Когда вы таб нажимаете, текстареа теряет фокус и изменения дискардятся. Видимо, надо придумать что-то более интуитивно понятное.
спасибо. На счёт первого постараюсь выяснить, что могло случиться. Если у вас появится дополнительная информация как воспроизвести баг, напишите, пожалуйста. На счёт второго да, надо подумать, как лучше сделать.
Вот это да. Спасибо за отзыв! Косяк на счёт «See more» правда был — оказалось, скрипт социальных кнопок «ShareThis» автоматически добавлял ко всему копируемому и вставляемому тексту такую фразу, даже не спросив у меня разрешения. Остальные ваши замечания я добавил в todo-лист, обязательно сделаю, спасибо.
Большое спасибо за фидбек! Баг действительно был, он устранён.
С проблемой читабельности я тоже сталкивался не раз, как один из возможных вариантов решения сделал кнопку «Expand regex» — попробуйте. Буду рад идеям об улучшении этой самой читабельности.
Как известно, в таких ситуациях решающим фактором является цена информации и цена усилий для её получения. Если вторую цену мы поднимем достаточно высоко, то он скорее плюнет и бросит эту дурацкую затею.
там сейчас такая логика, что изменения в textarea отменяются при потере фокуса. Когда вы таб нажимаете, текстареа теряет фокус и изменения дискардятся. Видимо, надо придумать что-то более интуитивно понятное.
С проблемой читабельности я тоже сталкивался не раз, как один из возможных вариантов решения сделал кнопку «Expand regex» — попробуйте. Буду рад идеям об улучшении этой самой читабельности.
За сервис спасибо, я о таком не знал.
Товарищ в этом комментарии оставил пример — habrahabr.ru/post/175179/#comment_6086545 — мне сходу не удаётся понять логический смысл, надо разбираться, а вам? )