Најпрво методот EAP: кој хеш на лозинка може да го користи еден VPN
VPN го проверува тајното, а не веб-хешот. Прочитајте го методот, потоа проверете што чува складиштето пред да ветите дека истите лозинки сѐ уште ќе работат.
Многу тимови имаат веб-најава што работи и VPN што ја одбива секоја лозинка од истата табела. Веб-апликацијата споредува хеш што самата го пресметала, додека тунелот бара од клиентот да докаже поседување тајна на начин што серверот мора да може да го провери. Тоа се различни барања кон складираниот материјал. Токму во јазот меѓу нив застануваат повеќето вакви проекти.
Прво прочитајте го методот, потоа шемата
Запишете каков доказ бара избраниот метод пред да погледнете било која шема. Методот предизвик-одговор бара материјал од кој серверот може да го пресмета очекуваниот одговор, што во практика значи лозинката или компатибилна изведена форма. Методот што ја носи лозинката внатре во заштитен тунел бара самата лозинка кај проверувачот. Читајте ја документацијата на методот поради барањето на проверувачот, а не поради конфигурацијата на клиентот, зашто барањата на клиентот обично се лесниот дел.
Солениот хеш што го создава современа веб-рамка не дава ниту едното. Тој проверува една конкретна споредба и не може да се врати во тајната од која настанал.
Предизвик-одговорот не може да користи солен хеш
MSCHAPv2 е размена на предизвик-одговор, па серверот никогаш не ја добива лозинката и не може да спореди складирана низа. Мора да го изведе очекуваниот одговор од материјал што веќе го има, и затоа компатибилните складирани форми се толку тесни. Вредност на bcrypt или Argon2 со сол по корисник е еднонасочна на начин што целосно ја исклучува размената. Табелата подолу започнува од формата на складирање, а не од името на методот, зашто формата на складирање ја одлучува одговорот.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
Документацијата на SQL приклучокот за strongSwan дефинира сопствена шема за конфигурација и акредитиви, а проектот тој приклучок сѐ уште го означува како експериментален. Ништо во неа не се прилагодува на табелата со корисници на некоја апликација ниту претпоставува која шема за хеширање создала складирана вредност. Затоа реалните опции се преселба во складиште што портата може да го користи, или услуга за автентикација пред постојното складиште што може да ја изврши размената. Сето друго е поврзувач со скриена претпоставка внатре во него.
RADIUS го преместува работата, не барањето
Делегирањето на EAP на RADIUS сервер менува каде се врши проверката и обично ја подобрува ревизорската трага. Тоа не враќа лозинка од еднонасочен хеш, па услугата за автентикација сѐ уште бара материјал компатибилен со методот што го завршува. Тимовите го откриваат ова откако ќе го изградат патот преку RADIUS и ќе налетаат на истиот ѕид од другата страна.
Онаму каде RADIUS серверот може да чита директориум со компатибилни акредитиви, решението работи и VPN портата останува едноставна. Онаму каде не може, искрениот одговор е промена на запишувањето, а не уште еден поврзувач. Обезбедувањето и отповикувањето ѝ припаѓаат на онаа страна што го поседува идентитетот, па копирана табела без поддржан процес за синхронизација е втор животен циклус на акредитиви, а не едно најавување. Таа се разидува првиот пат кога некој ќе ја ресетира лозинката само на едно место, и разидувањето е тивко додека сметката што постои во двата система не почне да се однесува различно во секој од нив.
Ограничете ја сметката што го чита директориумот само на тоа читање и држете ја одвоена од сметката што портата ја користи за сопствената конфигурација. Заедничка административна сметка го претвора решението само за читање во многу поширок радиус на штета.
Каде треба да живее сметката
Откако прашањето за материјалот е решено, остануваат две архитектури. Портата може да поседува мало складиште за акредитиви што само таа го чита, или да делегира на услуга за автентикација што стои пред корпоративниот директориум.
Првата е полесна за размислување и полоша за корисникот, кој останува со втора лозинка за одржување. Втората чува еден идентитет и додава зависност од услуга што сега мора да работи пред некој да може да се поврзе. Ниту едната не е погрешна, но изборот треба да се запише до конфигурацијата на портата, зашто инаку следниот инженер ќе претпостави дека е избрана другата. Што и да изберете, двете наредби подолу се тие што ја покажуваат текучката состојба пред да ја промените.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsАвтентикацијата на сметката исто така не ја решава авторизацијата. Членството во групи, состојбата на уредот и мрежната дозвола сѐ уште бараат експлицитно мапирање откако корисникот ќе го докаже бараниот идентитет. Врска што совршено се автентификува и ништо не авторизира е резултат на политика, а не дефект во методот.