jr@amanue.UUCP (Jim Rosenberg) (11/29/88)
Well now, net folk, since we're talking about good and bad ideas for passwords,
how does this idea strike you. (1) Restrict all passwords to a *MAXIMUM* of
4 characters. (2) *PROHIBIT* anything but digits from appearing in a password.
Isn't this nifty? You're probably thinking I'm a nut case.
Well surprise: This exact password system is ***IN USE***!!! In (are you
ready:) ***BANKS***!!! I am not kidding. Do you have an Automatic Teller
Machine card? What does your password look like? Every time I've been given
one of those things the password was just 4 digits!!!!!!!
And we think *WE'VE* got problems!
--
Jim Rosenberg
CIS: 71515,124 decvax!idis! \
WELL: jer allegra! ---- pitt!amanue!jr
BIX: jrosenberg uunet!cmcl2!cadre! /ekrell@hector.UUCP (Eduardo Krell) (11/30/88)
In article <438@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: >Well surprise: This exact password system is ***IN USE***!!! In (are you >ready:) ***BANKS***!!! I am not kidding. Do you have an Automatic Teller >Machine card? What does your password look like? Every time I've been given >one of those things the password was just 4 digits!!!!!!! I don't know about your bank, but mine will take away your card if you enter the wrong PIN something like 3 or 5 times in a row (the ATM will eat the card). Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
barmar@think.COM (Barry Margolin) (11/30/88)
In article <10900@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >In article <438@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: [ATM passwords are 4 digits] >I don't know about your bank, but mine will take away your card if you >enter the wrong PIN something like 3 or 5 times in a row (the ATM will >eat the card). Even without this, there are other safeguards. First and foremost, the perpetrator needs your card. Of course, if he has your card he doesn't really need to guess your password, since it is encoded on the card, so if he knows what he is doing he can simply change it. If he doesn't have your card, but has instead manufactured a forged card, he doesn't need your password since he can put whatever password he wants on it. I may be wrong about the password being on the card. In that case, there is still another piece of security: the only interface an outsider has is the ATM. In the case of Unix, if someone can read the encrypted passwords he can run a program to try lots of passwords very quickly. With an ATM you can't download the encrypted passwords, so you would have to stand there typing in passwords. If you could enter a password every second it could take three hours to find a password. If the ATM spits out the card after a couple of bad passwords (as I think mine does) this could slow you down by an order of magnitude. When there isn't a means for trying passwords at high speed, as there is in Unix (without shadow password files), it isn't as important to make the password namespace really large. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
lbr@holos0.UUCP (Len Reed) (11/30/88)
From article <438@amanue.UUCP>, by jr@amanue.UUCP (Jim Rosenberg):
= Well now, net folk, since we're talking about good and bad ideas for passwords,
= how does this idea strike you. (1) Restrict all passwords to a *MAXIMUM* of
= 4 characters. (2) *PROHIBIT* anything but digits from appearing in a password.
=
= Isn't this nifty? You're probably thinking I'm a nut case.
=
= Well surprise: This exact password system is ***IN USE***!!! In (are you
= ready:) ***BANKS***!!! I am not kidding. Do you have an Automatic Teller
= Machine card? What does your password look like? Every time I've been given
= one of those things the password was just 4 digits!!!!!!!
You have to have physical possession of the card, too, not just knowledge
of the account number. The "password" merely stops someone from using
the card between the time it is stolen and the theft is reported to
and dealt with by the bank. It's a backup to the main security stategy--
possession of the card. Not exactly the same thing as a computer system
with dial-in capability.
The banks around here have a "three strikes and you're out" rule. If you
put the card in and fail three times to get the password right the
machine keeps the card.
BTW, I do think you're a nut case.
--
- Len Reednick@ccicpg.UUCP (Nick Crossley) (12/01/88)
In article <10900@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >In article <438@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: >>Well surprise: This exact password system is ***IN USE***!!! In (are you >>ready:) ***BANKS***!!! I am not kidding. Do you have an Automatic Teller >>Machine card? What does your password look like? Every time I've been given >>one of those things the password was just 4 digits!!!!!!! > >I don't know about your bank, but mine will take away your card if you >enter the wrong PIN something like 3 or 5 times in a row (the ATM will >eat the card). > >Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ But, in the UK at least, if you abort the 'login' attempt after the 2nd attempt (there is a button to do this), you get your card back, and can then try again immediately. Thus you have an unlimited number of attempts. I have not tried this on a machine in the US. I have often wondered about the four-digit limit anyway - surely even some branches must have close to 9999 accounts, let alone whole banks. That does make the code number very unique. This no longer has much to do with Unix. -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick
crossgl@ingr.UUCP (Gordon Cross) (12/01/88)
In article <32305@think.UUCP>, barmar@think.COM (Barry Margolin) writes: > > Even without this, there are other safeguards. First and foremost, > the perpetrator needs your card. Of course, if he has your card he > doesn't really need to guess your password, since it is encoded on the > card, so if he knows what he is doing he can simply change it. If he > doesn't have your card, but has instead manufactured a forged card, he > doesn't need your password since he can put whatever password he wants > on it. As I understand it, the only thing encoded on the card itself is the card number (the UNIX equivalent of a user name). The card holder must supply his secret number which the ATM forwards (along with the card number) to the bank's central computer for verification. Presumably this information is encrypted to prevent someone from tapping the transmission... Gordon Cross Intergraph Corp. Huntsville, AL ...uunet!ingr!crossgl
john@anasaz.UUCP (John Moore) (12/01/88)
In article <32305@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: ]In article <10900@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: ]>In article <438@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: ][ATM passwords are 4 digits] ]>I don't know about your bank, but mine will take away your card if you ]>enter the wrong PIN something like 3 or 5 times in a row (the ATM will ]>eat the card). ] ]Even without this, there are other safeguards. First and foremost, ]the perpetrator needs your card. Of course, if he has your card he ]doesn't really need to guess your password, since it is encoded on the ]card, so if he knows what he is doing he can simply change it. If he ]doesn't have your card, but has instead manufactured a forged card, he ]doesn't need your password since he can put whatever password he wants ]on it. The password is stored on the card encrypted with DES. If you don't know the key, you can't write a password onto the card AND know what it is. ] ]you would have to stand there typing in passwords. If you could enter ]a password every second it could take three hours to find a password. ]If the ATM spits out the card after a couple of bad passwords (as I ]think mine does) this could slow you down by an order of magnitude. Often the ATM will eat the card if it detects a possible security violation (more than 3 tries at a PIN, etc) -- John Moore (NJ7E) {decvax, ncar, ihnp4}!noao!nud!anasaz!john (602) 861-7607 (day or eve) {gatech, ames, rutgers}!ncar!... The opinions expressed here are obviously not mine, so they must be someone else's. :-)
fyl@ssc.UUCP (Phil Hughes) (12/02/88)
In article <1526@holos0.UUCP>, lbr@holos0.UUCP (Len Reed) writes: > From article <438@amanue.UUCP>, by jr@amanue.UUCP (Jim Rosenberg): > = Well surprise: This exact password system is ***IN USE***!!! In (are you > = ready:) ***BANKS***!!! I am not kidding. Do you have an Automatic Teller > = Machine card? What does your password look like? Every time I've been given > = one of those things the password was just 4 digits!!!!!!! > You have to have physical possession of the card, too, not just knowledge > of the account number. Not really true. If you are serious about ATM fraud you can buy a mag stripe writer for about $300. I used to work for a company that makes automatic gas station equipment -- stick in your card, punch in your PIN and pump gas. We bought a card writer. I made myself an extra EXCHANGE card. Sort of fun. By the way, track 2 on the cards is the account number. Most bank machines either ignore or display track 1. Rainier Bank locally puts your name on track one and displays it on the terminal. Rewrite track 1 and when you enter your card you can get a nice message like: GOOD AFTERNOON YOU ROTTEN CROOK on the display. It amuses the people waiting in line behind you. Now, for a worse story -- as of two years ago every ATM machine in a whole state would accept a particular 4 digit number as a valid pin for every card. Yes, really. I was doing testing on a controller to hook into their network and it wasn't getting invalid PIN errors. As it turned out there was a bug in our software and it wasn't sending the PIN that was being entered. It just happened to be sending the magic PIN for the network. Now that was really stupid. -- Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX uw-beaver!tikal!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fyl
glf@munnari (Giuseppe Fiusco) (12/02/88)
From article <43034@ccicpg.UUCP>, by nick@ccicpg.UUCP (Nick Crossley): > In article <10900@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >>Well surprise: This exact password system is ***IN USE***!!! In (are you >>ready:) ***BANKS***!!! I am not kidding. Do you have an Automatic Teller >>Machine card? What does your password look like? Every time I've been given >>one of those things the password was just 4 digits!!!!!!! > > But, in the UK at least, if you abort the 'login' attempt after the 2nd > attempt (there is a button to do this), you get your card back, and can > then try again immediately. Thus you have an unlimited number of attempts. > I have not tried this on a machine in the US. I do not know about England but given the various machines that I have used only tend to give the users 3 goes whether they cancel or not. This gives the user the chance to cancel and check in some way thier ID but does not allow someone to continually attempt to use the card by trying to guess the number. This can be dependant on whether the ATM is on or off line to the bank. > I have often wondered about the four-digit limit anyway - surely even some > branches must have close to 9999 accounts, let alone whole banks. That does > make the code number very unique. Passwords never need be too unique as they are tied to the id of the requester and the methodolgy used to gain access to the protected enviroment. For ATM's the four digit number is reasonable Now this really has nothing to do with UNIX :-) Giuseppe Fiusco Department of Computer Science , University of Melbourne, Parkville, Victoria 3052, Australia VOICE: (03) 344 7415 (International: +61 3 344 7415) ACSnet: glf@munmurra.mu.oz UUCP: {uunet,mcvax,ukc,ubc-vision}!munnari!munmurra.mu.oz!glf ARPA: munnari!munmurra.mu.oz!glf@uunet.css.gov CSNET: glf%munmurra.mu.oz@csnet-relay
stefan@mikros.systemware.de (Stefan Stapelberg) (12/02/88)
In article <43034@ccicpg.UUCP> nick@ccicpg.UUCP (Nick Crossley) writes: > >I have often wondered about the four-digit limit anyway - surely even some >branches must have close to 9999 accounts, let alone whole banks. That does >make the code number very unique. Long time ago, I coded a program for creation of PIN numbers on credit cards. The PIN number is encoded with another number identifying the card's holder. The whole combination isn't four digits (I don't remember how much digits there are finally). Some people safely may share the same PIN number. This can't be compared to UNIX passworts, since you must have the *card* and the PIN to break someone's "account". -- Die schaerfsten Kritiker der Elche waren frueher selber welche. -- Traxler
tim@scsmo1.UUCP (12/03/88)
>But, in the UK at least, if you abort the 'login' attempt after the 2nd >attempt (there is a button to do this), you get your card back, and can >then try again immediately. Thus you have an unlimited number of attempts. >I have not tried this on a machine in the US. This will work in the U.S. Some machines will kick the card out after 3 incorrect tries. One machine I tried 8 times, it didn't take the card, but later after the card had been slightly mutated it took it. I had the number changed on my card, there was an ibm pc connected to a card reader. I typed in the number (on a seperate keypad) and the banker slid the card back through the card reader. The pc was _NOT_ connected to anything. >This no longer has much to do with Unix. But it does have to do with money. How about terminals that have card readers? The biggest security problem is users that don't think about security problems, They tell other users their passwords (the don't like using paths to get files) Tim Hogard tim@scsmo1.uucp Soil Conservation Service.
ccdn@levels.sait.edu.au (DAVID NEWALL) (12/03/88)
In article <3057@ingr.UUCP>, crossgl@ingr.UUCP (Gordon Cross) writes: > As I understand it, the only thing encoded on the card itself is the card > number (the UNIX equivalent of a user name). The card holder must supply > his secret number which the ATM forwards (along with the card number) to the > bank's central computer for verification. Presumably this information is > encrypted to prevent someone from tapping the transmission... It is not possible for ATMs to be on-line *all* the time. There are many reasons for this, one of which is, I believe, scheduled downtime. However, even when the ATM is off-line, it still functions (although some functions, account balance enquiry for example, are unavailable). From this I conclude that the PIN can be verified from information recorded on the card. I guess that *my* PIN is encrypted, and stored on the card, although milage may vary from bank to bank. One hopes that the encryption mechanism used is kept secret. David Newall Phone: +61 8 343 3160 Unix Systems Programmer Fax: +61 8 349 6939 Academic Computing Service E-mail: ccdn@levels.sait.oz.au SA Institute of Technology Post: The Levels, South Australia, 5095
nick@ccicpg.UUCP (Nick Crossley) (12/06/88)
In article <1096@murtoa.cs.mu.oz.au> glf@munnari writes: >From article <43034@ccicpg.UUCP>, by nick@ccicpg.UUCP (Nick Crossley): >> I have often wondered about the four-digit limit anyway - surely even some >> branches must have close to 9999 accounts, let alone whole banks. That does >> make the code number very unique. > >Passwords never need be too unique as they are tied to the id of the requester >and the methodolgy used to gain access to the protected enviroment. >For ATM's the four digit number is reasonable > and another poster made a similar comment. This does not make me feel any happier. If the password is not sufficiently unique, it has little value. If all passwords were the same (the digit '1'), then loss of your ATM card would be serious, as any person finding it could use it. If all passwords were drawn from a sufficiently small set, then the same applies. This is more or less what the Unix password debates have been about, and (presumably) what led the original poster to comment on ATM systems. We are trying to encourage Unix users to use non-obvious passwords from a potentially very large set, and there are versions of passwd which try to ensure the user does not limit himself to a small alphabet. At the same time, here is a much larger user base than Unix users, trusting money to a very small password set. I realise that there are differences; Unix users choose their own (easily guessed) passwords, banks/computers choose those for ATMs, etc. But... -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick
nelson@ishmael (12/07/88)
The BayBanks system (Eastern Mass.) lets you pick your own password up to 6 characters long (they use a telephone-like alphabet/numeric scheme). I was rather surprised, however, to discover that only the first 4 characters of my 6 character password are checked. In fact, I heard of a case where someone had lost their card and whose account was subsequently pilfered. As a password she had used the first 4 letters of her name followed by two dummy letters. I realize that this is pretty far from Unix, but there is a lesson somewhere. If nothing else, BayBanks users beware. - Nelson Nelson Lerner uunet!inmet!nelson nelson@inmet.inmet.com
allbery@ncoast.UUCP (Brandon S. Allbery) (12/13/88)
As quoted from <43908@ccicpg.UUCP> by nick@ccicpg.UUCP (Nick Crossley): +--------------- | I realise that there are differences; Unix users choose their own (easily | guessed) passwords, banks/computers choose those for ATMs, etc. But... +--------------- At least some banks let the applicant for an ATM card select his/her own PIN (password). Which makes things rather worse. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.