Som Thomas säger så är det jättebra tills ett eller två av dessa knäcks eller läcker på annat sätt. Sen är det ett känt mönster och kommer att finnas i dictionaries, och om du är intressant kommer de illvilliga att testa detta mönster på andra ställen med din mail som användare och liknande. Chansen att det knäcks med brute-force är förstås inte så stor men man kan ju inte veta att alla tjänster man har konto på har bra säkerhet.
Jag har tidigare jobbat med tjänster som allmänheten hade tillgång till. Vi hade för tiden rätt bra säkerhet (ur denna aspekten i alla fall) med hashade lösenord med salt och så, utom i ett system där kunden krävde krypterade lösenord och fick det. Detta var förstås katastrof för säkerheten, inte minst för att krypteringsnyckeln låg i samma DB. Men web-appen hade också ett enormt hål för alla övriga kunder som är fixat sedan dess, att funktionen för att validera lösenordet, som alltså hashade vad användaren skrev in och matchade det mot värdet i databasen, testade "o-hashat" om inte det hashade stämde. Tanken var att utvecklaren kanske redan hade hashat någon annanstans, och web-appen tog ju inte in så långa lösenord som en hash, men det var ju inte svårt att typ med postman eller något bara anropa API:t direkt. Så om man fick tag i databasen på något sätt, så behövde man inte knäcka lösenorden utan man kunde bara använda dem direkt.
En annan aspekt är ju att lösenord betraktas som kritiska, men felaktiga lösenord inte alltid gör det. Så om man kollar i exempelvis IIS-loggar så kan man se att en person försökt logga in tio gånger innan den lyckades och vad det felaktiga lösenordet var i klartext för varje försök. Detta gör det förstås enkelt att gissa vad den har som lösenord till denna sida, men det gör också sådana typer av mönster lätt igenkännbara.
