On Sun, Dec 31, 2000 at 13:11 +0100, Claudia Arnold wrote:
Ich habe da eine kleine Verständnisfrage:
Stimmt. Die Mailingliste nutzt Englisch als "Amtssprache". :) Und vor dem Schreiben eine Weile mitzulesen oder in Archiven zu wuehlen hilft auch eine Menge. Dann stoesst Du auf Literaturlisten, FAQs, etc und koenntest Dir selbst noch schneller helfen als auf Antworten warten zu muessen (die nicht einmal stimmen muessen).
Wenn ein Passwort verschlüsselt ist (z.B. shadow) und man davon ausgeht, daß es Verschlüsselungsverfahren gibt, die nur schwer bzw. (momentan) gar nicht zu knacken sind, wie bekommt dann das System (z.B. bei Login-Passwort) das unverschlüsselte Passwort heraus ???
[ short translation: How will the system determine the clear text password at login / auth time to compare it against the given one when it's stored in encrypted form? ] Well, when you login (or do auth in some other context) the password you provide won't get compared against its original form. It just gets processed the same way as it got processed when you initially set it up and stored it. The assumption is that given the same input (your password) as well as the same algorithm (plus some initial state like SALT or stuff) will result in the same crypted representation. And of course that any deviation in the input (read: a wrong password or different state - think of S/Key - ) will lead to a different result and thus will mismatch. Since the password crypt algorithm is not reversible, the only (technical) form of getting the cleartext equivalent or an successful auth is to use brute force in an enormous trial and error loop. Doing this against a live login(8) program will be almost useless due to the delay every unsuccessful attempt will cause. To add to this every attempt gets logged and will raise some attention. Having access to the encrypted form will give the chance to do this brute force run "off line" and unnoticed. That's the most important motivation to move this field from /etc/passwd to /etc/shadow, where you can set more restictive access parameters. But when you don't protect those sensitive files ... Another method being even more promising is social engineering: What's the cat's birthday? How is the dog named? What's the most favourite word people use? When did they marry? etc pp There's no substitute for thinking and no technical means can solve problems caused by human laziness or even stupidity ...
Das gleiche ist ja auch bei z.B. EC-Karten der Fall. Glaubt man der Bank, so ist es für die Angestellten nicht möglich eine vergessene Geheimzahl nachträglich herauszufinden. Wie schafft es denn dann der Geldautomat herauszufinden, ob ich die korrekte Geheimzahl eingegeben habe ???
[ The bank makes me believe their stuff has no means of getting my PIN back in case I forgot. How does the cash money automat(id?) prove my PIN to be correct? ] The cheque card is quite another topic. Although there are four digits leading to a problem space of 1000 combinations in theory, in practice it's only some 150. And still the clear text password is not stored on the card, but a crypted form thereof. In this particular case the bank believes the algorithm to be secure because "(almost) nobody knows it" -- that's "security by obscurity" and leads to a false sense of security. That's even more dangerous and plain doesn't work, as you can read a few thousand times in the archives. Your only hope / chance is that the card gets blocked after three wrong attempts which makes brute forcing inappropriate, and that the algo really is a secret and will remain so. This should suffice for the risk of loosing "a little money". Unless you write down the password (PIN) on a piece of paper right next to the card or tell it to everyone to ask you. Or even scribble the PIN on the card itself. That's the "Think!" thing, again, see above ... virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.