Если честно, я не понял, что вы этим хотели сказать. Я знаю, как в JS записываются массивы. Также, насколько я помню, в JS родной поддержки котрежей нет, так что это не существенно. :-)
Как вариант, на других сайтах эти поля каждый раз имеют разные имена создавая иллюзию защищенности в то самое время, когда данные спокойно оседают в истории автодополнения браузера.
Зачем нужна?
Допустим, мы подписываем следующие данные (ФИО пассажира, тип и номер удостоверения личности, номер рейса, вагона, места).
ФИО и паспорт вы предъявляете, а на номер вагономеста вы претендуете.
О, нет, вы совсем меня не поняли, тех недостатков, на которые вы указываете в системе нет. Естественно система _продажи_ билетов должна быть подключена к сети РЖД, я говорю лишь о том, что можно избежать поддержки постоянно подключения проводника (системы _проверки_ белетов) к сети, т.к. мне это кажется наиболее «нестабильным» в плане поддержки связи звеном цепи.
С другой стороны, в моём варианте будет буквенно-числовой код подлиннее раз в N-цать — ~1024 бита, например. Кейген в таком случае будет создать настолько же сложно, насколько сложно разломать RSA и/или SHA. Соответственно, чтоб эти 1024 бита передать — придётся печатать либо баркод какой-нибудь, либо строчку символов этак в 160.
Ну вот, а я за решения, которые могут работать и в оффлайне, т.к. один пакистанский провайдер разослав неудачный BGP-анонс может нарушить работу «половины интернета» :-)
Да, я знаю, что у РЖД свои каналы связи, но, например, мне гораздо больше нравятся микропроцессорные карточки a-la «золотая корона», которые могут работать даже если на POS нет постоянной связи.
Другой вопрос, что я не уверен в применимости всего этого размышления к реалиями РЖД. Возможно, у машиниста есть инструкция в духе «немедленно остановить поезд при пропаже оперативной связи с ЦУП».
Сеть, конечно, нужна, но постоянное соединение с сетью в вагоне у проводника не обязательно.
Берем фамилию, данные удостоверения личности и прочие реквизиты билета, подписываем их ключем подписанным CA РЖД. Ключ валиден, например, только для подписи билетов на один прогон поезда от конечной до конечной, потом проводник просто проверяет валидность подписи + сверяет данные с удостоверением личности.
Смена ключей раз в N дней/часов может сделать это невыгодным. Менять ключи несколько проще, чем обеспечивать постоянную связь.
Хотя у РЖД со связью я лично проблем не ожидаю, но с другой стороны байку слышал, как РЖДшный канал был перегружен паразитным трафиком и из-за этого пришлось останавливать сообщение…
Даже участие в google summer of code можно при желании зачесть как производственную практику.
Изменения последней минуты контролируются по временной метке, которую можно сохранять вместе с подписью — у кого timestamp больше, тот и прав.
Допустим, мы подписываем следующие данные (ФИО пассажира, тип и номер удостоверения личности, номер рейса, вагона, места).
ФИО и паспорт вы предъявляете, а на номер вагономеста вы претендуете.
Практика показывает, что самое слабое звено системы — человек, но тем не менее это не значит, что стоит пренебрегать PKI.
В принципе, наверное, 160 символов можно обрезать до любого N, но я не ручаюсь за то, что это ничему не повредит.
С другой стороны, в моём варианте будет буквенно-числовой код подлиннее раз в N-цать — ~1024 бита, например. Кейген в таком случае будет создать настолько же сложно, насколько сложно разломать RSA и/или SHA. Соответственно, чтоб эти 1024 бита передать — придётся печатать либо баркод какой-нибудь, либо строчку символов этак в 160.
— страдающий от нехватки шрифтов линуксоид :-)
Да, я знаю, что у РЖД свои каналы связи, но, например, мне гораздо больше нравятся микропроцессорные карточки a-la «золотая корона», которые могут работать даже если на POS нет постоянной связи.
Другой вопрос, что я не уверен в применимости всего этого размышления к реалиями РЖД. Возможно, у машиниста есть инструкция в духе «немедленно остановить поезд при пропаже оперативной связи с ЦУП».
Берем фамилию, данные удостоверения личности и прочие реквизиты билета, подписываем их ключем подписанным CA РЖД. Ключ валиден, например, только для подписи билетов на один прогон поезда от конечной до конечной, потом проводник просто проверяет валидность подписи + сверяет данные с удостоверением личности.
Я что-то пропустил?
Хотя у РЖД со связью я лично проблем не ожидаю, но с другой стороны байку слышал, как РЖДшный канал был перегружен паразитным трафиком и из-за этого пришлось останавливать сообщение…