ntkt

Общепринятой реализации провайдеров в привычном виндовом представлении нет.
В ядре есть подсистема crypto и некоторое API к ней -- это реализация всех основных криптопримитивов для ядерного же использования.
А в юзермоде -- нет ничего готового, единого и удобного, надо самому использовать чисто юзермодные библиотеки: openssl, gnutls, libnss и иже с ними.
Все остальное -- маргинальные эксперименты (порт /dev/crypto из OpenBSD (www.logix.cz/michal/devel/cryptodev ), патчи в том же openssl, которые вызывают соотв. реализации функций из ядра через аналоги этого /dev/crypto, и т.д.).

Осторожно, одичавший костыль: перед просрочкой автоматически сбрасывать доменный пароль у юзеров с eToken на случайный и нигде не сохраняемый.
serverfault.com/questions/207115/how-do-i-bulk-reset-passwords-for-all-users-in-an-ou
Если юзеру надо будет срочно зайти под доменным паролем, придется ему его еще раз сбросить на известный.

Используйте HTTPS + аутентификацию при помощи SRP-6, как подсказывают коллеги выше.
1. Правильно настроенный HTTPS обеспечит приемлемую защиту канала обмена данными (если пользователи будут минимально сознательны).
2. SRP-6 не дает использовать перехваченные данные повторно и не дает подобрать изначальный пароль на их основе.
Даже если атакующий обойдет SSL, например, получит доступ к закрытому ключу от Вашего серверного сертификата, или от более высокого в цепочке сертификатов, вплоть до корневых, и проведет MITM-атаку, используя легитимный с точки зрения клиентского браузера поддельный SSL-сертификат, то перехваченной информации атакующему будет все равно недостаточно, чтобы аутентифицироваться вместо пользователя.

Вместо SRP-6 можно использовать более слабые стандарты типа htdigest (HTTP digest authentication, rfc2617, есть в апаче из коробки, правда, в самом простом варианте использования это будет для клиента выглядеть как некрасивое стандартное pop-up окно в браузере).

Я вижу два противоречивых пункта в Вашей постановке задачи.
1. Использовать «на любом ПК» — значит, предполагаем, что на «любом ПК» стоит только голая ось, и никаких доп. программ. Поскольку единого стандарта шифрования внешних носителей нет, это грустно.
2. «при подключении надо ввести пароль» — значит, на «любом ПК» уже есть некоторое ПО, которое этот пароль спросит, и далее и передаст его некоторой службе (неважно какой и где), которая уже будет поддерживать собственно шифрование.

Я вижу только один очевидный выход — это ПО надо носить на самой флэшке, на отдельном разделе, например. А раздел с данными шифровать целиком.

Решения лучше TrueCrypt я не видел, хотя аналоги есть — всякие PGP Portable и т.д.

«видны файлы криптографии» — TrueCrypt Hidden Volume Вам в помощь.

Можно сочинить свое аппаратное решение для себя, но это уже перебор.

В качестве сугубо личного генератора паролей можно все, но всегда надо понимать:
1) Какова процедура «Incident response handling» для Вашего решения — что делать, если пришла лисичка и что-то подсмотрела
2) Пароль для системы аутентификации — это то, что знает мистер Х и не знает мистер Y. Без вариантов. Если кто-то знает алгоритм генерации пароля и угадает исходные данные, этот кто-то для системы — Вы.