Ennek legvalószínűbb oka az, hogy a rendszer megcsonkítja a jelszavakat. Ennek a hipotézisnek az ellenőrzéséhez megpróbálhatja megváltoztatni a jelszavát valamivel hosszabbra, és megnézni, mi történik: felismeri a rendszer az "ezt a hosszú jelszót" "ennek a hosszúnak"? Ha igen, a rendszer határozottan csonkolja a jelszavakat. Ha nem, akkor komoly problémák merülhetnek fel a bemeneti hitelesítéssel kapcsolatban, amire a @Matthew rámutatott.

Bár a jelszócsonkolásra szükség lehet a régi rendszerekkel való együttműködéshez - amelyek a felhasználóneveket is csonkolják, lásd ezt a választ a Serverfault-on - általában kerülni kell, mivel csökkenti a "jelszóteret", vagyis a létrehozható egyedi jelszavak számát.

A támadók rengeteg erőforrást (időt, pénzt) spórolhatnak meg, ha tudják, hogy a célrendszerük csonka jelszavakat használ, mivel tudják, hogy nem kell a csonka hossznál hosszabb jelszavakat kipróbálniuk.

Bár a viselkedése nem tűnik számomra rosszindulatúnak, néhány szervezet nagyon érzékeny arra, hogy az emberek hibákat találnak a rendszerükben.

Ezért megpróbálhatja elmondani erről az egyetemének, de ne tegye. Ne hangsúlyozza túlságosan a tudását a lehetséges támadásokról. Csak annyit mondani, hogy "Olvastam, ez biztonsági kérdés jele lehet", rendben van. Ezenkívül ne állítson abszolút módon olyan dolgokat, mint "ez teljesen ésszerűtlen", mivel ennek oka lehet (jelszócsonkolás, nem pedig a helytelen bemeneti ellenőrzés).

Nyilvánvaló, hogy ne végezzen túl sok teszt, ne automatizálja a teszteket, és ne hajtson végre támadásokat.

Ez azt sugallhatja, hogy bármely használt jelszó-elosztási rutin vagy megcsonkítja a bemenetet (csak a jelszó első x karakterét használja), vagy a helyes jelszavak összehasonlítása rosszul valósult meg, és csak az első részt hasonlítja össze (ez a jelszavak tárolására használt blokkos titkosítást, vagy a nyers jelszavak tárolását jelentheti).

Egyik helyzet sem különösebben jó.

Csonka esetén hamis értelmet ad a biztonság kedvéért - lehet, hogy hosszú véletlenszerű jelszót választott, de ha csak az első néhány karaktert használjuk, akkor ez közel sem olyan biztonságos, mint gondolnánk, és ennélfogva egy durva erő támadásában kitalálható könnyen. Remélem, hogy ez volt az esélyesebb magyarázat.

Gyenge összehasonlítási rutin esetén ez arra utal, hogy a hitelesítési rutinért felelős fejlesztő nem ismerte a biztonságos fejlesztési gyakorlatokat. Részleges összehasonlítás használatával (pl. SELECT * FROM users WHERE 'felhasználónév LIKE' $ username% 'ÉS' jelszó LIKE '$ password%' ) ismét növeli a durva erő támadásainak esélyét , de azt is sugallja, hogy más hibákat is elkövettek: a fenti példa alapján az a 'OR 1 = 1' - jelszó potenciális beállítása SQL injekciós támadást eredményez. Nyilvánvaló, hogy ez egy kissé kitalált példa, de nem haladja meg a lehetőségek lehetőségeit.

Abban az esetben, ha blokk titkosítást használnak, és nem jelszó-kivonatoló algoritmust, akkor az adatbázisban megengedett hosszúság lehet elégtelen hosszú jelszóért, egyszer titkosítva. Valójában ez a csonkolás, de a titkosított adatok helyett a bemenet. A véghatás azonban ugyanaz: hosszú jelszó megadása hamis biztonságérzetet ad.