informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/magazines/INFORMATIK/inform-2.phk

3752 lines
173 KiB
Plaintext
Raw Blame History

+=============================================================================+
| ## ## ## ###### ###### ###### ### ### ###### ###### ## ## ## |
| ## ### ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## |
| ## ## ### ##### ## ## ###### ## ## ###### ## ## #### |
| ## ## ## ## ###### ## ## ## ## ## ## ## ## ## ## |
+=============================================##==============================+
| Jan 10, 1992|
| [ The Journal of Privileged Information ] |
| |
+-----------------------------------------------------------------------------+
| Issue 02 By: 'Above the Law' |
+-----------------------------------------------------------------------------+
| |
|Informatik--Bringing you all the information you should know... |
| and a lot you shouldn't... |
| |
+=============================================================================+
/* Introduction */
By the Informatik staff
Well, we're proud to present Issue #2 of Informatik Journal.
Issue #1 was very well received, and we hope to continue to get good reviews
>from our readers.
This issue once again includes articles on a variety of subjects
related to hacking and phreaking, along with a special report on HoHoCon
1991. Both of our editors were on hand at the Con, which was not to be
missed.
Please note, the Internet address "@shake" found in some releases of
Informatik #1 no longer exists, and the owner is not affiliated with this
journal, and mail should NOT be sent there. We are happy to announce that we
have obtained a permanent Internet address. The address is:
inform@doc.cc.utexas.edu
Please direct submissions, suggestions, and subscription requests to that
address. Our subscription and submissions policies are included in this
issue.
Informatik can also be obtained via FTP at the CUD archives, which
are at the following address:
ftp.cs.widener.edu
Informatik is in the directory /pub/cud/misc. Back issues of Informatik,
along with many other t-files, including Phrack, CUD, and NIA can be found
at the site.
Enjoy,
Mack Hammer & Sterling
[Editors]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
*DISCLAIMER*
Informatik Journal is printed for informational purposes only. We
do not recommend or condone any illegal or fraudulent application of
the information found in this electronic magazine. As such, we
accept no liability for any criminal or civil disputes arising from
said information.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
===========================================
============== - CONTENTS - ===============
================ Issue 02 =================
======= Release date January 10, 1991 =====
===========================================
01) Issue #2 Introduction
By: Mack Hammer & Sterling
02) HoHoCon 1991
By: Mack Hammer
03) The HP3000's 'SECURITY/3000' system (part 1)
By: Sterling
04) Inside NORAD
By: Anonymous NORAD Insider
05) Magnetic Strip Technology
By: Count Zero
06) Tid-Bytes
By: the Informatik Staff
07) Hot Flashes--The Underground News Report
By: Various Sources
08) Submission and Subscription Information
By: the Informatik Staff
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
::*::*::*::*::*::*::*::*::*::*::*::*::*::*::*::
:*: :*:
:*: HohoCon '91: The Sordid Details :*:
:*: :*:
:*: by: Mack Hammer :*:
:*: :*:
::*::*::*::*::*::*::*::*::*::*::*::*::*::*::*::
December 27 - 29, 1991, Houston was invaded by some 80 plus hackers
and telecommunications enthusiasts from around the country. HohoCon '91 was
a marked success, unlike its predecessor, HohoCon '90. The con, sponsored by
NIA and dFx, was very well organized, with Drunkfux, Judge Dredd, and Lord
MacDuff taking the brunt of the organizing on their shoulders. Vision was
also acknowledged as one of the organizers, but was out of town and couldn't
make the Con.
The Con was held at the Airport Hilton near Intercontinental Airport
in Houston, Texas, and was a three-day event, although almost all of the
business was taken care of on Saturday the 28th. Thanks to the organizers'
securing an entire wing separate from the rest of the hotel and a large
conference room, the conferees went unmolested for the whole of the weekend.
Friday the 27th
~~~~~~~~~~~~~~~
Most of the guests started arriving during the afternoon of Friday
the 27th. After laying around/getting acquainted for most of the day,
Hunter (who provided valuable assistance with entertainment all weekend)
contacted Rogue, who provided spirits (at cost) for the night. After
bringing in some 300 dollars worth of hard liquor, the party began.
While the events that ensued that evening are somewhat foggy for
this writer, I will attempt to detail some of the highlights. Everyone
wandered in and out of the conference room (where the liquor was located)
and basically got smashed and swapped hacker war stories. It was then that
Doc Cypher made the unofficial introductory address of the Con. The entire
group cheered and jeered as Doc, in a drunken stupor, took a nostalgic look
back at some of the great NUIs, systems, services, etcetera that marked
hacking in the Eighties.
The party then moved to the room of MC Allah (who was passed out on
the bed after drinking beer all day and capping it off with some mixed
drinks that night). A VCR was set up, and a group of about 20 people
watched "Necromantic," a European porn flick featuring, you guessed it, the
dead. After the movie, everyone split up and either went to bed or drank
the night away, talking about the old times.
Saturday the 28th
~~~~~~~~~~~~~~~~~
The actual conference was scheduled to begin at noon on Saturday,
but due to massive hangovers, was postponed until 2 pm. At 2 pm somewhere
between 80 and 100 people made their way into the conference room to hear
speeches by various members of the hack/phreak community.
Drunkfux started things off with a few introductions and some
general announcements about the Con, and then introduced Bruce Sterling, the
first speaker. Bruce, the writer of several cyberpunk novels including his
most recent release, The Difference Engine (with William Gibson), was basically
the celebrity of the Con, and spoke as a member of the Austin Branch of the
Electronic Frontiers Foundation. As you should know, the EFF is concerned with
protecting the civil liberties of computer users and telecommunications
enthusiasts. Mail can be sent to the EFF at eff.org, or the Austin Branch can
be contacted at eff-a.tic.com.
The next speaker was Steve Ryan from World View Magazine. World
View is an electronic magazine which also concerns civil liberties,
especially those involving computers. One of the primary concerns of the
magazine's writers is freedom of speech, and Steve spoke about the
suspension of this right during the sixties, and warned that it may happen
again.
The guys from Phrack (Crimson Death and Dispater) then took the
podium and basically told the story of what had been going on with Phrack
over the last year or two. They explained the editorial conflict
surrounding Phrack 34, and gave everyone a short history of who had edited
Phrack when. Crimson Death and Dispater finally put to rest any controversy
concerning Phrack, and did an excellent job of clarifying the situation.
They also explained why Phrack has "sucked" as of late, blaming it on poor
submissions. Now that the editorship is once again on stable ground, we're
once again expecting big things from hacking's most famous electronic
publication.
Everyone's favorite ex-LODers, Chris (Erik Bloodaxe) and Scott (Doc
Holiday) were the next speakers. Now known as Comsec Data Security, and
trying to shake that evil hacker stigma, Scott and Chris have joined
corporate America as security consultants. The two explained that they
hadn't gotten an especially warm welcome from anyone already in the security
field, and that they had been blackballed by every trade organization.
Rather than taking advantage of the huge body of knowledge possessed by the
ex-hackers, established security experts and publications have chose to
ignore them due to their colored past. Furthermore, it seems that they have
also been spurned by much of the hacking community. Overall, the speech
provided an interesting look into the way the computer security field
operates, and was very reassuring to the hackers still on the other side of
the fence. Scott and Chris did report, however, that business was good.
They then shifted gears and reported on New York's MOD, perhaps the most
unpopular group in the history of hacking. First they reported on MOD's
activities in general, ie; the posting of personal information of other
hackers on IRC and Lutzifer, general harassment of many noted members of the
hacking community, and the destructions of private systems on various
networks. They then announced the best news of the day, five MOD members
(including Corrupt, Phiber Optik, and Outlaw) were raided on December 6.
After the Comsec guys finished their speech, Count Zero of RDT
presented a film, starring himself and the other RDT guys, exploring the
campus of MIT. The film included extensive footage of the steam tunnels
running under the campus, and a great shot of a physical plant employee.
After the MIT film, about a third of the attendees left, and the
conferees who remained saw the episode of "And Now It Can Be Told" about
hackers. Geraldo Rivera, along with just about everyone else on the show,
got a lot of boos and hisses from the crowd.
The conference then took about a four hour lull while everyone ate,
drank, and watched the pay-per-view channels for free (see Tid-Bytes for
more info). About 9 pm, Hunter and Rogue once again came through with the
liquor, and yet another night of revelry began. Everyone once again began
to indulge heavily in the alcohol, and most of the conferees staying in the
hotel found their way into the hallway, where a horrified couple was being
hustled from our wing. The couple, mistakenly assigned to the HohoCon wing
by the hotel staff, was quite amazed to find some 40 odd drunken and raucous
hackers partying in the hallways.
Just when things once again died down a bit, Hunter came through
once again, this time with a couple of strippers he picked up somewhere.
While the live performance put on by the strippers couldn't compare with
Necromantic, it was the main entertainment of the night. Eventually,
everyone ended up either going to bed or working on CDC File #200, and
HohoCon '91 was all but through.
Sunday the 29th
~~~~~~~~~~~~~~~
As always, there wasn't much going on Sunday, with most people
checking out and departing for home. Overall, it seems that HohoCon '91 was
a smashing success, and we're looking forward to next year.
Now... for the first annual...
:: Informatik HohoCon Awards ::
Least constructive use of time:
Crimson Death, for watching approximately six hours of pornos free of
charge on Saturday night.
Most disgusting drink:
Ronnie, who mixed rum, tequila, grenadine, blue Hawaiian mix, vodka, and
lime juice.
Hard-day's-night award:
M.C. Allah, for drinking all day, drinking most of the night, passing
out, and puking on his hotel room floor and Siegfried's foot.
Most distasteful video presentation:
Erik Bloodaxe, for showing the most vile porno known to man,
Necromantic.
Should have been drowned in the pool award:
Rou Tisten, the most annoying personality in the world and a voice to
match.
Hard Luck Award:
The whole crew from Memphis whose transmission went out in their truck.
I sure hope you made it home, guys.
I get paid for this? Award:
Wile E. Security Guard. For marching around our wing approximately
11,000 times and never saying ANYTHING about our raucous conduct.
Logistical genius Award:
The guy who put the Baptist-Revival-Worship-Meeting-Thing next to the
Con on Friday night.
:: Unofficial HohoCon '91 Guest List ::
Allanon Lord MacDuff
Amateur M.C. Allah
Analog Assassin Mack Hammer
Archangel Macross the Black
Battery Material Man
Beowulf Minor Threat
Black Night Misanthrope
Bryan O'Blivian Morpheus
Bundy Mustang
Cabbage Truck Nihilator
Chizz Omega
Circle Jerk Phaedrus
Colin Campbell Psionic Infiltrator
Count Zero Purple Hayes
Count Zero Rambo
Crimson Death Razorback
Cross Connect Rev. Scott Free
Cyndre The Grey Rogue Lord of the Swastika
Dark Piper Ronnie
Devereuax Rou Tisten
Dispater Search 'n Seizure
Doc Cypher Siegfried
Doc Holiday Snow Blind
Drunkfux Split
Elrond of Rivendell Spoink
Erik BloodAxe Sterling
Format C: Swamp Rat
Frosty Technysis
G.A. Ellsworth Terminator
Holistic Hacker Terry-Scientist of Confusion
Hunter The Brain
Informant The Butler
Jabba The Chairman
Joe Rockhead The Conflict
Johnny Rotten The Desert Fox
Judge Dredd The Master
Junk Master The Pope
Kable Borks The Prisinor
Knightlife White Knight
Loki Winter's Ice
Please note: This list was compiled mainly from a sign-in sheet passed
around at the conference on Saturday. If you missed being
on the list, we apologize.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>*>
*> <*
<* The HP3000's 'SECURITY/3000' System (part 1) *>
*> <*
<* by Sterling *>
*> <*
<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<*<
SECURITY/3000 is a third party security package for use on HP 3000 series
computers. It replaces several commands and bundles several utility programs
to monitor system security. In part 1, I will try to provide an overview of
the obstacles that the SECURITY/3000 package presents for any would be
intruders, and discuss the usages of the LOGON system.
SECURITY/3000 is popular because it attempts to shore up the security
weaknesses found in the basic HP MPE Operating System. In order to insure user
ID integrity, HP's logon security system uses passwords. However, these
passwords provide only an illusion of security because:
* There is only one password for each level (user, group, or
account) of security. Thus, knowledge of this password
guarantees that level of security is penetrable.
* On many HP3000 systems, several users log on with the same
USERNAME.ACCTNAME which means they share the same
passwords--this reduces security and provides no auditability.
* Many users treat passwords as a dispensable nuisance, and
therefore readily reveal their passwords to unauthorized
persons.
* Passwords are stored in the system in clear text. Thus, they
may be readily found in job streams, discarded LISTDIR
listings, or on :SYSDUMP tapes.
SECURITY/3000 provides several new features:
USER ID INTEGRITY
~~~~~~~~~~~~~~~~~
In addition to conventional MPE passwords, SECURITY/3000 can use a system of
personal profile passwords -- answers to personal questions such as "WHAT IS
YOUR MOTHER'S MAIDEN NAME?", "WHAT IS YOUR FIRST LOVE'S NAME?", etc. Instead
of asking the same question all the time, SECURITY/3000 asks a random one out
of a number of questions (up to 30, user-configurable). And, instead of
keeping the answers stored in clear text, it encrypts them using a special
one-way encryption system, through which the answers cannot be decrypted by
anybody (not even VESOFT). By this, DP personnel are relieved of problems
associated with having readable passwords on the system.
Thus, passwords are automatically given a psychological security significance;
knowledge of all personal passwords is required to be sure of being able to
access the system, even though the user is asked only one at logon time; and,
passwords are made impossible to determine. Even voluntary disclosure is made
difficult. (The default questions can be configured with custom ones, or
SECURITY/3000 can be configured to instead prompt for a single question rather
than a random personal question).
Furthermore, SECURITY/3000 can be configured to differentiate users by session
name by expanding the USER ID to include session name in addition to user and
account name. This feature permits a better account structure by allowing
"generic" users to be created with user names describing the users' function
and session names identifying the user (e.g. JOHN,ENTRY.PAYROLL and
MARY,CLERK.AP). Thereby, several users could be set up under a common user
name but with different session names, and each one would have unique personal
profile answers, time and day restrictions, menu files, etc. SECURITY/3000
can therefore enforce the use of correct session name by requiring that a user
logs on using the same session name which was configured when added to the
security system.
In addition, SECURITY/3000 permits the system manager to configure a user with
a wildcard ("@") representing the session name and/or user name and/or account
name, which allows authorization of an Account Manager to log on as any valid
user in his account, or the System Manager to log on as any valid user on the
system, or an ordinary user to log on to several different accounts, etc.
This permits greater flexibility while still maintaining a high level of
security and providing positive user identification.
SECURITY/3000 may be activated for the entire system, for selected accounts,
for only certain users, or for only those logons to certain LDEVs (terminals,
DIAL-UPs, DS lines, etc.).
TIME OF DAY, DAY OF WEEK, AND TERMINAL RESTRICTIONS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Most security violations will not occur on Tuesday afternoon at 2:30 in the
middle of the company's payroll department; they will most likely be done in
the dead of night on a weekend across a telephone line. If the payroll
clerks work only on weekdays from 9 to 5 on terminals 31, 32, 33, and 35, any
attempt to access the PAYROLL account at any other time from any other place
is inherently a security violation. HP's logon security system does not
protect against this, but SECURITY/3000 does!
LOGON MENUS VS ':'
~~~~~~~~~~~~~~~~~~
After a user has logged on successfully, it is often undesirable, for reasons
of security and/or user-friendliness, for the user to converse with MPE by
typing MPE commands. Rather, one would want a menu of allowed commands and
programs the user is permitted to access to be displayed on the terminal;
then, the user could choose one of them.
Of course, restricting users from MPE (so that they never get a ':') vastly
improves system security because users are prevented from attempting to breach
security using various "holes" existing in MPE (e.g. :FCOPYing a file
containing a password to the terminal, reading passwords in :RELEASEd job
streams [a hole that doesn't exist if the supplied STREAMX utility is
installed] or even doing :LISTFs in sensitive groups and accounts).
This approach is far more common than the often-used method of blocking out
MPE commands by setting up UDC's with the same name, (which can be
circumvented with little effort, such as executing the commands from within
EDITOR or FCOPY) because it is far easier to implement and maintain a system
which INCLUDES the things a user is allowed rather than EXCLUDES the things a
user is not allowed.
VIOLATION REPORTING
~~~~~~~~~~~~~~~~~~~
Unlike HP's logon security system, which reports security violations only to
the system console, SECURITY/3000 reports them to the system console (in
inverse video, to distinguish them from ordinary console messages), prints a
user-definable memo to the system line printer, and logs them to its own log
file for future reference (thus providing a permanent record for further
interrogation). This "three-alarm" system makes sure that attempted security
violations are acted upon, not ignored. [supposedly]
AUDIT TRAIL
~~~~~~~~~~~
Although an Account Manager ID should be able to add, change, or remove user
security within his own account, there must be some means provided to keep
track of his actions. Under HP's logon security system, an Account Manager
ID can be used to create a fictitious user ID, log on to the system under it,
and do something that he shouldn't be doing without being afraid of getting
caught. With SECURITY/3000, all user additions, changes, and deletions are
logged to the SECURITY log file, thus allowing an auditor or System Manager
to determine who created, altered, or removed a given user ID.
ENFORCING REGULAR PASSWORD CHANGES BY OBSOLETING MPE PASSWORDS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OBSOL, SECURITY/3000's MPE Password Obsolescence System, ensures that MPE
passwords are changed on a regular basis, which can be defined for each
password. Users are warned before a password will expire (configurable as to
the number of days) to get their password changed.
PERMITTING USERS TO CHANGE THEIR OWN MPE PASSWORDS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MPE's security makes changing user passwords quite difficult. Since only an
Account Manager can change a user password, changing passwords is actually
discouraged! A user will feel reluctant to take the time to get hold of his
Account Manager to have his password changed (even if he, the user, suspects
it has been compromised); an Account Manager is very likely to put off
changing passwords if it means changing them for all 100 users in his account.
The SECURITY/3000 package contains "PASCHG" a program that allows users to
change their own passwords (not other users' unfortunately); this poses no
security threat; in fact, it actually improves security by making it easier
for users to get their own password changed.
ELIMINATING PASSWORDS IN JOB STREAMS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The requirement of keeping passwords in clear text in job streams is a big
security flaw because anyone with READ access to the job stream can read the
passwords, and any listing of the job contains the password. More
importantly, since changing a password means having to change every single job
that contains it, these passwords are virtually guaranteed never to be
changed.
STREAMX eliminates the need to embed passwords, lockwords, and other sensitive
information in job streams, while adding additional flexibility to jobs by
permitting parameter passing.
DIAL-UP, TERMINAL AND DS SECURITY
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also desirable is the ability to put a password on a DIAL-UP line, DS line, or
terminal, regardless of the user trying to log on. That way, if a hacker
or "inside" violator attempted to log on to a DIAL-UP, he would have to know
the password for the DIAL-UP, which could be changed every day.
In addition, the high level of user authentication that the logon procedure in
SECURITY/3000 provides can be linked with the terminal and DIAL-UP security by
conditionally invoking the SECURITY/3000 logon security based on LDEV to which
a user is logging on.
This type of terminal security is provided by the TERMPASS utility.
AUTOMATIC LOGOFF OF INACTIVE USERS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another threat to system security is a very common one: a user goes on a
break or to lunch without logging off. By this, a would-be thief could just
walk up to a terminal and use it--without even having to log on. There are
times when users forget to sign off even before going home for the day, (which
holds up system backups.
The LOGOFF utility allows automatic log off of terminals on which users have
been inactive for a given period of time.
Now that we have had a general overview of SECURITY/3000's many features, lets
take a much more detailed look into the logon security system.
WHAT HAPPENS AT LOGON TIME
~~~~~~~~~~~~~~~~~~~~~~~~~~
With the Logon Security System if SECURITY/3000 invoked, whenever a user logs
on (before he gets the ':' prompt and after he types in his MPE passwords [if
he has any]), SESSION, TIME, DAY, and TERMINAL restrictions which may have
been placed on the user are verified--if the user is not within the allowed
time and day limits or if he is attempting to log on from a terminal he is not
authorized to use, he is denied access to the system (i.e. logged off), an
inverse-video message describing the failed logon attempt is sent to the
console, a memo is printed off the line printer, and an entry is logged to the
SECURITY log file.
If the user, for some reason, replies incorrectly to the original question, he
is given as many more chances as are configured (two by default); he is asked
to reply to the SAME QUESTION additional times--if he does not give the
correct answer on any of these attempts, he is logged off and the violation
reporting described above is done. If, however, he replies correctly to any
of the question prompts, he is allowed on the system.
Here is an example of the logon conversation:
:HELLO JOHN,CLERK.PAYROLL
WHERE WAS YOUR FATHER BORN? << incorrect answer entered >>
Error: The answer given was INCORRECT
WHERE WAS YOUR FATHER BORN? << now a correct answer is entered >>
Welcome! You are now signed on.
END OF PROGRAM
: << you have signed on successfully, you are now in MPE >>
An Account or System Manager can set up a special LOGON MENU for some or all
users. If this has been done, a menu will roll up on the screen immediately
after the logon question is answered.
At this point, the user should enter the number of the selection that he
wishes to invoke, or 'E' to exit. If he enters a selection number, that
selection is invoked, and, when it is done, the menu is redisplayed. When the
user types 'E', he is logged off the system.
How to ADD users to the Logon Security System
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Of course, before the system can ask users questions at logon time, it must
know the correct answers. So, the Account or System Manager must add each
user to the Logon Security System data base (ANSWER.DATA.SECURITY), specifying
the user name, account name, and session name (which comprise the "USER ID")
and time, day, and terminal restrictions, the menu file name (WHICH MUST HAVE
BEEN CREATED ALREADY) and then have the user input the answers to the personal
profile questions.
To enter users, log on as Account Manager (to add users under an account) or
System Manager (to add any user) and then
:RUN USER.PUB.SECURITY,ADD
Following are the items that this option prompts for:
(type '?' for help any time you don't know what to enter or how to enter it)
Enter user name:
Enter the MPE user name of the user to be added into the Logon Security
System. This user must exist in MPE already. Or you may enter an "@", which
means "any user" (or hit <return> to exit).
Enter account name:
You are asked this only if you are the System Manager; if you are an Account
Manager, this will default to your account name. You may enter an "@" which
means any account (or hit <return> to exit).
Enter session name:
The system permits securing users by session name as well as user name and
account name. Enter the session name which the user should use at logon or
hit <return> if the user will not use a session name, or enter an "@" if the
user may log on with different session names.
NOTE: This feature may be used to create a better account structure --
instead of creating MPE users by first name (JOHN, MARY, etc.) the
Account Manager can create "generic" user names based on the functions
existing within a department (CLERK, SUPER, MANAGER, etc.). When
several people share the same function, the Logon Security System will
differentiate them by session name which can be the person's first name.
Example of such logons are :HELLO MARY,MANAGER.PAYROLL and :HELLO
JOHN,CLERK.PAYROLL. The session name may be retrieved by your
application programs and then carried through your application system
along with the transaction record.
Enter user's real name:
This is the real name of the user (for instance, JOHN Q. DOE). This
information is used on the printed security violation memo and some log file
entries.
Enter the permitted terminal numbers:
Enter up to 30 logical device numbers on which the user is to be permitted to
log on, separated by commas (for instance, '220,55,73'). Hit <return> to
permit access by the user on all terminals. (See the "REMOTE" section of this
manual for details about putting a password on a dial-up, DS line, or other
terminal, regardless of where the user is logging on to.)
Enter the day-of-week access restrictions:
To permit the user to log on only on certain days of the week, enter a day of
the week (e.g. 'WEDNESDAY' means the user can log on only on Wednesdays) or
two days of the week separated by a '-' (e.g. 'MON-FRI' means the user can log
on only on Monday through Friday). Days may be spelled out or abbreviated to
3 characters. Hit <return> to permit access on all days.
Abbreviations allowed: 'SUN', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT'
Enter the time-of-day access restrictions:
To allow the user to log on only at certain times of the day, enter the
starting hour followed by a '-' followed by the ending hour (e.g. '9-17' means
that the user can sign on from 9 am to 5 pm). Hit <return> to permit access
at any time of day.
Enter the menu filename:
If you wish to set up a logon menu for this user, enter the name of the menu
file. THE MENU FILE MUST HAVE ALREADY BEEN CREATED (see "LOGON MENUS FOR
SECURITY AND CONVENIENCE" in this manual for details on how to set up a menu).
If you wish the user to instead be allowed to access MPE directly, just hit
<return>.
If you did not create the menu file already, hit <return> (for none), continue
entering the user info, and add the menu file later (see "How to CHANGE users
in the Logon Security System" later in this file).
Should the user be asked personal profile questions (Y/N)?
If you want the user to be asked a personal profile question at logon, type
'Y'. If you do not want a personal profile question to be asked (but still
have all other access restrictions apply), type 'N'.
The user is then added to the Logon Security System, a message is printed
acknowledging the addition of the user, and you are prompted for another user
(hit <return> to exit). Note that all successful user additions are logged to
the SECURITY log file.
NOTE: The ADD option requires Account/System Manager capability!
Following is an example of this option:
:RUN USER.PUB.SECURITY,ADD
SECURITY/ADD Version 0.5 (VESOFT (C) 1981) For help type '?'
Enter user name: CLERK
Enter account name: PAYROLL
Enter session name: JOHN
Enter user's real name: JOHN Q. DOE
Enter permitted terminal numbers: 34,35,36,37,50,52,53,54
Enter day of week access restrictions: MON-FRI
Enter time of day access restrictions: << <return> hit >>
Enter menu filename: CLERK.MENU.PAYROLL
Should the user be asked personal profile questions (Y/N)? Y
WHAT IS YOUR MOTHER'S MAIDEN NAME? << user answers, no echo >>
WHAT ELEMENTARY SCHOOL DID YOU GO TO? << user answers, no echo >>
WHERE WAS YOUR FATHER BORN? << user answers, no echo >>
WHAT IS YOUR FIRST LOVE'S NAME? << user answers, no echo >>
*** User has been added ***
Enter user name: << <return> hit to exit >>
Note that all successful user ADDs are logged to the SECURITY log file.
ANOTHER NOTE: Before starting the ADD option you may wish to get HELP.
To do so say
:FILE CICAT.PUB.SYS=USER.HELP.SECURITY
:HELP
IMPORTANT: Before this user attempts to log on, the Logon
Security System must be activated--see "ACTIVATING THE LOGON SECURITY
SYSTEM" later in this file.
How to CHANGE users in the Logon Security System
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It may occur that an incorrect response was given to the ADD-time
configuration and personal profile questions or you may want to permit a user
to change his answers to the personal profile questions (which is all he is
permitted to do in this option); so to make changes to existing user profiles:
:RUN USER.PUB.SECURITY,CHANGE
The CHANGE option prompts you for: (type '?' for help at any prompt)
Enter user name:
Enter the user name of the user to be changed. If you are not an Account or
System Manager, this defaults to the logon user, (or hit <return> to exit).
Enter account name:
Enter the account of the user ID to be changed. If you are not System
Manager, this defaults to the logon account, (or hit <return> to exit).
Enter session name:
Enter the session name entered at user ADD time. If none was entered, hit
<return>.
This option now displays a menu of items corresponding to the configuration
and personal profile questions, and you are prompted for the item to be
changed. After you change an item, it continues to prompt you until you hit
<return>. (If the menu rolls off the screen, type 'R' to redisplay it.) An
Account or System Manager can change anything; an ordinary user can change
only his answers to the personal profile questions.
Following is an example of the CHANGE option:
:RUN USER.PUB.SECURITY,CHANGE
SECURITY/CHANGE Version 0.5 (VESOFT (C) 1981) For help type '?'
Enter user name: CLERK
Enter account name: PAYROLL
Enter session name: JOHN
R: Redisplay this menu
U: User info (user, account, session)
N: User's real name
T: Permitted terminal numbers
D: Day-of-week access restrictions
H: Time-of-day access restrictions
M: Menu file name
A: Ask personal profile questions?
1: WHAT IS YOUR MOTHER'S MAIDEN NAME:
2: WHERE WAS YOUR FATHER BORN:
3: WHAT ELEMENTARY SCHOOL DID YOU GO TO:
4: WHAT IS YOUR FIRST LOVE'S NAME:
Enter item number to change: M << change menu file name >>
Menu file name is now: PAYCLERK.MENU.PAYROLL
Enter NEW menu file name: PAYSUPER.MENU.PAYROLL
Enter item number to change: << <return> hit to exit >>
*** User has been changed ***
Enter user name: << <return> hit to exit >>
Note that all successful user CHANGEs are logged to the SECURITY log file.
How to COPY users in the Logon Security System
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On some systems a certain user (System Manager, for example) may be required
to access more than one account and therefore may log on with more than one
user ID. This is where the copy option will save you time because it allows
an Account or System Manager to copy a given user's security configuration and
personal profile answers to a new user in the data base. An Account Manager
can copy only users within his account, whereas the System Manager can copy
users anywhere on the system. To enter copy mode, execute a:
:RUN USER.PUB.SECURITY,COPY
Following are the items that this option will ask for
(type '?' for help at any prompt)
Enter original user name:
The user name of the user to be copied. This user must exist in the data base
already, (or hit <return> to exit).
Enter original account name:
The account of the user to be copied.
If you are not System Manager, this defaults to the logon account.
(Hit <return> to exit.)
Enter original session name:
The session name with which the user is configured in the user data base (the
session name that was specified at ADD time). If no session name was
specified, hit <return>.
Enter new user name:
The user name to which the original user's security parameters (configuration
and personal profile answers) should be copied. This user must exist in MPE
already, (or hit <return> to exit).
Enter new account name:
The account to which the original user's security parameters should be copied.
This account must exist in MPE already. If you are not System Manager,
defaults to the logon account, (or hit <return> to exit).
Enter new session name:
The session name which the user should use at logon, or hit <return> if the
user will not use a session name.
Following is an example of the copy option:
:RUN USER.PUB.SECURITY,COPY
SECURITY/COPY Version 0.5 (VESOFT (C) 1981) For help type '?'
Enter original user ID
Enter user name: CLERK
Enter account name: PAYROLL
Enter session name: JOHN
Enter new user ID
Enter user name: CLERK
Enter account name: ORDER
Enter session name: JOHN
*** User information has been copied ***
Enter original user ID
Enter user name: << <return> hit to exit >>
Note that all successful user COPYs are logged to the SECURITY log file.
How to DELETE users from the Logon Security System
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When you delete users from MPE, you should delete them from the Logon Security
System as well. Users must exist in MPE in order to be deleted from the Logon
Security System, so if you wish to delete a user from both, you should delete
him from the Logon Security System by using this option BEFORE doing a
:PURGEUSER. To do this:
:RUN USER.PUB.SECURITY,DELETE
This option prompts you for (type '?' for help at any prompt)
Enter user name:
The user name of the user to be deleted, (or hit <return> to exit).
Enter account name:
The account of the user to be deleted. If you are an Account Manager and not
the System Manager, this will default to the logon account, ( or hit <return>
to exit).
Enter session name:
The session name specified at user ADD time.
If none was specified, hit <return>.
NOTE: This option requires Account/System Manager capability!
Following is an example of the DELETE option:
:RUN USER.PUB.SECURITY,DELETE
SECURITY/DELETE Version 0.5 (VESOFT (C) 1981) For help type '?'
Enter user name: CLERK
Enter account name: PAYROLL
Enter session name: JOHN
*** User has been deleted ***
Enter user name: << <return> hit to exit >>
Note that all successful user DELETEs are logged to the SECURITY log file.
How to SET UP users who use MULTIPLE LOGON IDs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Users are normally defined in the Logon Security System with the specific
session name, user name, and account name (user ID) with which they log on.
In some environments, a user may be authorized to use more than one user ID to
log on, depending on the function he is performing. For example, a user who
uses the Payroll, Accounts Payable, and General Ledger systems may log on with
three user IDs, i.e. JOHN,CLERK.PAYROLL, JOHN,CLERK.AP and JOHN,CLERK.GL. For
this, the COPY option of the USER.PUB.SECURITY program is useful because one
user may be set up with the proper security parameters and the information may
be COPYd to the other two user IDs.
It is also possible that an Account Manager will want to be allowed to log on
as any user in his account; or the System Manager will want to log on as any
user on the system. The Logon Security System permits you to set up a user
who is authorized to log on using many different user IDs by specifying "@"
as the session name and/or user name and/or account name.
For example, if you wanted to set up the System Manager, Mike, so that he
could log on as any user on the system, you could create a user called
MIKE,@.@
by responding to the prompts of the ADD option as follows:
Enter user name: @
Enter account: @
Enter session name: MIKE
If you wanted to set up the Account Manager of the PAYROLL account, Jane, so
that she could log on as any user in her account, you would create a user
called JANE,@.PAYROLL by responding to the ADD prompts as follows:
Enter user name: @
Enter account: PAYROLL
Enter session name: JANE
Jane would be allowed to log on using any valid user name in the account, and
the same personal profile and security restrictions would be used.
ACTIVATING THE LOGON SECURITY SYSTEM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Logon Security System may be imposed on the entire system, for selected
accounts, for only certain users, or for only logons to certain LDEVs
(terminals, dial-up lines, DS lines, etc.).
To activate the Logon Security System for selected accounts or users, the
Account or System Manager must set up an "OPTION LOGON" UDC that will invoke
the USER.PUB.SECURITY program. The UDC is stored in the file
SECURUDC.PUB.SECURITY
SECURUDC
OPTION LOGON, NOBREAK
comment
comment *******************************************
comment JCW is set 1717 by TERMPASS when $SECURITY
comment keyword is specified for the logon port.
comment Please see the TERMPASS.DOC.SECURITY.
comment *******************************************
comment
IF JCW<>1717 THEN
SETJCW SECURITYANSWER=0
CONTINUE
RUN USER.PUB.SECURITY,LOGON
IF SECURITYANSWER = 1 THEN
BYE
ENDIF
ENDIF
Because the Logon Security System is activated by a UDC, you can limit the
system's scope by setting the UDC at the level (either user, account, or
system) where it is appropriate. So to invoke the Logon Security System for
the logon account, the Account Manager can do the following:
WARNING: DO NOT PERFORM THE FOLLOWING UNLESS YOU HAVE AUTHORIZED
YOURSELF AS A USER (see "How to ADD users to the Logon
Security System" in this section). OTHERWISE, YOU MAY LOCK
UP YOUR ACCOUNT!
:SETCATALOG SECURUDC.PUB.SECURITY;ACCOUNT
(In spite of this warning, if you DID lock up your account, log on to some
other account, create the following file in your editor:
!JOB MGR/password.ACCOUNT/password << the locked-up account >>
!SETCATALOG;ACCOUNT
!EOJ
and :STREAM it.)
Once the SECURUDC is set, whenever a user who is affected by this UDC tries to
sign on, the Logon Security System is invoked and the time, day, and terminal
restrictions, etc., will be applied.
If the account or a user in the account has a logon UDC, that UDC should be
changed to do as its first command the execution of SECURUDC; e.g. if you
want to have a logon UDC that does a SHOWJOB, use the following UDC:
LOGONUDC
OPTION LOGON, NOBREAK
SECURUDC
SHOWJOB
***
Note that the UDC SECURUDC must have also been set for the user or account in
question, e.g.
:SETCATALOG MYUDC, SECURUDC.PUB.SECURITY
It is also recommended that you
:ALLOCATE USER.PUB.SECURITY
to speed things up when logging on, and also so that it will function during
backups.
LOGON MENUS FOR SECURITY
~~~~~~~~~~~~~~~~~~~~~~~~
Of course, by restricting users from MPE (so that they never get a ':') you
are vastly improving security on your system because users are prevented from
attempting to breach security using various "holes" existing in MPE
(e.g. :FCOPYing a file containing a password to the terminal, :SHOWCATALOGs,
or even doing :LISTFs in sensitive groups and accounts).
SECURITY/3000's menu subsystem implements this kind of closed system where you
specify what the user is allowed to do.
If you, the Account or System Manager, want to limit a user's access via a
menu, you must first build a file (the "menu file") in your editor describing
the menu (the user must have READ access to it).
A menu file consists of:
*HEADER Optionally, any number of '*HEADER' lines, which contain
text to be printed when the menu is invoked. A common use
for this is to print some form of menu identification, e.g.
*HEADER ****************************
*HEADER MAIN ACCOUNTS PAYABLE MENU
*HEADER ****************************
You may also put escape sequences to control the display
on a *HEADER line (e.g. <escape-H> <escape-J> to home the
cursor and clear the screen before displaying the menu).
*CAPTION Up to 24 selection descriptors. Each section descriptor
consists of one
'*CAPTION' line followed by a number of body lines.
The '*CAPTION' line defines what this selection should be
identified as on the menu, e.g.
*CAPTION INVOICE ADDITION
The body lines contain the commands to be executed when
the selection is chosen. A body line can be:
MPE Any MPE command or commands, including :RUN,
command :IF, :ELSE, and :ENDIF, e.g.
FILE D=DATA.PUB.AP
RUN INVADD.PUB.AP
LISTF XYZ.PUB;$NULL
IF CIERROR = 907 THEN
RUN UPDATE.PUB;PARM=1
ELSE
DISPLAY Update system in use
ENDIF
DISPLAY which causes the specified string to be
displayed to the terminal, e.g.
DISPLAY This system inoperative until Friday
DISPLAY Contact Joe Martin at ext. 283
VEMENU which invokes VEMENU with the specified menu file.
This permits "nested menus", e.g.
VEMENU NEWORDER.ENTRY.PURCH << menu file >>
USE which executes commands from the specified file,
e.g.
USE ENTRY.PROC.GL << file containing set of
file equations and
commands for entry of
GL information >>
EXIT which exits VEMENU and logs the user off the system.
Thus, a simple menu file may be created as follows:
:EDITOR
/ADD
1 *HEADER *************************************
2 *HEADER ACCOUNTS PAYABLE SYSTEM
3 *HEADER CHOOSE ONE OF THE FOLLOWING:
4 *HEADER *************************************
5 *HEADER
6 *CAPTION VENDOR MAINTENANCE
7 FILE APDB=APDB.DATABASE.AP
8 RUN AP010
9 *CAPTION INVOICE MAINTENANCE
10 FILE APDB=APDB.DATABASE.AP
11 RUN AP020
12 *CAPTION CHECK PRINTING
13 FILE STRMFILE=CHKPRINT.JOB.AP << job stream
14 RUN STREAMX.PUB.SECURITY;PARM=1 << which asks
15 *CAPTION ARCHIVE << for starting check # >>
16 DISPLAY Sorry, archive system not yet ready
17 DISPLAY -- see system management
18 *CAPTION GO TO ACCOUNTS RECEIVABLE MENU
19 VEMENU ARMENU.PUB.AR
/KEEP MAINMENU.PUB.PAYROLL
/EXIT
Then, add the user to the Logon Security System, entering the name of the menu
file when prompted for it; if the user has already been set up in the Logon
Security System, use the CHANGE option to change his menu file name to the
menu file he is to use. If you decide that a user should go directly into MPE
when he logs on instead of using a menu, just hit <return> when prompted for
the name of the menu file.
Whenever a user who is configured in the Logon Security System with a menu
file logs on, the menu contained in that file is displayed and he is asked to
choose a selection or hit 'E' to exit. When a selection is chosen, the
commands specified in the selection body are executed.
When that menu option has completed, the user is returned to the menu and
asked to choose another selection. This continues until either the user
enters 'E' or a selection chosen by the user executes an 'EXIT' command. When
the user exits the menu, he is automatically logged off. AT NO TIME IS THE
USER EVER LET INTO MPE!
Of course, different users can have different menu files. For instance, if
you have an Accounts Payable system--in which you have clerks who can add and
delete invoices; supervisors who can add and delete vendors as well as
invoices; and a manager who can add and delete vendors, add and delete
invoices, and print checks--you can have one menu file for clerks, another
menu file for supervisors, and a third for the manager. (Remember that if
several users share the same function, you can have them all use a common user
name and differentiate them by their session)
ATTEMPTED SECURITY VIOLATION LOGGING
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When an attempted violation occurs, the Logon Security System makes it
possible to catch the violator "in the act" by immediately providing the
necessary information about the attempted security breach.
If a violation attempt occurs--meaning a user has responded incorrectly to a
logon question or has attempted to log on at an unauthorized time, on an
unauthorized day, or from an unauthorized terminal--the Logon Security System
will immediately:
* Send a descriptive message to the system console, in inverse
video, to distinguish it from other console messages
* Print a violation memo off the system line printer (device class
LP) or a designated printer (see "SETTING ATTEMPTED SECURITY
VIOLATION MEMO ROUTING PARAMETERS" in this section).
* Log an entry to the SECURITY log file.
LOG.DATA.SECURITY
This file is initially built as a 5,000-record circular file,
so if the file fills up, new entries will be appended while
the oldest entries are dropped.
This provides sufficient information for the System Manager to immediately
respond to the attempted security breach. The System Manager may also "hang"
the terminal at this point (while someone is waiting to be logged on) for a
while to give himself more time to respond, or to disable that device so that
additional logon attempts are disallowed.
How to LIST the security LOG FILE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information about all changes to user status (add, change, delete) and all
violation attempts are logged to the SECURITY/3000 log file with pertinent
information about the time and date of the action, terminal on which the
action took place, and the user who performed the action (including session
name). SECURITY/3000 may be configured to log all successful logons,
providing an excellent audit trail of system access.
The following violation messages are logged:
BAD USER Logon attempted by unauthorized user
BAD RESPONSE Question was answered incorrectly
BAD DAY Logon attempted on unauthorized day
BAD TIME Logon attempted at unauthorized time
BAD TERMINAL Logon attempted on unauthorized terminal
INVALID TERMINAL PASSWORD Invalid terminal password was entered
(see the "REMOTE" section of this
manual for details).
and the following update messages are logged:
Add Addition of a user to the Logon Security System
Change Change made to a user in the Logon Security System
Copy Security profile copies from one user to another
Delete User deleted from Logon Security System
and the following successful logon messages are optionally logged:
'SUCCESSFUL LOGON' Valid logon through LOGON SECURITY
'SUCCESSFUL TERMINAL LOGON' Valid logon through the TERMPASS
This file can be later listed to the terminal or line printer, and can be
cleared after review. An Account Manager can list messages in his account,
and the System Manager can list the entire file; (only the System Manager can
clear the file.) An ordinary user is not permitted to use this option.
:RUN USER.PUB.SECURITY,LISTLOG
When you run this option, you are prompted for whether the listing is to go to
the line printer (reply 'L') or to the terminal (reply 'T'). If the line
printer is selected, the log file is dumped (in a readable format) to the line
printer (device class LP). If the terminal is selected, the same printout is
generated except that users' real names are not printed.
To redirect the listing from the default (DEV=LP) to some other device or a
disc file, issue a file equation for SECLIST, e.g.
:FILE SECLIST=MYLOGLST;ACC=OUT;DEV=DISC;NOCCTL;REC=,,,ASCII;SAVE
Following is an example of the use of this option:
:RUN USER.PUB.SECURITY,LISTLOG
SECURITY/LISTLOG Version 0.5 (VESOFT (C) 1981) For help type '?'
Listing to (L)ine printer or (T)erminal: T
Type : Date Time Dev Logon Target user/
Violatn type
Add :20JUL85 5:17PM 33 DON,MANAGER.PAYROLL ENTRY.PAYROL
Violat:21JUL85 9:23AM 117 READER,LABOR.PAYROLL BAD USER
Violat:21JUL85 9:23AM 117 SALLY,ENTRY.PAYROLL BAD RESPONSE
Change:21JUL85 10:17AM 25 BILL,MANAGER.SYS ENTRY.PAYROL
Violat:24JUL85 2:33PM 117 R1,ENTRY.PAYROL BAD DAY
Violat:26JUL85 1:54PM 103 R1,ENTRY.PAYROL BAD TERMINAL
Logon :26JUL85 2:00PM 25 ENTRY.PAYROL SUCCESSFUL LOGON
*** Log file has been printed ***
How to CLEAR the security LOG FILE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Of course you may have good reason to clear the SECURITY log so:
:RUN USER.PUB.SECURITY,CLEARLOG
to clear the log file.
This option will not prompt you for any input.
NOTE: This option can be used by the System Manager only.
A sample run of this option follows:
:RUN USER.PUB.SECURITY,CLEARLOG
SECURITY/CLEARLOG Version 0.5 (VESOFT (C) 1981) For help type '?'
*** Log file has been cleared ***
CONFIGURING SECURITY/3000
~~~~~~~~~~~~~~~~~~~~~~~~~
Several configuration options (described below) may be specified in the
security configuration file,
SECURMGR.PUB.SECURITY
This file is created at installation time with default values, which may be
modified as described in the options below.
DISALLOWING CONCURRENT SESSIONS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As you may know, MPE allows several users with an identical user/account name
(e.g. USER.PAYROLL) to be logged on simultaneously. A user is therefore
permitted to be logged on to more than one terminal and have more than one
session running concurrently, which may be undesirable.
As one of our users pointed out, "No individual could fully control the
activity on two terminals at a time and hence while on one terminal,
unauthorized use could be made of the other."
The Logon Security System may be configured to disallow more than one session
with a given user ID to be logged on concurrently. Remember that we consider
session name to be part of the user ID, so JOE,USER.GL and MARY,USER.GL are
recognized as being different, even though the MPE user name is the same.
With concurrent sessions disallowed, if someone attempts to log on with a user
ID exactly the same as a user who is already logged on, he is not let on the
system. Furthermore, a message is sent to the already-logged-on terminal to
let that user know that someone is attempting a secondary logon.
To disallow concurrent sessions, add the following line to the SECURMGR file:
CONCURRENT-SESSION=NO
Of course we would rather allow concurrent sesseons, so change it to:
CONCURRENT-SESSION=YES
By default, concurrent sessions are permitted.
ELIMINATING SESSION NAME CHECK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SECURITY/3000 differentiates users by session name by expanding the user ID to
include session name in addition to user and account name. This feature
permits a better account structure by allowing "generic" users to be created
with user names describing the users' function and session names identifying
the individual user (e.g. JOHN,ENTRY.PAYROLL and MARY,CLERK.AP). Thereby,
several users could be set up under a common user name but with different
session names, and each one would have unique personal profile answers, time
and day restrictions, menu files, etc.
SECURITY/3000 therefore enforces the use of correct session name by requiring
that a user log on using the same session name with which he was configured
when added to the security system. If he was configured with a session name
of JOHN, for example, and tries to log on using no session name or a different
session name, he will not be recognized as an authorized user and therefore
will not be let on the system.
For those who do not wish to enforce session name or set up "generic" users
and would rather use MPE's approach of optional session name, it is possible
to instruct the Logon Security System to ignore the session name at logon by
adding the following to the SECURMGR file:
SESSION-NAME=OFF
However, if you choose not to enforce session name, all users must have been
set up in the Logon Security System with the session name the same as the user
name or with a session name of '@'. For example, if you are adding a user who
should log on as JOHN.PAYROLL, he must be set up at ADD time with a user name
of 'JOHN', an account name of 'PAYROLL' and a session name of 'JOHN' or '@'.
When he logs on, however, he should not use the session name but rather just
JOHN.PAYROLL.
(When SESSION-NAME=OFF, the SECURITY data base is checked for an authorized
user with a session name which is the same as the user name.)
By default, session name is a valid part of the user ID.
DISABLING A TERMINAL ON WHICH AN ATTEMPTED VIOLATION HAS OCCURED
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If a user is unsuccessful in logging on (either by not responding properly to
personal profile question, attempting to log on at an unauthorized time or
day, etc.), it is often desirable to "hang" that user's terminal so that he is
unable to attempt further logons.
To do this, determine the time in seconds for which you would like the
terminal hung and then add a line to the SECURMGR file in the format:
PAUSE=numseconds
where 'numseconds' is the number of seconds for which the terminal will be
hung. Then, when a user has an unsuccessful logon attempt, he will be hung
for the amount of time specified.
By default, 'numseconds'=0, which means that the user will not be hung at all.
SPECIFYING NUMBER OF ATTEMPTS TO ANSWER QUESTION AT LOGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You may specify the number of attempts users are allowed to answer the
question at logon by adding a line to the SECURMGR file in the format:
TIMES=attempts
where 'attempts' is the number of times the question will be asked.
By default, 'attempts'=2.
LOGGING SUCCESSFUL LOGONS
~~~~~~~~~~~~~~~~~~~~~~~~~
You may wish to know who is logging on through the dial-up line, or whether a
particular logon is being utilized. For how to log successful logons which
come through your dial-in lines or are specific to a port.
You may enable SECURITY/3000 to log successful logons which pass through the
USER program by adding a line to the SECURMGR.PUB.SECURITY file in the format:
LOG-LOGON=ON
This keyword will be seen by the LOGON security program and cause all
successful logons to be written to the LOG.DATA.SECURITY file for later
review. No other configuration is required and this keyword may be added or
removed at any time. When the log file is reviewed later the message:
SUCCESSFUL LOGON
will be displayed.
SETTING ATTEMPTED SECURITY VIOLATION MEMO ROUTING PARAMETERS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The security violation memo which is generated when a violation attempt has
occurred is a useful tool for immediately taking corrective action.
You may change the memo parameters--device to which the memo is routed, outpri
of the memo, and number of copies to generate--by adding a line to the
SECURMGR file in the format:
DEV=device,outpri,copies
where
'device' is the device to which the memo is routed.
'outpri' is the output priority with which the memo will be
generated.
'copies' is the number of copies of the memo which will be printed.
Therefore, if you want the memo routed to a special printer in the DP
Auditor's office where someone will be able to take immediate investigative
action, declare this on the 'device' parm. If you want to give the memo top
priority to ensure that it is printed right away, specify an outpri of 13; if
you want to defer printing the memo, specify an outpri of 1, which will cause
the memo to remain in the spooler for later printing or purging.
If you do not declare a 'DEV=' line in the SECURMGR file, the memo will be
created with default attributes (dev=LP, outpri=8, copies=1).
If you do not want the security violation memo at all (but will still have the
attempted violation console message and log file entry), do not declare a
'DEV=' line in the SECURMGR file, and add this file equation:
:FILE SECLIST=$NULL
to SECURUDC (the UDC which invokes the Logon Security System before the
command which :RUNs USER.PUB.SECURITY.)
HOW SECURITY VIOLATIONS ARE REPORTED
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Whenever an attempted violation occurs, a security memo is printed to the line
printer; the default format of it is:
TO: SYSTEM MANAGER
FROM: SECURITY/3000
RE: SECURITY VIOLATION
WE WOULD LIKE TO CALL TO YOUR ATTENTION THE FACT THAT THERE WAS A
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvv VIOLATION BY:
USER: uuuuuuuu
ACCOUNT: aaaaaaaa
GROUP: gggggggg
SESSION NAME: ssssssss
USER NAME: nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
LOGICAL DEVICE: lll
ON wwwwwwwwwwwwwwwwwwwwwwwwwww
PLEASE INVESTIGATE.
where
'uuuuuuuu' represents the user name
'aaaaaaaa' represents the account name
'gggggggg' represents the group name
'ssssssss' represents the session name
'lll' represents the logical device number
'nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn' represents the user's real name
'wwwwwwwwwwwwwwwwwwwwwwwwwww' represents the time and date when
the violation (attempt!) occurred
'vvvvvvvvvvvvvvvvvvvvvvvvvvv' represents the type of violation
(BAD USER, BAD DAY, BAD TIME,
BAD TERMINAL, or BAD RESPONSE).
By using the above abbreviations ('uuuuuuuu', 'aaaaaaaa', etc.),
you can modify the memo format as you please. The format is stored in
MEMOFORM.DATA.SECURITY
NOTE: If you have :HEADON on your LP, the header on the memo will
indicate the user name (in this case, the violator!) on it, and
the operator may deliver this memo to the violator!
HOW THE QUESTIONS FILE IS MAINTAINED
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The personal profile questions that are asked at logon time of all users in
the system are not fixed by SECURITY/3000; they can be set up with custom
questions--up to 30 of them (remember, only ONE of the questions, at random,
will be asked at logon time). The questions are stored in the editor-format
file called
QUESTION.DATA.SECURITY
When SECURITY/3000 is installed from VESOFT, there are already some sample
questions in this file, so it may not be changed at all.
So, if you want to add a question to the file, just do the following:
:EDITOR
/TEXT QUESTION.DATA.SECURITY
/ADD
6 HOW LONG DID YOU LIVE IN THE PLACE WHERE YOU WERE BORN?
7 //
/KEEP
/EXIT
If you must delete a question from the file, do:
:EDITOR
/TEXT QUESTION.DATA.SECURITY
/REPLACE 6
6 HOW LONG DID YOU LIVE IN THE PLACE WHERE YOU WERE BORN?
6 DELETED << you type >>
/KEEP
/EXIT
Again, NEVER execute an actual DELETE command!
You may want to have only ONE question in the file--this question will be the
only one asked at logon time. Therefore, if you would like to use an MPE-like
password rather than personal profile questions, you can have the one question
in the file be
Enter USER password:
which looks just like
MPE's password prompt; but don't forget that the passwords in SECURITY/3000's
Logon Security System, unlike MPE passwords, are stored in one-way encrypted
format.
If the QUESTION file is empty (zero records, not just only 'DELETED' records),
no questions will be asked at logon time; this is useful in case you do not
want SECURITY/3000's personal profile questions, but only its other features.
Remember that you can impose the questions on only selected users by answering
'N' to the "Should the user be asked personal profile questions?" prompt when
you ADD the user.
NOTE: The maximum number of questions is 30.
ACCESSING THE USER PROFILE DATA BASE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information about all the users you have authorized in the Logon Security
System (i.e. answers, permitted terminal numbers, permitted times of day/days
of week, real user names, etc.) is stored in the IMAGE data base
ANSWER.DATA.SECURITY
To write reports against this data base (e.g. show the user names and the
permitted days of week for all users, sorted by user ID), merely access this
data base with QUERY or any of your programs. Of course, the personal profile
answers are one-way encrypted, and therefore cannot be determined.
Note that you can open the data base through QUERY in READ mode only! Also,
as an added security feature, you may change the data base password (as
follows) and SECURITY/3000 will still be able to (magically!) access the data
base:
:HELLO MANAGER.SECURITY,DATA
:RUN DBUTIL.PUB.SYS
>>SET ANSWER PASSWORD 1=password
>>EXIT
CONCLUSION: PART 1
~~~~~~~~~~~~~~~~~~~
That's it for the particulars on how the LOGON portion of SECURITY/3000
works. In Part 2, I will discuss various utilities and security logs
associated with SECURITY/3000.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
/\ /\
/ \ / \
/ / \
/ Inside NORAD \ /\
/\ / \ / \
/ \ by: Anonymous / \
/ \ \
_ _ /_ _ _ _ _ _ \_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _\_ _
Note: The information below was compiled through research and personal
interviews with Air Force personnel who were stationed at NORAD
Headquarters. The officers that we talked wished for their names to
be withheld.
Aerospace Defense Structure
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The military defense of North America is a joint effort of the United
States and Canada. All forces directly assigned to aerospace defense by the
two nations are organized as the North American Air Defense Command (NORAD).
The major elements of NORAD are the Canadian Forces Air Defence Command
(CFADC), the U.S. Air Force's Air Defense Command (USAD ADC), and the U.S.
Army's Air Defense Command (ARADCOM). Headquarters of NORAD, USAF ADC, and
ARADCOM are in Colorado Springs, Colorado. While the CFADC headquarters are in
St. Hubert, Quebec.
The primary jobs of NORAD is to serve as an early warning system in the
event of nuclear attack. NORAD is primarily concerned with the detection,
identification, and tracking of hostile bombers, ballistic missiles, and space
vehicles.
Defense Against Manned Bombers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Defense against manned bombers includes ground-based and airborne radars
to warn of the approach of hostile aircraft; supersonic fighter-interceptor
aircraft capable of operating in any type of weather, and surface-to-air
interceptor missiles. Detection and tracking of bombers is accomplished by
ground-based radars located along the Arctic Circle from the Aleutians to
Greenland and, in greater concentrations, in southern Canada and the United
States. Radar equipped aircraft on continuous patrol off the Atlantic and
Pacific coasts extend surveillance seaward.
Any aircraft detected must of course be identified. Flights penetrating
designated Air Defense Identification Zones (ADIZ) must be identified by
correlating their flight plans submitted in advance with the precise position
of the aircraft or, when this fails, through visual identification by
interceptor aircraft. The simplest method of identification is to interrogate
an electronic coding device, called Identification Friend of For (IFF), located
in the aircraft, which replies to the interrogation with a known password. If
the airborne object is hostile, it will be destroyed by fighter-interceptor jet
aircraft using nuclear or conventional armament or by unmanned surface-to-air
missiles such as BOMARC or NIKE.
Integration of the defense systems against the manned bomber is
accomplished by the electronic supersystem called Semi-Automatic Ground
Environment (SAGE). In SAGE, computers receive and store data, solve problems,
and display solutions to the detection station display screens. This allows
air defense commanders to follow the battle situation and direct appropriate
defense weapons.
If interceptors or missiles are launched or committed against the target,
the computer, with operator assistance, transmits information to and guides
them to the hostile object. Interceptors are equipped with an automatic pilot,
which can ge guided from the ground by means of data link. In the event the
SAGE system should become inoperative, its functions would be taken over by
BUIC, the Back-up Interceptor Control system, with widely dispersed automated
control centers.
Defense Against Ballistic Missiles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Defense against ballistic missiles presents more difficult problems than
defense against manned bombers. An extensive network known as the Ballistic
Missile Early Warning System (BMWES), runs through Alaska, Canada, Greenland,
and the British Isles, is used to detect and relay information about inbound
missiles. A similar network is planned to cover the southern portion of the
continent. In the event that an inbound missiles is detected, NORAD directs
the use of antiballistic-missile weaponry.
Defense Against Attack Through Space
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Although space vehicles are note currently employed for offensive military
usage at the present, the possibility is certainly there. One of NORAD's
primary responsibilities is to monitor any space born vehicles.
The number of man made objects in orbit above the Earth numbers in the
thousands. Continuous surveillance of these objects in space is performed by
NORAD's Space Detection and Tracking System (SPADATS). SPADATS consists of two
primary elements, the U.S. Navy's Space Surveillance (SPASUR) System--an
electronic fence of high-powered transmitters and receivers extending across
the southern United States--and the U.S. Air Force's SPACETRACK system.
SPACETRACK consists of a worldwide network of radars, space-probing cameras,
and communications. An operational control center with a central
data-processing facility called the Space Defense Center, located at NORAD
headquarters, serves to integrate the entire network.
NORAD Headquarters
~~~~~~~~~~~~~~~~~~
In 1966, operations began in the new Combat Operations Center deep inside
a mountain in Colorado. The center is located outside Colorado Springs at the
Cheyenne Mountain Air Force Base. The complex is set inside tunnels that have
been carved deep into the heart of the mountain itself. The entire structure
is situated atop huge, 3-foot diameter springs to absorb nuclear shock waves.
The headquarters was designed to survive a 1 megaton nuclear blast, but since
this was designed to deter 1960's nuclear technology, it is questionable
whether or not it would withstand attack by today's "smart" bombs, which could
put a missile right in the front door.
Every day, over a thousand people go to work the day shift at NORAD,
commuting up from near by Peterson Air Force Base. Upon arrival at the center,
they walk past the station's concertina wire topped twelve foot fences, which
are surprisingly non-electrified. The exterior is constantly patrolled and
observed by the Air Force Elite Security Forces, each armed to the teeth with
9mm pistols and M-16's. Scores of German Shepherd attack dogs are used as an
added bit of security. Above the main tunnel entrance, is a sign that reads:
"Use of Deadly Force Authorized by all Personnel."
The interior of the base, built to survive a nuclear attack, is completely
self-contained. Backup power is available in case of a power failure, and
provides uninterupted power for lighting as well as computer systems. The base
also contains food and water supplies for all personnel for over 30 days. The
base itself is entirely shielded with lead and reinforced concrete, which
augments the natural protection provided by the mountain. Huge blast doors
provide the only entrances and exits to the base.
Of course, the base is equipped with state-of-the-art communications
systems, with full time links to all nuclear weapons sites in both the U.S. and
Canada. The base is also linked into all major news and civil defense agencies
to accept and release up-to-the-minute information on global military affairs.
Surprisingly, however, the base is not equipped with today's most powerful
mainframes and supercomputers. Many of the systems are somewhat archaic, as any
upgrade would cause massive redesign of weapons and defense systems.
Conclusion
~~~~~~~~~~
One may wonder about the usefulness of this unique command post in the
interior of a mountain in light of current global events. With the evaporation
of central government in the Soviet Union, and the decreased likelihood of
another global war, a huge nuclear arsenal is beginning to seem worthless.
However, with the capability to monitor global military situations at all times,
and the ability to deter possible conflict, it still provides a valuable service
to all of North America, if not the world. Better safe than sorry.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
*******************************************************************************
* *
* Card-O-Rama: Magnetic Stripe Technology and Beyond *
* *
* or *
* *
* "A Day in the Life of a Flux Reversal" *
* *
* *
* *
* by: ..oooOO Count Zero OOooo.. yRDTy 11/22/91 *
* *
*******************************************************************************
---A production of : -=Restricted -=Data -=Transmissions :
: :
: "Truth is cheap, but information costs." :
Look in your wallet. Chances are you own at least 3 cards that have
magnetic stripes on the back. ATM cards, credit cards, calling cards,
frequent flyer cards, ID cards, passcards,...cards, cards, cards! And chances
are you have NO idea what information is on those stripes or how they are
encoded. This detailed document will enlighten you and hopefully spark your
interest in this fascinating field. None of this info is 'illegal'...but
MANY organizations (government, credit card companies, security firms,
etc.) would rather keep you in the dark. Also, many people will IMMEDIATELY
assume that you are a CRIMINAL if you merely "mention" that you are
"interested in how magnetic stripe cards work." Watch yourself, ok? Just
remember that there's nothing wrong with wanting to know how things work,
although
in our present society, you may be labelled a "deviant" (or worse, a <gasp>
"hacker!").
Anyway, I will explain in detail how magstripes are encoded and give
several examples of the data found on some common cards. I will also cover the
technical theory behind magnetic encoding, and discuss magnetic encoding
alternatives to magstripes (Wiegand, barium ferrite). Non-magnetic card
technology (bar code, infrared, etc.) will be described. Finally, there will
be an end discussion on security systems and the ramifications of emergent
"smartcard" and biometric technologies.
*DISCLAIMER*
Use this info to EXPLORE, not to EXPLOIT. This text is presented for
informational purposes only, and I cannot be held responsible for anything you
do or any consequences thereof. I do not condone fraud, larceny, or any other
criminal activities.
*A WARNING*
I've noticed lately a few "books" and "magazines" for sale that were
FILLED with PHILES on a variety of computer topics. These philes were
originally released into the Net with the intention of distributing them for
FREE. HOWEVER, these philes are now being PACKAGED and sold FOR PROFIT. This
really pisses me off. I am writing this to be SHARED for FREE, and I ask no
payment. Feel free to reprint this in hardcopy format and sell it if you must,
but NO PROFITS must be made. Not a f**king DIME! If ANYONE reprints this
phile and tries to sell it FOR A PROFIT, I will hunt you down and make your
life miserable. How? Use your imagination. The reality will be worse.
** MAGSTRIPE FIELDS, HEADS, ENCODING/READING **
Whew! I'll get down to business now. First, I am going to explain the
basics behind fields, heads, encoding and reading. Try and absorb the THEORY
behind encoding/reading. This will help you greatly if you ever decide to
build your own encoder/reader from scratch (more on that later).
FERROMAGNETIC materials are substances that retain magnetism after an external
magnetizing field is removed. This principle is the basis of ALL magnetic
recording and playback. Magnetic POLES always occur in pairs within magnetized
material, and MAGNETIC FLUX lines emerge from the NORTH pole and
terminate at the SOUTH. The elemental parts of MAGSTRIPES are ferromagnetic
particles about 20 millionths of an inch long, each of which acts like a tiny
bar magnet. These particles are rigidly held together by a resin binder.
The magnetic particles are made by companies which make coloring pigments
for the paint industry, and are usually called pigments. When making the
magstripe media, the elemental magnetic particles are aligned with their
North-South axes parallel to the magnetic stripe by means of an external
magnetic fields while the binder hardens.
These particles are actually permanent bar magnets with TWO STABLE
POLARITIES. If a magnetic particle is placed in a strong external magnetic
field of the opposite polarity, it will FLIP its own polarity (North becomes
South, South becomes North). The external magnetic field strength required to
produce this flip is called the COERCIVE FORCE, or COERCIVITY of the particle.
Magnetic pigments are available in a variety of coercivities (more on that
later on).
An unencoded magstripe is actually a series of North-South magnetic
domains (see Figure 1). The adjacent N-S fluxes merge, and the entire stripe
acts as a single bar magnet with North and South poles at its ends.
Figure 1: N-S.N-S.N-S.N-S.N-S.N-S.N-S.N-S <-particles in stripe
---------
represented as-> N-----------------------------S
However, if a S-S interface is created somewhere on the stripe, the fluxes
will REPEL, and we get a concentration of flux lines around the S-S interface.
(same with N-N interface) ENCODING consists of creating S-S and N-N
interfaces, and READING consists of (you guessed it) detecting 'em. The S-S
and N-N interfaces are called FLUX REVERSALS.
||| ||| <-flux lines
Figure 2: N------------N-N-S-S-----------------S
--------- flux lines -> ||| |||
The external magnetic field used to flip the polarities is produced by a
SOLENOID, which can REVERSE its polarity by reversing the direction of CURRENT.
An ENCODING head solenoid looks like a bar magnet bent into the shape of a ring
so that the North/South poles are very close and face each other across a tiny
gap. The field of the solenoid is concentrated across this gap, and when
elemental magnetic particles of the magstripe are exposed to this field, they
polarize to the OPPOSITE (unlike poles attract). Movement of the stripe past
the solenoid gap during which the polarity of the solenoid is REVERSED will
produce a SINGLE flux reversal (see Figure 3). To erase a magstripe, the
encoding head is held at a CONSTANT polarity and the ENTIRE stripe is moved
past it. No flux reversals, no data.
| | <----wires leading to solenoid
| | (wrapped around ring)
/-|-|-\
/ \
Figure 3: | | <----solenoid (has JUST changed polarity)
--------- \ /
\ N S / <---gap in ring.. NS polarity across gap
N----------------------SS-N-------------------------S
^^
<<<<<-direction of stripe movement
S-S flux reversal created at trailing edge of solenoid!
So, we now know that flux reversals are only created the INSTANT the
solenoid CHANGES its POLARITY. If the solenoid in Figure 3 were to remain at
its current polarity, no further flux reversals would be created as the
magstripe moves from right to left. But, if we were to change the solenoid
gap polarity from NS to *SN*, then (you guessed it) a *N-N* flux reversal would
instantly be created. Just remember, for each and every reversal in solenoid
polarity, a single flux reversal is created (commit it to memory..impress your
friends..be a tech weenie!). An encoded magstripe is therefore just a series
of flux reversals (NN followed by SS followed by NN ...).
DATA! DATA! DATA! That's what you want! How the hell are flux reversals
read and interpreted as data? Another solenoid called a READ HEAD is used to
detect these flux reversals. The read head operates on the principle of
ELECTROMAGNETIC RECIPROCITY: current passing through a solenoid produces a
magnetic field at the gap, therefore, the presence of a magnetic field at the
gap of a solenoid coil will *produce a current in the coil*! The strongest
magnetic fields on a magstripe are at the points of flux reversals. These are
detected as voltage peaks by the reader, with +/- voltages corresponding to
NN/SS flux reversals (remember, flux reversals come in 2 flavors).
See Figure 4.
magstripe---> -------NN--------SS--------NN---------SS------
Figure 4: voltage-----> .......+.........-.........+...........-.....
---------
---------- -------------
peak readout--> | | | |
--------| |----------| |----
The 'peak readout' square waveform is critical. Notice that the voltage
peak remains the same until a new flux reversal is encountered.
Now, how can we encode DATA? The most common technique used is known as
Aiken Biphase, or 'two-frequency coherent-phase encoding' (sounds impressive,
eh?). First, digest the diagrams in Figure 5.
Figure 5: ---------- ---------- ----------
--------- | | | | | | <- peak
a) | |--------| |--------| | readouts
* 0 * 0 * 0 * 0 * 0 *
----- ----- ----- ----- ----- -
| | | | | | | | | | |
b) | |----| |----| |----| |----| |----|
* 1 * 1 * 1 * 1 * 1 *
----- ---------- ----- ----- -
| | | | | | | | |
c) | |----| |--------| |----| |----|
* 1 * 0 * 0 * 1 * 1 *
There ya have it. Data is encoded in 'bit cells,' the frequency of which
is the frequency of '0' signals. '1' signals are exactly TWICE the frequency
of '0' signals. Therefore, while the actual frequency of the data passing
the read head will vary due to swipe speed, data density, etc, the '1'
frequency will ALWAYS be TWICE the '0' frequency. Figure 5C shows exactly how
'1' and '0' data exists side by side.
We're getting closer to read DATA! Now, we're all familiar with binary
and how numbers and letters can be represented in binary fashion very easily.
There are obviously an *infinite* number of possible standards, but thankfully
the American National Standards Institute (ANSI) and the International
Standards Organization (ISO) have chosen 2 standards. The first is
** ANSI/ISO BCD Data format **
This is a 5-bit Binary Coded Decimal format. It uses a 16-character set,
which uses 4 of the 5 available bits. The 5th bit is an ODD parity bit, which
means there must be an odd number of 1's in the 5-bit character..the parity bit
will 'force' the total to be odd. Also, the Least Significant Bits are read
FIRST on the strip. See Figure 6.
The sum of the 1's in each case is odd, thanks to the parity bit. If the
read system adds up the 5 bits and gets an EVEN number, it flags the read
as ERROR, and you gotta scan the card again. (yeah, I *know* a lot of you
out there *already* understand parity, but I gotta cover all the bases...not
everyone sleeps with their modem and can recite the entire AT command set
at will, you know ;). See Figure 6 for details of ANSI/ISO BCD.
Figure 6: ANSI/ISO BCD Data Format
---------
* Remember that b1 (bit #1) is the LSB (least significant bit)!
* The LSB is read FIRST!
* Hexadecimal conversions of the Data Bits are given in parenthesis (xH).
--Data Bits-- Parity
b1 b2 b3 b4 b5 Character Function
0 0 0 0 1 0 (0H) Data
1 0 0 0 0 1 (1H) "
0 1 0 0 0 2 (2H) "
1 1 0 0 1 3 (3H) "
0 0 1 0 0 4 (4H) "
1 0 1 0 1 5 (5H) "
0 1 1 0 1 6 (6H) "
1 1 1 0 0 7 (7H) "
0 0 0 1 0 8 (8H) "
1 0 0 1 1 9 (9H) "
0 1 0 1 1 : (AH) Control
1 1 0 1 0 ; (BH) Start Sentinel
0 0 1 1 1 < (CH) Control
1 0 1 1 0 = (DH) Field Separator
0 1 1 1 0 > (EH) Control
1 1 1 1 1 ? (FH) End Sentinel
***** 16 Character 5-bit Set *****
10 Numeric Data Characters
3 Framing/Field Characters
3 Control Characters
The magstripe begins with a string of Zero bit-cells to permit the
self-clocking feature of biphase to "sync" and begin decoding.
A "Start Sentinel" character then tells the reformatting process where to start
grouping the decoded bitstream into groups of 5 bits each. At the end of the
data, an "End Sentinel" is encountered, which is followed by an "Longitudinal
Redundancy Check (LRC) character. The LRC is a parity check for the sums of
all b1, b2, b3, and b4 data bits of all preceding characters. The LRC
character will catch the remote error that could occur if an individual
character had two compensating errors in its bit pattern (which would fool the
5th-bit parity check).
The START SENTINEL, END SENTINEL, and LRC are collectively called "Framing
Characters", and are discarded at the end of the reformatting process.
** ANSI/ISO ALPHA Data Format **
Alphanumeric data can also be encoded on magstripes. The second ANSI/ISO
data format is ALPHA (alphanumeric) and involves a 7-bit character set with
64 characters. As before, an odd parity bit is added to the required 6 data
bits for each of the 64 characters. See Figure 7.
Figure 7:
--------- ANSI/ISO ALPHA Data Format
* Remember that b1 (bit #1) is the LSB (least significant bit)!
* The LSB is read FIRST!
* Hexadecimal conversions of the Data Bits are given in parenthesis (xH).
------Data Bits------- Parity
b1 b2 b3 b4 b5 b6 b7 Character Function
0 0 0 0 0 0 1 space (0H) Special
1 0 0 0 0 0 0 ! (1H) "
0 1 0 0 0 0 0 " (2H) "
1 1 0 0 0 0 1 # (3H) "
0 0 1 0 0 0 0 $ (4H) "
1 0 1 0 0 0 1 % (5H) Start Sentinel
0 1 1 0 0 0 1 & (6H) Special
1 1 1 0 0 0 0 ' (7H) "
0 0 0 1 0 0 0 ( (8H) "
1 0 0 1 0 0 1 ) (9H) "
0 1 0 1 0 0 1 * (AH) "
1 1 0 1 0 0 0 + (BH) "
0 0 1 1 0 0 1 , (CH) "
1 0 1 1 0 0 0 - (DH) "
0 1 1 1 0 0 0 . (EH) "
1 1 1 1 0 0 1 / (FH) "
0 0 0 0 1 0 0 0 (10H) Data (numeric)
1 0 0 0 1 0 1 1 (11H) "
0 1 0 0 1 0 1 2 (12H) "
1 1 0 0 1 0 0 3 (13H) "
0 0 1 0 1 0 1 4 (14H) "
1 0 1 0 1 0 0 5 (15H) "
0 1 1 0 1 0 0 6 (16H) "
1 1 1 0 1 0 1 7 (17H) "
0 0 0 1 1 0 1 8 (18H) "
1 0 0 1 1 0 0 9 (19H) "
0 1 0 1 1 0 0 : (1AH) Special
1 1 0 1 1 0 1 ; (1BH) "
0 0 1 1 1 0 0 < (1CH) "
1 0 1 1 1 0 1 = (1DH) "
0 1 1 1 1 0 1 > (1EH) "
1 1 1 1 1 0 0 ? (1FH) End Sentinel
0 0 0 0 0 1 0 @ (20H) Special
1 0 0 0 0 1 1 A (21H) Data (alpha)
0 1 0 0 0 1 1 B (22H) "
1 1 0 0 0 1 0 C (23H) "
0 0 1 0 0 1 1 D (24H) "
1 0 1 0 0 1 0 E (25H) "
0 1 1 0 0 1 0 F (26H) "
1 1 1 0 0 1 1 G (27H) "
0 0 0 1 0 1 1 H (28H) "
1 0 0 1 0 1 0 I (29H) "
0 1 0 1 0 1 0 J (2AH) "
1 1 0 1 0 1 1 K (2BH) "
0 0 1 1 0 1 0 L (2CH) "
1 0 1 1 0 1 1 M (2DH) "
0 1 1 1 0 1 1 N (2EH) "
1 1 1 1 0 1 0 O (2FH) "
0 0 0 0 1 1 1 P (30H) "
1 0 0 0 1 1 0 Q (31H) "
0 1 0 0 1 1 0 R (32H) "
1 1 0 0 1 1 1 S (33H) "
0 0 1 0 1 1 0 T (34H) "
1 0 1 0 1 1 1 U (35H) "
0 1 1 0 1 1 1 V (36H) "
1 1 1 0 1 1 0 W (37H) "
0 0 0 1 1 1 0 X (38H) "
1 0 0 1 1 1 1 Y (39H) "
0 1 0 1 1 1 1 Z (3AH) "
1 1 0 1 1 1 0 [ (3BH) Special
0 0 1 1 1 1 1 \ (3DH) Special
1 0 1 1 1 1 0 ] (3EH) Special
0 1 1 1 1 1 0 ^ (3FH) Field Separator
1 1 1 1 1 1 1 _ (40H) Special
***** 64 Character 7-bit Set *****
* 43 Alphanumeric Data Characters
* 3 Framing/Field Characters
* 18 Control/Special Characters
The two ANSI/ISO formats, ALPHA and BCD, allow a great variety of data to be
stored on magstripes. Most cards with magstripes use these formats, but
occasionally some do not. More about those later on.
** Tracks and Encoding Protocols **
Now we know how the data is stored. But WHERE is the data stored on the
magstripe? ANSI/ISO standards define *3* Tracks, each of which is used for
different purposes. These Tracks are defined only by their location on the
magstripe, since the magstripe as a whole is magnetically homogeneous. See
Figure 8.
Figure 8:
--------- <edge of card>
_________________________________________________________________
| ^ ^ ^
|------------------| 0.223"--|---------|-------------------------
| | | 0.353" | ^
|..................|.........|.........| 0.493" |
| Track #1 0.110" | | |
|............................|.........|... <MAGSTRIPE>
| | | |
|............................|.........|... |
| Track #2 0.110" | |
|......................................|... |
| | |
|......................................|... |
| Track #3 0.110" |
|.......................................... |
| |
|------------------------------------------------------------------
|
| <body of card>
|
You can see the exact distances of each track from the edge of the card, as
well as the uniform width and spacing. Place a magstripe card in front of you
with the magstripe visible at the bottom of the card. Data is encoded from
left to right (just like reading a book, eh?). See Figure 9.
Figure 9:
--------- ANSI/ISO Track 1,2,3 Standards
Track Name Density Format Characters Function
--------------------------------------------------------------------
1 IATA 210 bpi ALPHA 79 Read Name & Account
2 ABA 75 bpi BCD 40 Read Account
3 THRIFT 210 bpi BCD 107 Read Account &
*Encode* Transaction
*** Track 1 Layout: ***
| SS | FC | PAN | Name | FS | Additional Data | ES | LRC |
SS=Start Sentinel "%"
FC=Format Code
PAN=Primary Acct. # (19 digits max)
FS=Field Separator "^"
Name=26 alphanumeric characters max.
Additional Data=Expiration Date, offset, encrypted PIN, etc.
ES=End Sentinel "?"
LRC=Longitudinal Redundancy Check
*** Track 2 Layout: ***
| SS | PAN | FS | Additional Data | ES | LRC |
SS=Start Sentinel ";"
PAN=Primary Acct. # (19 digits max)
FS=Field Separator "="
Additional Data=Expiration Date, offset, encrypted PIN, etc.
ES=End Sentinel "?"
LRC=Longitudinal Redundancy Check
*** Track 3 Layout: ** Similar to tracks 1 and 2. Almost never used.
Many different data standards used.
Track 2, "American Banking Association," (ABA) is most commonly used. This
is the track that is read by ATMs and credit card checkers. The ABA designed
the specifications of this track and all world banks must abide by it. It
contains the cardholder's account, encrypted PIN, plus other discretionary
data.
Track 1, named after the "International Air Transport Association," contains
the cardholder's name as well as account and other discretionary data. This
track is sometimes used by the airlines when securing reservations with a
credit card; your name just "pops up" on their machine when they swipe your
card!
Since Track 1 can store MUCH more information, credit card companies are trying
to urge retailers to buy card readers that read Track 1. The *problem* is that
most card readers read either Track 1 or Track 2, but NOT BOTH! And the
installed base of readers currently is biased towards Track 2. VISA USA is at
the front of this 'exodus' to Track 1, to the point where they are offering
Track 1 readers at reduced prices through participating banks. A spokesperson
for
VISA commented:
"We think that Track 1 represents more flexibility and the
potential to deliver more information, and we intend to
build new services around the increased information."
What new services? We can only wait and see.
Track 3 is unique. It was intended to have data read and WRITTEN on it.
Cardholders would have account information UPDATED right on the magstripe.
Unfortunately, Track 3 is pretty much an orphaned standard. Its *original*
design was to control off-line ATM transactions, but since ATMs are now on-line
ALL THE TIME, it's pretty much useless. Plus the fact that retailers and banks
would have to install NEW card readers to read that track, and that costs $$.
Encoding protocol specifies that each track must begin and end with a length
of all Zero bits, called CLOCKING BITS. These are used to synch the self-
clocking feature of biphase decoding. See Figure 10.
Figure 10: end sentinel
start sentinel | longitudinal redundancy check
| | |
000000000000000 SS.................ES LRC 0000000000000000
leading data, data, data trailing
clocking bits clocking bits
(length varies) (length varies)
THAT'S IT!!! There you have the ANSI/ISO STANDARDS! Completely explained.
Now, the bad news. NOT EVERY CARD USES IT! Credit cards and ATM cards will
follow these standards. BUT, there are many other types of cards out there.
Security passes, copy machine cards, ID badges, and EACH of them may use a
PROPRIETARY density/format/track-location system. ANSI/ISO is REQUIRED for
financial transaction cards used in the international interbank network. All
other cards can play their own game.
The good news. MOST other cards follow the standards, because it's EASY to
follow a standard instead of WORKING to make your OWN! Most magstripe cards
other than credit cards and ATM cards will use the same Track specifications,
and use either BCD or ALPHA formats.
** A Bit About Magstripe Equipment **
"Wow, now I know how to interpret all that data on magstripes! But...
waitasec, what kind of equipment do I need to read the stripes?
Where can I buy a reader? I don't see any in Radio Shack!!"
Sorry, but magstripe equipment is hard to come by. For obvious reasons,
card readers are not made commonly available to consumers. How to
build one is the topic for another phile (and THIS phile is already too long!).
Your best bets are to try and scope out Electronic Surplus Stores and flea
markets. Don't even bother trying to buy one directly from a manufacturer,
since they will immediately assume you have "criminal motives." And as for
getting your hands on a magstripe ENCODER...well, good luck! Those rare
beauties are worth their weight in gold. Keep your eyes open and look around,
and MAYBE you'll get lucky! A bit of social engineering can go a LONG way.
There are different kinds of magstripe readers/encoders. The most common
ones are "swipe" machines: the type you have to physically slide the card
through.
Others are "insertion" machines: like ATM machines they 'eat' your card, then
regurgitate it after the transaction. Costs are in the thousands of dollars,
but like I said, flea markets and surplus stores will often have GREAT deals
on these things. Another problem is documentation for these machines. If you
call the manufacturer and simply ask for 'em, they will probably deny you the
literature. "Hey son, what are you doing with our model XYZ swipe reader? That
belongs in the hands of a 'qualified' merchant or retailer, not some punk kid
trying to 'find out how things work!" Again, some social engineering may be
required. Tell 'em you're setting up a new business. Tell 'em you're working
on a science project. Tell 'em anything that works!
2600 Magazine recently had a good article on how to build a machine that
copies magstripe cards. Not much info on the actual data formats and encoding
schemes, but the device described is a start. With some modifications, I bet
you could route the output to a dumb terminal (or through a null modem cable) in
order to READ the data. Worth checking out the schematics.
As for making your own cards, just paste a length of VCR, reel-to-reel, or
audio cassette tape to a cut-out posterboard or plastic card. Works just as
good as the real thing, and useful to experiment with if you have no expired or
'dead' ATM or calling cards lying around (SAVE them, don't TOSS them!).
** Examples of Data on Magstripes **
The real fun in experimenting with magstripe technology is READING cards to
find out WHAT THE HELL is ON them! Haven't you wondered? The following cards
are the result of my own 'research'. Data such as specific account numbers and
names has been changed to protect the innocent. None the cards used to make
this list were stolen or acquired illegally.
Notice that I make careful note of 'common data'; data that I noticed was
the same for all cards of a particular type. This is highlighted below the
data with asterisks (*). Where I found varying data, I indicate it with "x"'s.
In those cases, NUMBER of CHARACTERS was consistent (the number of "x"'s equals
the number of characters...one to one relationship).
I still don't know what some of the data fields are for, but hopefully I
will be following this phile with a sequel after I collect more data. It ISN'T
easy to find lots of cards to examine. Ask your friends, family, and co-workers
to help! "Hey, can I, um, like BORROW your MCI calling card tonite? I'm
working on an, um, EXPERIMENT. Please?" Just...be honest! Also, do some
trashing. People will often BEND expired cards in half, then throw them out.
Simply bend 'em back into their normal shape, and they'll usually work (I've
done it!). They may be expired, but they're not ERASED!
-------------------------------------------------------------------------------
-=Mastercard=- Number on front of card -> 1111 2222 3333 4444
Expiration date -> 12/99
Track 2 (BCD,75 bpi)-> ;1111222233334444=99121010000000000000?
***
Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN?
*
Note that the "101" was common to all MC cards checked, as well as the "B".
-------------------------------------------------------------------------------
-=VISA=- Number on front of card -> 1111 2222 3333 4444
Expiration date -> 12/99
Track 2 (BCD,75 bpi)-> ;1111222233334444=9912101xxxxxxxxxxxxx?
***
Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN^9912101xxxxxxxxxxxxx?
*
Note that the "101" was common to all VISA cards checked, as well as the "B".
Also, the "xxx" indicates numeric data that varied from card to card, with no
apparent pattern. I believe this is the encrypted pin for use when cardholders
get 'cash advances' from ATMs. In every case, tho, I found *13* digits of the
stuff.
-------------------------------------------------------------------------------
-=Discover=- Number on front of card -> 1111 2222 3333 4444
Expiration date -> 12/99
Track 2 (BCD,75 bpi)-> ;1111222233334444=991210100000?
********
Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN___^991210100000?
********
Note, the "10100000" and "B" were common to most DISCOVER cards checked.
I found a few that had "10110000" instead. Don't know the significance.
Note the underscores after the name JOHN. I found consistently that the name
data field had *26* charaters. Whatever was left of the field after the name
was "padded" with SPACES. Soo...for all of you with names longer than 25
(exclude the "/") characters, PREPARE to be TRUNCATED! ;)
-------------------------------------------------------------------------------
-=US Sprint FON=- Number on front of card -> 111 222 3333 4444
Track 2 (BCD,75 bpi)-> ;xxxxxx11122233339==xxx4444xxxxxxxxxx=?
*
Track 1 (ALPHA,210 bpi)-> %B^ /^^xxxxxxxxxxxxxxxxx?
*
Strange. None of the cards I check had names in the Track 1 fields. Track 1
looks unused, yet it was always formatted with field separators. The "xxx"
stuff varied from card to card, and I didn't see a pattern. I know it isn't
a PIN, so it must be account data.
-------------------------------------------------------------------------------
-=Fleet Bank=- Number on front of card -> 111111 222 3333333
Expiration date -> 12/99
Track 2 (BCD,75 bpi)-> ;1111112223333333=9912120100000000xxxx?
****
Track 1 (ALPHA,210 bpi) ->
%B1111112223333333^PUBLIC/JOHN___^9912120100000000000000xxxx000000?
* ****
Note that the "xxx" data varied. This is the encrypted PIN offset. Always 4
digits (hrmmm...). The "1201" was always the same. In fact, I tried many
ATM cards from DIFFERENT BANKS...and they all had "1201".
-------------------------------------------------------------------------------
(Can't leave *this* one out ;)
-=Radio Shack=- Number on front of card -> 1111 222 333333
NO EXPIRATION data on card
Track 2 (BCD,75 dpi)-> ;1111222333333=9912101?
*******
Note that the "9912101" was the SAME for EVERY Radio Shack card I saw. Looks
like when they don't have 'real' data to put in the expiration date field, they
have to stick SOMETHING in there.
-------------------------------------------------------------------------------
Well, that's all I'm going to put out right now. As you can see, the major
types of cards (ATMs, CC) all follow the same rules more or less. I checked
out a number of security passcards and timeclock entry cards..and they ALL had
random stuff written to Track 2. Track 2 is by FAR the MOST utilized track on
the card. And the format is pretty much always ANSI/ISO BCD. I *did* run
into some hotel room access cards that, when scanned, were GARBLED. They most
likely used a character set other than ASCII (if they were audio tones, my
reader would have put out NOTHING...as opposed to GARBLED data). As you can
see, one could write a BOOK listing different types of card data. I intended
only to give you some examples. My research has been limited, but I tried to
make logical conclusions based on the data I received.
** Cards of All Flavors **
People wanted to store A LOT of data on plastic cards. And they wanted that
data to be 'invisible' to cardholders. Here are the different card
technologies that were invented and are available today.
HOLLERITH - With this system, holes are punched in a plastic or paper card and
read optically. One of the earliest technologies, it is now seen
as an encoded room key in hotels. The technology is not secure,
but cards are cheap to make.
BAR CODE - The use of bar codes is limited. They are cheap, but there is
virtually no security and the bar code strip can be easily damaged.
INFRARED - Not in widespread use, cards are factory encoded by creating a
"shadow pattern" within the card. The card is passed through a
swipe
or insertion reader that uses an infrared scanner. Infrared card
pricing is moderate to expensive, and encoding is pretty secure.
Infrared scanners are optical and therefore vulnerable to
contamination.
PROXIMITY - Hands-free operation is the primary selling point of this card.
Although several different circuit designs are used, all proximity
cards permit the transmission of a code simply by bringing the card
near the reader (6-12"). These cards are quite thick, up to
0.15" (the ABA standard is 0.030"!).
WIEGAND - Named after its inventor, this technology uses a series of small
diameter wires that, when subjected to a changing magnetic field,
induce a discrete voltage output in a sensing coil. Two rows of
wires are embedded in a coded strip. When the wires move past
the read head, a series of pulses is read and interpreted as binary
code. This technology produces card that are VERY hard to copy
or alter, and cards are moderately expensive to make. Readers
based on this tech are epoxy filled, making them immune to weather
conditions, and neither card nor readers are affected by external
magnetic fields (don't worry about leaving these cards on top of
the television set...you can't hurt them!). Here's an example of
the layout of the wires in a Wiegand strip:
||| || || | ||| | || || | || || | | ||
| | | | | | |||| || |||| ||
The wires are NOT visible from the outside of the card, but if
your card is white, place it in front of a VERY bright light source
and peer inside. Notice that the spacings between the wires is
uniform.
BARIUM FERRITE - The oldest magnetic encoding technology (been around for 40
yrs!) it uses small bits of magnetized barium ferrite that are
placed inside a plastic card. The polarity and location of
the "spots" determines the coding. These cards have a short
life cycle, and are used EXTENSIVELY in parking lots (high
turnover rate, minimal security). Barium Ferrite cards are
ONLY used with INSERTION readers.
There you have the most commonly used cards. Magstripes are common because
they are CHEAP and relatively secure.
** Magstripe Coercivity **
Magstripes themselves come in different flavors. The COERCIVITY of the
magnetic media must be specified. The coercivity is the magnetic field
strength required to demagnetize an encoded stripe, and therefore determines
the encode head field strength required to encode the stripe. A range of media
coercivities are available ranging from 300 Oersteds to 4,000 Oe. That boils
down to HIGH-ENERGY magstripes (4,000 Oe) and LOW-ENERGY magstripes (300 Oe).
REMEMBER: since all magstripes have the same magnetic remanence regardless of
their coercivity, readers CANNOT tell the difference between HIGH and LOW
energy stripes. Both are read the same by the same machines.
LOW-ENERGY media is most common. It is used on all financial cards, but its
disadvantage is that it is subject to accidental demagnetization from contact
with common magnets (refrigerator, TV magnetic fields, etc.). But these cards
are kept safe in wallets and purses most of the time.
HIGH-ENERGY media is used for ID Badges and access control cards, which are
commonly used in 'hostile' environments (worn on uniform, used in stockrooms).
Normal magnets will not affect these cards, and low-energy encoders cannot
write to them.
** Not All that Fluxes is Digital **
Not all magstripe cards operate on a digital encoding method. SOME cards
encode AUDIO TONES, as opposed to digital data. These cards are usually
used with old, outdated, industrial-strength equipment where security is not an
issue and not a great deal of data need be encoded on the card. Some subway
passes are like this. They require only expiration data on the magstripe, and
a short series of varying frequencies and durations are enough. Frequencies
will vary with the speed of swiping, but RELATIVE frequencies will remain the
same (for instance, tone 1 is twice the freq. of tone 2, and .5 the freq of
tone 3, regardless of the original frequencies!). Grab an oscilloscope to
visualize the tones, and listen to them on your stereo. I haven't experimented
with these types of cards at all.
** Security and Smartcards **
Many security systems utilize magstripe cards, in the form of passcards and
ID cards. It's interesting, but I found in a NUMBER of cases that there was
a serious FLAW in the security of the system. In these cases, there was a
code number PRINTED on the card. When scanned, I found this number encoded on
the magstripe. Problem was, the CODE NUMBER was ALL I found on the magstripe!
Meaning, by just looking at the face of the card, I immediately knew exactly
what was encoded on it. Ooops! Makes it pretty damn easy to just glance at
Joe's card during lunch, then go home and pop out my OWN copy of Joe's access
card! Fortunately, I found this flaw only in 'smaller' companies (sometimes
even universities). Bigger companies seem to know better, and DON'T print
ALL of the magstripe data right on card in big, easily legible numbers. At
least the big companies *I* checked. ;)
Other security blunders include passcard magstripes encoded ONLY with the
owner's social security number (yeah, real difficult to find out a person's
SS#...GREAT idea), and having passcards with only 3 or 4 digit codes.
Smartcard technology involves the use of chips embedded in plastic cards,
with pinouts that temporarily contact the card reader equipment. Obviously,
a GREAT deal of data could be stored in this way, and unauthorized duplication
would be very difficulty. Interestingly enough, not much effort is being put
into smartcards by the major credit card companies. They feel that the tech
is too expensive, and that still more data can be squeezed onto magstripe
cards in the future (especially Track 1). I find this somewhat analogous to
the use of metallic oxide disk media. Sure, it's not the greatest (compared
to erasable-writable optical disks), but it's CHEAP..and we just keep improving
it. Magstripes will be around for a long time to come. The media will be
refined, and data density increased. But for conventional applications, the
vast storage capabilities of smartcards are just not needed.
** Biometrics: Throw yer cards away! **
I'd like to end with a mention of biometrics: the technology based on reading
the physical attributes of an individual through retina scanning, signature
verification, voice verification, and other means. This was once limited to
government use and to supersensitive installations. However, biometrics will
soon acquire a larger market share in access control sales because much of its
development stage has passed and costs will be within reach of more buyers.
Eventually, we can expect biometrics to replace pretty much ALL cards..because
all those plastic cards in your wallet are there JUST to help COMPANIES
*identify* YOU. And with biometrics, they'll know you without having to read
cards. I'm not paranoid, nor do I subscribe to any grand 'corporate
conspiracy', but I find it a bit unsettling that our physical attributes will
most likely someday be sitting in the cool, vast electronic databases of
the CORPORATE world. Accessible by anyone willing to pay. Imagine CBI and TRW
databases with your retina image, fingerprint, and voice pattern online for
instant, convenient retrieval. Today, a person can CHOOSE NOT to own a credit
card or a bank card...we can cut up our plastic ID cards! Without a card, a
card reader is useless and cannot identify you. Paying in cash makes you
invisible! However, with biometrics, all a machine has to do is watch...
.listen...and record. With government/corporate America pushing all the
buttons.. "Are you paying in cash?...thank you...please look into the camera.
Oh, I see your name is Mr. Smith...uh, oh...my computer tells me you haven't
paid your gas bill....afraid I'm going to have to keep this money and credit
your gas account with it....do you have any more cash?...or would you rather
I garnish your paycheck?" heh heh
** Closing Notes (FINALLY!!!!) **
Whew...this was one MOTHER of a phile. I hope it was interesting, and I hope
you distribute it to all you friends. This phile was a production of
"Restricted Data Transmissions"...a group of techies based in the Boston area
that feel that "Information is Power"...and we intend to release a number of
highly technical yet entertaining philes in the coming year....LOOK FOR THEM!!
Tomorrow I'm on my way to Xmascon '91.....we made some slick buttons
commemorating the event...if you ever see one of them (green wreath..XMASCON
1991 printed on it)..hang on to it!...it's a collector's item.. (hahahah)
Boy, I'm sleepy...
Remember.... "Truth is cheap, but information costs!"
But -=RDT is gonna change all that... ;) set the info FREE!
Peace.
..oooOO Count Zero OOooo..
Usual greets to Magic Man, Brian Oblivion, Omega, White Knight, and anyone
else I ever bummed a cigarette off.....
Comments, criticisms, and discussions about this phile are welcome. I can be
reached at
count0@world.std.com
count0@spica.bu.edu
count0@atdt.org
Magic Man and I are the sysops of the BBS "ATDT"...located somewhere in
Massachusetts. Great message bases, technical discussions...data made
flesh...electronic underground.....our own Internet address (atdt.org)...
.field trips to the tunnels under MIT in Cambridge.....give it a call..
..mail me for more info.. ;)
ATDT------(???)YOU-WISH
(You're not paranoid if they're REALLY out to get you... ;)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/
-/- -/-
/-/ *> TID-BYTES <* /-/
-/- -/-
/-/ by the Informatik Staff /-/
-/- -/-
/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/-/
Tid-Bytes is a standing column of miscellaneous bits of information.
Some FYI
~~~~~~~~
Ever wonder why Rolling Rock Beer has that mysterious "33" printed on the
back of the bottle? Well apparently there are two stories concerning this
strange number. The OFFICIAL story: The number 33 stands for two things, 1)
The year that Prohibition was repealed (1933), and 2) the number of words in
the legend printed above the 33 on cans and bottles. The REAL story is that
the bold "33" is nothing more than an accident. During the initial design of
the beer's label, someone scribbled a large "33" to point out the extreme
length of the legend. This copy made it to the printers and the note was
included in the final printing.
-------------------------------------------------------------------------------
Interesting Books
~~~~~~~~~~~~~~~~~
"Automated Crime Information Systems" by J. Van Duyn
This 142-page hardcover book provides a complete introduction to all existing
and planned systems of automated criminal records-gathering and dissemination
in the United States. Includes the latest information on such topics as: The
FBI's criminal history and ID programs; NCIC; federal/state co-op efforts;
useful software applications for law enforcement; legality of stored
information, DNA analysis, and more. The book is $22.95 from TAB Professional
and Reference Books, Blue Ridge Summit, PA 17294-0850. The Order Number of
the book is 3503.
"Deception Detection--Winning the Polygraph Game" by Charles Clifton
In this 145 page book the author explains the theory behind polygraphs, and
gives countermeasures to turn the results to your favor by several methods.
It is available for $15.00 from Paladin Press, PO Box 1307, Boulder, CO 80306.
"Engineer's Trade Secrets of Radio" by James R. Cunningham
Brimming with information on AM/FM, Ham, broadcast transmitters, antennas,
signal enhancement schemes, this 140-page book is a must for radio electronic
enthusiasts (legal or otherwise). Note that some projects described in the
book are not legal in the United States. Order for $19.95 from CRB Research
Books, Inc., PO Box 56, Commack, NY 11725.
------------------------------------------------------------------------------
Pay-Per-View the Discount Way
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you've ever had a burning desire to watch those expensive movies on the
pay channels at hotels, but have never had the cash to indulge, here's the
solution. Simply disconnect the input coax (the one hooked up to the wall)
>from the "control box" on top of the T.V. Then disconnect the patch cable
between the T.V. and control box from the T.V. Connect the input cable to
the now vacant cable input on the T.V., then patch the cable box into itself
with the short cable. The high channels on the T.V. tuner should now be
showing the pay-per-view movies free of charge. One warning, the cables may
have a short shield over the end of the connector to prevent removal. In
this case, needle nose pliers or a similar tool is required to remove them.
Be sure to pack one in your shave kit!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)
)%( )%(
(%) > Hot Flashes < (%)
)%( )%(
(%) The Underground News Report (%)
)%( )%(
(%) Edited by: the Informatik Staff (%)
)%( )%(
(%) January 1992 (%)
)%( )%(
(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)%(%)
===================================
Computer Civil Liberties Conference
===================================
First Announcement of
THE SECOND CONFERENCE ON COMPUTERS, FREEDOM, AND PRIVACY
L'Enfant Plaza Hotel, Washington DC March 18-20, 1992
(A longer, complete, electronic version of this announcement is available
by sending a request with any title and any message to cfp2-info@eff.org.)
(The printed announcement (brochure) is available -- see end of this notice.)
The rush of computers into our workplaces, homes, and institutions is
drastically altering how we work and live, how we buy and sell, and with whom
we communicate. Computers are obliterating traditional political and
organizational boundaries, making time zones irrelevant, and bridging diverse
cultures. They are fundamentally changing our culture, values, laws,
traditions, and identities.
The turmoil of the changes calls into question many old assumptions about
privacy, freedom of speech, search and seizure, access to personal and
governmental information, professional responsibilities, ethics,
criminality, law enforcement, and more. The only way to sort out these
issues and arrive at a consensus for action is to acknowledge that we don't
know the answers -- and then, with reason and good will, to find the
answers through discussion and education. That's why the Conference on
Computers, Freedom, and Privacy was founded in 1991.
The Computers, Freedom, and Privacy Conference is unique. It has no
"agenda for change". It seeks only to bring together people from all the
major communities and interest groups that have a stake in the new world being
shaped by information technology, so that they may share their ideas, ideals,
concerns and experiences.
At the first conference, hundreds of people from the fields of law,
computer science, law enforcement, business, public policy, government,
education, research, marketing, information providing, advocacy and a host of
others met for several days. It was the first time such a diverse group had
ever assembled, and the exchange of ideas and points of view was electric.
The conference is "single-track" -- all participants attend all the
sessions. A morning of tutorials at the beginning of the conference will help
participants get up to speed in specific "hot" areas. The conference sessions
themselves take up timely and, at times, thorny issues. Each session aims for
a balance of perspectives in order to assist diverse groups appreciate the
views of others. A brief examination of the long list of sponsoring and
supporting organizations will reveal that this respect for diverse outlooks is
built into the conference from the ground up.
The question is no longer whether information technologies will change
our world. They are, now. The real question is how we, as citizens and
professionals, will respond to and manage that change. Those at the Second
Conference on Computers, Freedom, and Privacy will lead the way.
Sponsors: Association for Computing Machinery, Special Interest Groups on
Computers and Society, Communications, Security, Audit, and Control
Host: Department of Electrical Engineering and Computer Science
The George Washington University
Patrons: Bell Atlantic Computer Security Institute
Department of Energy* Dunn & Bradstreet
Equifax Hayes Microcomputer Products, Inc.
John Gilmore Mitchell Kapor
National Institutes of Health* National Science Foundation*
*applied for
Co-sponsors and cooperating organizations:
American Civil Liberties Union
Association for Computing Machinery
Special Interest Group on Software Engineering
Association of Research Libraries
Computer Professionals for Social Responsibility
Electronic Frontier Foundation
Federal Library and Information Center Committee
First Amendment Congress
Institute for Electrical and Electronics Engineers-USA
Committee on Communications and Information Policy
Library and Information Technology Association
Privacy International
U. S. Privacy Council
The WELL (Whole Earth 'Lectronic Link)
STEERING COMMITTEE
Lance J. Hoffman (General Chair), The George Washington University
Michael F. Brewer, Dun and Bradstreet
Paul Clark (chair, Operations Committee), Trusted Information Systems
Dorothy Denning (chair, Tutorials Committee), Georgetown University
Peter Denning (chair, Program Committee), George Mason University
David Farber, University of Pennsylvania
Craig Feied, The George Washington University Medical Center
Mike Gibbons, FBI
Mitchell Kapor, Electronic Frontier Foundation
Jane Kirtley, Reporters Committee for Freedom of the Press
Lu Kleppinger (chair, Finance Committee), The George Washington University
C. Dianne Martin, The George Washington University
John McMullen (chair, Scholarship Committee), McMullen & McMullen, Inc.
Lynn McNulty, NIST
Ronald Plesser, Piper and Marbury
Molly Raphael, D.C. Public Library
Mark Rotenberg, CPSR Washington Office
James Sylvester, Bell Atlantic
Jim Warren, Autodesk and MicroTimes
Fred Weingarten, Computing Research Association
WEDNESDAY, MARCH 18, 1992
PRE-CONFERENCE TUTORIALS
Group A: 9:00 a.m.
Making Information Law and Policy
Jane Bortnick, Congressional Research Service, Library of Congress
Information policy is made (or not made) by a bewildering array of
government officials and agencies. This tutorial gives a road map through
this maze of laws, regulations, practices, etc.
Getting on the Net
Mitchell Kapor, Electronic Frontier Foundation
Practical issues of access to the Internet for the nontechnical end-user,
including basic services (email, USENET, ftp), PC and Mac-based network
applications, and net-speak.
Communications and Network Evolution
Sergio Heker, JVNCNet
The underlying technical infrastructure for the Internet, for persons not
deeply immersed in the technology. Possible future technologies and
projects, and what privacy and freedom problems they may bring.
Private Sector Privacy
Jeff Smith, Georgetown University
An introduction to laws, rules, and practices regarding personal
information gathered and stored by private organizations such as direct
marketers, hospitals, etc.
Group B: 10:30 a.m.
Constitutional Law for Nonlawyers
Harvey Silverglate, Silverglate & Good
An overview of Constitutional law with special emphasis on the First,
Fourth, and Fifth Amendments and the application of their principles in the
information age.
Computer Crime
Don G. Ingraham, Alameda County District Attorney's Office
Investigation, search, seizure, and evidence requirements for pursuing
computer crime. For computer users, owners, sysops, and investigators and
attorneys unfamiliar with computer crime practices.
Modern Telecommunications: Life after Humpty Dumpty
Richard S. Wolff, Bellcore
Roles and relationships of the key players in telecommunications,
developments in communications technology, and new services. Signaling
System 7, ISDN, and advanced intelligent network features.
International Privacy Developments
David Flaherty, University of Western Ontario
Privacy-related developments within the European community, OECD, and the
United Nations, and how they affect the United States. Comparison of
privacy regulations here and abroad.
CONFERENCE PROGRAM
1:00-2:00 p.m. KEYNOTE ADDRESS:
Al Neuharth, Chairman, The Freedom Forum and Founder, USA Today
"Freedom in Cyberspace: New Wine in Old Flasks?"
The differing legal and regulatory constraints on publishers of
newspapers, owners of television stations, and the telephone service
providers imply that some dogfights will occur and some tough decisions
will have to be made to balance privacy and freedom in the coming decade,
since the old wine of 1970's-era regulation will not fit into the new
flasks of 21st Century. Mr. Neuharth, a self-proclaimed S.O.B., will give
us a peek at his vision of what the future holds.
2:30 pm - 4 pm Who logs on?
* Chair: Robert Lucky, AT&T Bell Laboratories
* Panel: Linda Garcia, Office of Technology Assessment
* Alfred Koeppe, New Jersey Bell
* Brian Kahin, Harvard University
4:30 pm - 6 pm Ethics, Morality, and Criminality
* Chair: J. Michael Gibbons, Federal Bureau of Investigation
* Panel: Scott Charney, U. S. Dept. of Justice
* James Settle, Federal Bureau of Investigation
* Mike Godwin, Electronic Frontier Foundation
* Emory Hackman, Esq. (former president, Capital Area Sysops
Association)
* Don Delaney, New York State Police
6:00 pm - 7:30 pm RECEPTION
9:00 pm BIRDS OF A FEATHER SESSIONS
THURSDAY, MARCH 19, 1992
9:00 am - 10:30 am For Sale: Government Information
* Chair: George Trubow, John Marshall Law School
* Panel: Dwight Morris, Los Angeles Times Washington Bureau
* Ken Allen, Information Industry Association
* Patricia Glass Schuman, American Library Association
* Evan Hendricks, Privacy Times
* Fred Weingarten, Computing Research Association
* Franklin S. Reeder, Office of Management and Budget
* Costas Torreagas, Public Technology, Inc.
* Robert R. Belair, Kirkpatrick and Lockhart
10:45 am - 12:15 pm Free Speech and the Public Telephone Network
* Chair: Jerry Berman, ACLU Information Technology Project
* Panel: Henry Geller, The Markle Foundation
* Eli Noam, Columbia University
* John Podesta, Podesta Associates
12:15 pm - 1:45 pm Luncheon with Address: Bruce Sterling
"Speaking for the Unspeakable"
Mr. Sterling will gamely attempt to publicly present the points of view
of certain elements of the "computer community" who are not represented at
CFP-2. He will speak up for those who, in his words, are too "venal,
violent, treacherous, power-mad, suspicious or meanspirited to receive (or
accept) an invitation to attend.
2:00 pm - 3:30 pm Who's in Your Genes?
* Chair: Phil Reilly, Shriver Center for Mental Retardation
* Panel: John Hicks, FBI Laboratory
* Tom Marr, Cold Spring Harbor Laboratory
* Paul Mendelsohn, Neurofibromatosis, Inc.
* Peter Neufeld, Esq.
* Madison Powers, Kennedy Center for Ethics,
Georgetown University
3:45 pm - 5:15 pm Private Collection of Personal Information
* Chair: Ron Plesser, Piper and Marbury
* Panel: Janlori Goldman, Privacy and Technology Project, ACLU
* John Baker, Equifax
* James D. McQuaid, Metromail
* James Rule, SUNY-Stony Brook
* Mary Culnan, Georgetown University
* P. Michael Neugent, Citicorp
5:15 pm - 6:45 pm EFF Awards Reception
9:00 pm Birds of a Feather Sessions
FRIDAY, MARCH 20, 1992
9:00 am - 10:30 am Privacy and intellectual freedom in the digital library
* Chair: Marc Rotenberg, Computer Professionals for Social Responsibility
* Panel: Robert A. Walton, CLSI, Inc.
* Gordon M. Conable, Monroe (MI) County Library System
* Jean Armour Polly, Liverpool (NY) Public Library
10:45 am - 12:15 pm Computers in the Workplace: Elysium or Panopticon?
* Chair: Alan F. Westin, Columbia University
* Panel: Gary Marx, MIT
* Mark DiBernardo, National Association of Manufacturers
* Kristina Zahorik, Subcommittee on Employment and
Productivity, U. S. Senate Labor Committee
12:15 pm - 1:30 pm Lunch (on your own)
1:30 pm - 3:00 pm Who Holds the Keys?
* Chair: Dorothy Denning
* Panel: Jim Bidzos, RSA Data Security
* David Bellin, Pratt Institute
* John Gilmore, Cygnus Support
* Whitfield Diffie, SunSoft, Inc.
3:00 pm - 4:15 pm Public Policy for the 21st Century
Co-chairs: Peter J. Denning, George Mason University
Lance J. Hoffman, George Washington University
GENERAL INFORMATION
Registration
Please register for the conference by returning the Conference
Registration Form (below) along with the appropriate payment -- check,
Visa, or Mastercard. Registration fee includes conference materials,
Thursday luncheon, and receptions. The registration is $295 for ACM
members and $350 for nonmembers, $65 for full-time students. Tutorials,
$95 ($35 students).
Premium for Early Registration
While they last, a limited number of premiums are available to early
registrants on a first-come, first-served basis. Early registrants will
receive by mail a voucher which they can exchange at the conference for one
of a number of premiums. These include:
Videotapes of CFP-1 sessions
Audiotapes of CFP-1 sessions
Proceedings of CFP-1
Computers Under Attack: Intruders, Worms, and Viruses
by Peter Denning, editor
Rogue Programs: Viruses, Worms, and Trojan Horses
by Lance Hoffman, editor
"Citizen Rights and Access to Electronic Information"
by Dennis Reynolds, editor
The Cuckoo's Egg by Cliff Stoll
The Difference Engine by Bruce Sterling and William Gibson
Confessions of an S.O.B. by Al Neuharth
Cyberpunk by Katie Hafner and John Markoff
CONSIDER REGISTERING BY FAXING THE REGISTRATION FORM BELOW OR TELEPHONING
IF YOU ARE INTERESTED IN ONE OF THESE PREMIUMS. THEY WON'T LAST LONG!
Registration Scholarships
Full-time students and others wishing to apply for one of a limited
number of registration scholarships should send a request to the address
listed in the complete announcement, copies of which are available as
described elsewhere in this shorter electronic notice.
Hotel Accomodations
The 1992 Computers, Freedom, and Privacy Conference will be held at the
Loew's L'Enfant Plaza Hotel, Washington, DC. One of the finest hotels in
the city, it is just ten minutes from Washington National Airport, five
minutes from Capitol Hill. The world-renowned Smithsonian Institution
Museums are located within a few blocks.
To qualify for the conference rate of $105 single or $110 double, call
the hotel reservation line (below) and identify yourself as a CFP-2
participant. To ensure a room at the L'Enfant Plaza, reservations should
be made by February 10, 1992. After this date, rooms will be released to
the public. Hotel reservations: (800) 243-1166; (202) 484-1000 (local).
Transportation
As a participant in CFP-2, you are eligible for discounted rates as
follows: 40% off unrestricted coach fares and 5% off the lowest available
fares on specified carriers (all rules and restrictions apply). To receive
the best rate available call GW Travel (below) and make your reservations
early. Seats may be limited. Please mention that you are attending the
CFP-2 Conference. (Code C-6) GW Travel: (800) 222-1223; (301) 897-8001
(local).
Accreditation
The Second Conference on Computers, Freedom, and Privacy has been
approved by The George Washington University Medical Center for Category One
Continuing Medical Education Units.
Refund Policy
Refund requests received in writing by February 28, 1992 will be honored.
A $50 cancellation fee will apply. No refunds will be made after this
date; however, you may send a substitute in your place.
REGISTRATION FORM
YOU CAN NOT REGISTER BY ELECTRONIC MAIL. YOU MAY REGISTER BY MAIL, BY FAX,
OR BY PHONE. YOU CAN PRINT THIS REGISTRATION FORM OUT, FILL IT IN, AND
MAIL OR FAX IT. OR YOU CAN REQUEST A PRINTED BROCHURE FROM THE "BY MAIL"
ADDRESS BELOW, WHICH WILL HAVE A PRINTED ONE-PAGE REGISTRATION FORM IN IT.
YOU CAN ALSO OBTAIN THIS PRINTED BROCHURE BY ELECTRONICALLY MAILING A SHORT
REQUEST WITH YOUR NAME AND (POSTAL) MAIL ADDRESS TO cfp2@seas.gwu.edu.
* * * * * REGISTRATION FORM * * * * *
By mail: Conferences & Institutes, The George Washington University,
2003 G St. N.W., Washington, D. C. 20052
By fax (24 hrs., with credit card): Send registration form to (202)
994-7048
By phone (with credit card): (202) 994-7238 (9 a.m. to 5 p.m., EST)
Name:______________________________________________________
Title:_____________________________________________________
Affiliation: ______________________________________________
Mailing address: __________________________________________
City ____________________________ State _____ Zip _________
Country (if not USA): _____________________________________
Telephone: ________________________________________________
FAX number: _______________________________________________
E-Mail address: ___________________________________________
PRIVACY NOTE: This information will not be sold, rented, loaned, exchanged,
or used for any purpose other than official CFP-2 activities. A roster
will be distributed to attendees. Please indicate your preference:
____ Print all information above ______ Print name only
____ Print only name, affiliation, ______ Omit all above information
city, state, zip
REGISTRATION FEES:
Conference fee (check one) ___ ACM member ($295) ___ Non-member ($350)
[includes conference materials, Thursday luncheon, and receptions]
____ Student (full-time/valid ID):___ $65 (no lunch) ___ $30 (lunch)
Tutorial fee _____ Tutorial (half-day, 1 or 2 sessions, $95)
(Pick 2, 75 min. each) _____ Student (half-day, 1 or 2 sessions, $35)
Group A 9:00 a.m.
____ T(1) Making Information Law and Policy
____ T(2) Getting on the Net
____ T(3) Communications and Network Evolution
____ T(4) Private Sector Privacy
Group B 10:30 a.m.
____ T(5) Constitutional Law for Non-lawyers
____ T(6) Computer Crime
____ T(7) Modern Telecommunications
____ T(8) International Privacy Developments
Please check method of payment: Amount enclosed: $________
____ Visa _____ MasterCard ____ Check (payable to
The George Washington University)
Credit card number: ______________________________________
Expiration date: _________________________________________
Name on card: ____________________________________________
Signature: _______________________________________________
For Continuing Medical Education accreditation, give state and medical #:
* * * * END OF FORM * * * * *
The complete announcement will be mailed to you in printed form via the
postal service if you request one by telephone, fax, electronic mail, or
regular mail from
CFP - 2
Office of Conferences and Institutes
The George Washington University
2003 G St. NW
Washington DC 20052
phone (202) 994-7238
fax (202) 994-7048
email cfp2@seas.gwu.edu
-------------------------------------------------------------------------------
=====================
Voice of God Silenced
=====================
Popular Communications, Oct 1991
New York City Police detectives with the assistance of FCC agents,
arrested two New York City residents who had allegedly been interfering with
police radio communications.
Based on complaints filed by the NYPD, Engineers from the FCC's New York
City office, using mobile radio direction finding equipment, traced the source
of the interference to the residence of Noel Wo, New York, NY. Mr. Wo who
called himself the "Voice of God," challenged anyone to locate him, and
threatened to "blow away" anyone who tried to catch him.
Radio transmitting equipment allegedly used to transmit taunts, music,
and idle chatter over police emergency radio frequencies, were seized during
a search of his apartment and that of a second suspect, David Yung, New York,
NY. Both defendants were arrested and charged with obstructing governmental
administration. Other state and federal charges are pending.
-------------------------------------------------------------------------------
================================
Fraudulent Fax Gets Forger Freed
================================
San Francisco Chronicle, Dec 18, 1991
Jean Paul Barrett, a convict serving 33 years for forgery and fraud in
the Pima County jail in Tuscon, Arizona, was released on 13Dec91 after receipt
of a forged fax ordering his release. It appears that a copy of a legitimate
release order was altered to bear HIS name. Apparently no one noticed that
the faxed document lacked an originating phone number or that there was no
"formal" cover sheet. The "error" was discovered when Barrett failed to show
up for a court hearing.
The jail releases about 60 people each day, and faxes have become
standard procedure. Sheriff's Sergeant Rick Kastigar said "procedures are
being changed so the error will not occur again."
-------------------------------------------------------------------------------
====================================
Data Looted from SSA and FBI Systems
====================================
Associated Press, Dec 18, 1991
Associated Press writer Joseph Neff reports from Newark, NJ that eighteen
private investigators and Social Security Administration employees in nine
states were charged Wednesday with buying and selling confidential data
>from SSA and FBI computers. The information included earnings histories and
criminal records. The private investigators, many advertising in legal
journals, sold the information to companies. If convicted on all counts, the
defendants face maximum sentences of 20 to 150 years and multimillion dollar
fines.
-------------------------------------------------------------------------------
====================================
Taurus Poised to Clear Final Hurdles
====================================
Financial Times, Dec 19, 1991
The UK government appeared yesterday to have overcome legal obstacles to
the introduction of Taurus, the London Stock exchange's much delayed computer
settlement system. After more of a year of effort by the Department of Trade
and Industry lawyers, formal regulations were laid before parliament which
would create the legal framework necessary for Taurus. At the same time a
safeguard for personal shareholders, which had been built into the Taurus
system at the request of ministers has been dropped.
Investors would have had to quote confidential 13-digit personal
authorization codes before being able to deal in their shares. This
requirement has now been judged too cumbersome for the small amount of extra
security it would have bought. Instead shareholders will be able to tell the
registrars who maintain their shareholders only to transfer their shares after
they receive written instructions. This extra level of security will be
available only to investors who specifically request it.
The legal changes tabled yesterday are needed because share certificates
and transfer forms, currently required by law to give evidence of title and
enable a change of title to take place, will cease to be produced under the
new, paperless system of share ownership and dealing.
-------------------------------------------------------------------------------
==========================================================
Computer Database of Former E. German State Police (Stasi)
==========================================================
Source unknown, Winter 1991
An unverified report indicates that a German private detective agency that was
thought to be operated by former Stasi members bought a computer database
containing the names and salaries of 97,058 members of the Stasi in 1989. The
detective agency then pressed charges against the computer specialist who sold
them the information. The charges are not indicated, although they may be
under the strict (West) German privacy laws. If so, Stasi support for privacy
is new. In addition to their prying into the lives of (East) German citizens,
the Stasi had agents actively hacking into West German systems, including
Berlin's drivers license agency.
-------------------------------------------------------------------------------
==============================================
Recent Novell Software Contains a Hidden Virus
==============================================
John Markoff, New York Times, Dec 20, 1991
The nation's largest supplier of office-network software for personal
computers has sent a letter to approximately 3,800 customers warning that it
inadvertently allowed a software virus to invade copies of a disk shipped
earlier this month.
The letter, sent on Wednesday to customers of Novell Inc., a Provo, Utah,
software publisher, said the diskette, which was mailed on Dec. 11, had been
accidentally infected with a virus known by computer experts as "Stoned 111."
A company official said yesterday that Novell had received a number of
reports from customers that the virus had invaded their systems, although
there had been no reports of damage.
But a California-based computer virus expert said that the potential for
damage was significant and that the virus on the Novell diskette frequently
disabled computers that it infected.
'Massive Potential Liabilities'
"If this was to get into an organization and spread to 1,500 to 2,000
machines, you are looking at millions of dollars of cleanup costs," said
John McAfee, president of McAfee & Associates, a Santa Clara, Calif. antivirus
consulting firm. "It doesn't matter that only a few are infected," he said.
"You can't tell. You have to take the network down and there are massive
potential liabilities." Mr. McAfee said he had received several dozen calls
>from Novell users, some of whom were outraged.
The Novell incident is the second such case this month. On Dec. 6, Konami
Inc., a software game manufacturer based in Buffalo Grove, 111. wrote
customers that disks of its Spacewrecked game had also become infected with an
earlier version of the Stoned virus. The company said in the letter that it
had identified the virus before a large volume of disks had been shipped to
dealers.
Source of Virus Unknown
Novell officials said that after the company began getting calls earlier
this week, they traced the source of the infection to a particular part of
their manufacturing process. But the officials said they had not been able to
determine how the virus had infected their software initially.
Novell's customers include some of nation's largest corporations. The
software, called Netware, controls office networks ranging from just two or
three machines to a thousand systems.
"Viruses are a challenge for the marketplace," said John Edwards,
director of marketing for Netware systems at Novell. "But we'll keep up our
vigilance. He said the virus had attacked a disk that contained a help
encyclopedia that the company had distributed to its customers.
Servers Said to Be Unaffected
Computer viruses are small programs that are passed from computer to
computer by secretly attaching themselves to data files that are then copied
either by diskette or via a computer network. The programs can be written to
perform malicious tasks after infecting a new computer, or do no more than
copy themselves from machine to machine.
In its letter to customers the company said that the Stoned 111 virus
would not spread over computer networks to infect the file servers that are
the foundation of networks. File servers are special computers with large
disks that store and distribute data to a network of desktop computers.
The Stoned 111 virus works by attaching itself to a special area on a
floppy diskette and then copying itself into the computer's memory to infect
other diskettes.
But Mr. McAfee said the program also copied itself to the hard disk of a
computer where it could occasionally disable a system. In this case it is
possible to lose data if the virus writes information over the area where a
special directory is stored.
Mr. McAfee said that the Stoned 111 virus had first been reported in
Europe just three months ago. The new virus is representative of a
class of programs known as "stealth" viruses, because they mask their
location and are difficult to identify. Mr. McAfee speculated that
this was why the program had escaped detection by the company.
Steps Toward Detection
Novell has been moving toward adding new technology to its software to
make it more difficult for viruses to invade it, Mr. Edwards said. Recently,
the company licensed special digital-signature software that makes it
difficult for viruses to spread undetected. Novell plans to add this new
technology to the next major release of its software, due out at the end of
1992.
In the past, courts have generally not held companies liable for damages
in cases where a third party is responsible, said Susan Nycum, a Palo Alto,
Calif., lawyer who is an expert on computer issues. "If they have been
prudent it wouldn't be fair to hold them liable," she said. "But ultimately it
may be a question for a jury."
-------------------------------------------------------------------------------
======================
GTE Sells Sprint Stake
======================
USA Today, Jan 3, 1992
GTE said it is selling its 19% stake in long-distance phone company US Sprint
to majority owner United Telecommunications for $530 million. The sale ends a
partnership in which GTE and United Telecom combined their long distance
subsidiaries to create US Sprint in 1986. United Telecom said it will adopt
the Sprint name after completion of the deal, expected by the end of this
month. United Telecom Chairman WIlliam Esrey said the deal achieves a
long-time goal of total ownership of Sprint.
-------------------------------------------------------------------------------
====================
Caller ID in Chicago
====================
USA Today, Jan 3, 1992
Caller ID -- a service that reveals caller's number before the phone is
answered -- became available to most Chicago area Illinois Bell customers.
About 5,000 of 1.8 million eligible bought service, which costs an extra $6.50
monthly.
-------------------------------------------------------------------------------
==============================================
When the Phone Rings, You'll See Who's Calling
==============================================
Craig Crossman, Knight-Ridder Newspapers, Dec 26, 1991
Q. I have the new Caller ID service that displays the phone number of an
incoming call before I answer the phone. The problem is that it only displays
the number. I want to know if there is any way I can have my computer look up
the name of the person who's calling?
A. The problem with Caller ID is that it gives only the number, date and
time of an incoming call. You still don't know who the caller is.
A new product called Caller ID+Plus does just what you described and more.
It incorporates Rochelle Communications' ANI-32 Caller ID Computer Adaptor and
a special data base program that can run at the same time you are running other
programs. The 21/2-inch adapter plugs into your computer's serial port.
The provided telephone cable plugs into a standard modular phone jack. A
"T" adapter is also included, which gives you another jack to hook your
telephone into.
When an incoming call is detected, the program instantly compares the
detected phone number to your data base of up to 65,000 contacts. When a match
is detected, you are presented with all of the person's data that you have on
file, such as name, title, business and address, in a window.
The program has many capabilities. For example, you can store notes about
the call as well as notes from previous telephone conversations. You can also
display a log of all of the previous calls received from or made to the caller
including date, time and duration. All of this data is instantly displayed on
your screen before you pick up the phone.
Currently, you must manually enter names, addresses and telephone numbers
into your computer. Rochelle is planning a product that will take advantage of
commercially available telephone directories on CD-ROM. A single CD-ROM can
encompass every name, telephone number and address in the United States.
Caller ID+Plus requires an IBM PC or compatible with one available RS-232
serial port. It sells for $295. [Rochelle Communications Inc., (800) 542-8808
or (512) 794-0088]
-------------------------------------------------------------------------------
===============================================
Seized Computer Reveals Sophisticated Operation
===============================================
Mark Magnier, Journal of Commerce Nov 26, 1991
SINGAPORE -- Three U.S. software companies seized two personal computers
and various financial records in late October and early November, as part of
the raids against alleged software pirates Ong Seow Pheng and Tan Pui Fun in
Singapore.
Jeffrey Siebach, regional counsel of Lotus Development Corp., one of the
companies pursuing the case, says he received a call a few days after the raid
>from Ong's attorney.
"His lawyer called us and said, `We need all his books back because his
business has ground to a halt." After I picked my jaw up, I said, "You've got
to be kidding," Siebach said. "These guys don't see it as a moral issue at
all."
Only when the three U.S. software companies -- Lotus, Digital Research Inc.
and Novell Inc. -- turned on one of the personal computers did they realize how
sophisticated the operation was.
"We were amazed, to tell you the truth," said Siebach, who is also regional
vice president for the Business Software Alliance, an industry trade group that
initiates raids and lawsuits against pirates worldwide.
The first thing they were greeted with was a computer display that said,
"Welcome to the Ong Family of Businesses." A further search found over 450
computerized financial spread sheets with detailed sales and accounting
figures. These are being analyzed by Coopers & Lybrand, international
accountants.
Ong also had a detailed knowledge of and worked around BSA activities. For
instance, he knew the software alliance was concerned with business software
but not video game software, so its business software manuals were printed
offshore in Indonesia while its game manuals were printed in Singapore, Siebach
said. The group is investigating whether Ong had an interest in the printing
operations as well.
Ong would also write to retailers and suppliers telling them to be careful
because the alliance was active in their area, or telling suppliers to ship
only when he gave the green light.
He also had worked into his financial plan a contingency for getting
caught, Siebach said. He figured that the maximum fine in Singapore was the
equivalent of $59,172 (S$100,000) and calculated that the alliance normally
settled for damages and attorneys fees, so he had worked out a figure.
"He was ready for this," Siebach said. "It was a cost of doing business."
Ong is said to have been operating since at least 1988. As outlined, he
would acquire legitimate copies of a full range of software programs and video
games from U.S. mail-order outlets.
The original manuals were then sent to Indonesia, where they were illegally
copied and air-freighted back to Singapore as "technical manuals" for local and
regional distribution.
He sold the manuals along with a master copy to his retail customers, which
allowed them to copy off the master. One theory is that this saved him import
duties. Technical manuals face no Singapore import duties. Computer disks do.
Sources say he was able to maintain control by threatening to cut retailers
out of the lucrative trade and his access to the latest releases if they
crossed him.
The attorney adds that the operation appeared to enjoy strong loyalty from
its customers in part because of the low prices, but also because he could get
the product to market in some cases even before the legitimate dealers.
Siebach said he talked to one game distributor who had exclusive rights for
a new game that he planned to launch. Ong reportedly launched it before the
authorized dealer at a lower price, subsequently killing the authorized
dealer's market.
-------------------------------------------------------------------------------
==============================================
Computer Viruses Carry Threat to U.S.
Security, Military Admits its Systems Infected
==============================================
Bill Husted, The Atlanta Constitution, Nov 23, 1991
Military computers, including some used during the Persian Gulf War, were
infected by computer viruses that had the potential to destroy information or
bring a computer to a halt. Although the viruses proved to be more of a
nuisance than a disaster, they could have destroyed information used by
military commanders to make life-or-death battlefield decisions, Jim Christy,
director of computer crime investigation for the Air Force Office of Special
Investigation, said Friday.
Computer viruses - secretive programs designed to be electronic vandals
that damage data - are a continuing and increasing problem for the military,
Mr. Christy said. And, he added, there is the real fear that an enemy could
attack America using computer viruses capable of crippling communications and
computer systems.
There are unsubstantiated rumors that during the Gulf War viruses may have
spread to weapons that rely on computers to guide them. A virus attack on
these specialized computer systems would be very difficult. But some computer
experts, including Dr. David Stang, president of the National Computer Security
Association, said they heard rumors that the patriot missile - the high-tech
hero of the Gulf War - was infected by viruses.
The military acknowledged Friday that some of its computers - machines
identical to personal computers that are the workhorses of American business
- were infected. But Mr. Christy declined comment on whether any computer-
controlled weapon systems were affected. Mr. Christy would not say how many
military computers were infected during the war. But specialized defense and
computer publications say viruses were detected on thousands of computers.
Viruses are an increasing problem for all branches of the military, Mr.
Christy said. He said viruses discovered during the Gulf War probably weren't
planted by enemy agents. Instead, they may have come from something as
innocent as a computer game.
UNCONTROLLED SOFTWARE
"You have to remember that during Desert Shield, people were bringing
their own software from home, plus a lot of people went out and bought it," he
said. "It was a unique war. You could go out on the street and buy your own
software. And, to help morale, commanders were allowing their people to play
[computer] games."
Computer viruses are small programs that hide in another computer program
until they have a chance to duplicate themselves and move to a new computer.
While no apparent harm was done by viruses detected during the Gulf War, the
potential for disaster was great, Mr. Christy said.
"During Desert Storm, commanders made life-or-death decisions based on
information in a computer," he said. "I think it [the problems with military
computers] heightened the awareness of the viruses among Air Force commanders.
People didn't realize how necessary computers were to fight a war." And the
risk remains that viruses could be used as a weapon against military
computers, Mr. Christy said.
"I'm not sure it hasn't happened," he said. "It is awful hard to prove
intent. . . . We have so many viruses in the Air Force and some of them may be
intentional."
HOW AN ATTACK WOULD WORK
He said viruses, used by a terrorist or a foreign power, could sit and
wait for a remote signal before they do their work. "If you wanted to cripple
all the computer systems at one time, you'd wait for a certain time, and do
things like kill all of the Air Force traffic control computers," he said.
"People's lives would be at stake. Obviously an orchestrated attack would be
devastating."
Mr. Christy said computer viruses are a growing problem for the military.
"If you had asked me about it two or three years ago, I would have said that
the risk from virus was insignificant," he said. "We had two or three cases
of virus in the Air Force. But last year [they were so numerous] we had to
make an arbitrary decision that we would no longer investigate viruses [as a
crime]. We had found that in 100 percent of the cases, it was someone who had
unwittingly introduced the virus into the system."
He said, however, that while virus infections are not routinely prosecuted,
they are not ignored. A lot of the effort goes into finding ways to protect
military systems against a virus attack.
HACKERS CAN BE CULPRITS
Viruses are sometimes placed in military computers by hackers - computer
hobbyists who use their skills to break into computer systems. Hackers - who
use home computers and telephone lines to communicate with the Air Force
computer system - "routinely try to break in," Mr. Christy said. "I see
reports weekly about attempts to break into multiple systems."
The hackers have broken into computers containing unclassified
information, he said. It isn't all that difficult to do. Mr. Christy said
that he and his staff had broken into hundreds of Air Force computer systems
during exercises to test security.
Mr. Christy said that if a hacker placed a virus in any Air Force
computer, however, it might find its way into computers containing classified
information. Because of the potential that viruses have to cripple
computer-based weapons systems and disrupt civilian and military
communications, the Army has hired at least two private firms to develop ways
to defend against the viruses and to find out how to use computer viruses as
offensive weapons.
[ Editor's note: *SIGH* Isn't this the kind of sensationalistic journalism that
makes you want to toss your cookies? Some bored servicemen
discover that their IBM XT clone is infected with the "Stoner"
virus, causing them to lose their only copy of "Tetris" and
suddenly the press decides it must be a plot by 'mad hackers'
to shut down the Patriot Missile's targeting computer. ]
-------------------------------------------------------------------------------
=============================
Convicted Spy Granted Hearing
=============================
Associated Press, Jan 7, 1992
WASHINGTON (AP) A post-trial hearing will be held for an Air Force sergeant
who may not have understood the espionage charge to which he pleaded guilty,
the Air Force disclosed Tuesday. The proceeding Friday relates to the court
martial of Sgt. Jeffrey M. Carney, who admitted helping East German agents spy
on U.S. diplomats and military commanders in Berlin. He was sentenced Dec. 3 to
38 years in prison. Chief Trial Judge James Heupel ordered the court session.
The inquiry in a military courtroom at Andrews Air Force Base in Maryland
is
to ensure that Carney understood the espionage charge and his guilty plea to
it, the Air Force said in a statement. Carney also admitted copying classified
documents and passing them to the East Germans. He pleaded guilty to desertion
and conspiracy to commit espionage in addition to espionage.
Carney was a linguist and communications specialist at Tempelhof Central
Airport in Berlin, assigned to an electronics security group. In April 1984, he
was transferred to Goodfellow Air Force Base in Texas, a base for training
intelligence and communications specialists.
He deserted in 1985, defecting to East Germany. There, he intercepted,
translated and transcribed telephone calls of U.S. military commanders and
embassy officials stationed in Berlin, the Air Force said. Carney was arrested
last April 22 at his residence in what used to be the Soviet sector of Berlin.
------------------------------------------------------------------------------
==================
PC Virus Blackmail
==================
Information Week, Dec 16, 1991
A bizarre British court case involving computer viruses has pointed up
the vulnerability of users with careless policies on PC software. Hearing the
case of a U.S. scientist accused of computer blackmail late last month, the
court granted a stay after lawyers successfully argued that the defendant,
Joseph Popp, 41, was mentally ill. Popp was facing 11 charges of damaging
computer systems and attempting to obtain a total of 6 million pounds ($10.7
million) through blackmailing numerous medical institutes worldwide around
Christmas 1989.
Popp is alleged to have mailed more than 20,000 floppy disks to the
research institutes. He promoted the disks as containing valuable information
about AIDS. But the disks themselves contained a software virus, which has
since also been dubbed AIDS. When users tried to access the disk, they got
messages demanding 200 pounds (about $350) to eradicate the virus that had just
infected their systems.
Popp was extradited to the United Kingdom, where a chorus of scientists
>from universities and research institutes claimed that their software had been
damaged when the disks were loaded onto their systems.
One organization that fell foul of the virus was the Imperial Cancer
Research Fund in London. Dr. Ron Catterall, director of the fund's computer
research unit, was called as a witness for the prosecution. Catterall was
smart: He loaded the disk onto his stand alone PC rather than the network, and
warned other users as he discovered the virus. `It took a long time to find
out what was going on, and to clean up my machine,' he said. `It eventually
started overwriting the hard disk.'
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Informatik Submission & Subscription Policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Informatik is an ongoing electronic journal, and thus we are faced with
the ever present need for a steady influx of new material. If you have an
area of interest or expertise that you would like to write about, please do
not hesitate to contribute! We depend on reader submissions, especially for
the "Hot Flashes" news reports. We do ask that any submissions fit the
following guidelines...
General Content
~~~~~~~~~~~~~~~
Material for Informatik should concern information of interest to the
computer underground community. Examples of this include, but are by no
means limited to hacking and phreaking, governmental agencies, fraud,
clandestine activity, abuse of technology, recent advances in computing
or telecommunications technology, and other of information not readily
available to the public. Please include a title and author name.
Text Format
~~~~~~~~~~~
* standard ASCII test
* 79 characters per line
* no TAB codes
* no special or system specific characters
* mixed case type
News submissions
~~~~~~~~~~~~~~~~
* Submit only recent news items
* Include the headline or title of the article
the author's name (if given)
the publication of origin
the date of publication
Subscription policy
~~~~~~~~~~~~~~~~~~~
We are happy to provide an Internet based subscription service to our
readers. To be on our mailout list, send mail to our Internet address,
"inform@doc.cc.utexas.edu" and include the word subscription in the subject
of your message. If you requested a subscription before, you need to reply
again, because the old subscription list was deleted by MH.
/* End; Issue 02 */
Reference in New Issue View Git Blame Copy Permalink