22 Apr
2007
22 Apr
'07
7:27 a.m.
I've had an IMS 5000 system for about a year; I got it off ebay for a
song ($35), but as I didn't know any login name and corresponding
password, it has been a brick. I've thought of a couple ways to break
the security, which isn't all that secure, but didn't due to lack of
time. Finally I made time last night.
The machine specifically is an IMS 5000 IS. It is a very well built
late model S-100 system, aimed at professional applications. This one
came from a dentists office. The main unit contains a 12" CRT, an
intelligent terminal control board (8085 based) which is connected via
an internal serial port to a Z80 CPU card in the main S-100 chassis.
This is a turbodos system, meaning it is a multiprocessing Z80 system.
Serial ports on the back of the machine can connect to remote terminals;
I have one other remote head, also made by IMS.
The machine has a 10MB Rodime hard drive, still working, a single DSDD
floppy (although there is room for another), a master Z80 CPU, a 64KB
parity checked DRAM card, and two MPUs. An MPU is a card containing a
slave Z80 processor with its own 64KB parity checked DRAM and serial
ports, etc.
Although I have the docs showing the gross functionality, I have no
schematics for any of this.
First I rebuilt disk images from Fritz Chwolka's webpage for the IMS
5000, but for whatever reason I couldn't boot these disks. IMS made
more than one configuration of this machine, so it wasn't entirely
unexpected. Next I tried a hardware approach.
The hard disk controller has a 1KB SRAM buffer for holding an inbound or
outbound sector. Programmed IN/OUT transfers fill or drain the buffer,
not DMA. First I verified that the address lines on the RAM were wired
in conventional order by seeing what pins they were wired to on the
74LS193s forming the address counter. The data pin order was more of a
question, but I assumed since the address lines were connected in
consecutive order, so the data pins would be too. I hooked up a logic
analyzer to the RAMs, booted the system, and waited for the password
prompt. I typed some gibberish and hit return, and the logic analyzer
captured the writes to the RAM. I realized the first read or maybe
first few would be reading directory entries to find the USERID.SYS
file, which is a plain text file containing the login names, passwords,
cp/m user area, and privilege level. However, no matter what I did, the
data didn't make sense.
I thought perhaps I messed up the order of the data pins, so I buzzed
out which chip drove the DOn (data out) S100 pins. Again, I did the
login thing, assuming that any time this sector buffer ram was being
read that the data would be appearing on the S100 bus. Apparently not so.
So I switched gears. I shuffled cards around to make space and
connected the logic analyzer to the Z80 and set a trigger for I/O port
operations, triggering on the first IN from the port corresponding to
the sector buffer. Pay dirt. I quickly got the list of users and
passwords, and tried them and they worked.
After disconnecting the logic analyzer, I captured the contents of the
various EPROMs, then called it a night. Bitsavers and Fritz Chwolka
both have interesting web pages, so I won't attempt to duplicate any of
that, but I will be taking some pictures, posting the HEX files for the
EPROMS and making links to the other IMS 5000 resources on the web.
22 Apr
22 Apr
7:42 a.m.
[Sorry for the "top post"...]
Great sleuthing Jim - and a very informative writeup!!! Thanks.
Lyle
On Sunday 22 April 2007 07:27, Jim Battle wrote:
I've had an IMS 5000 system for about a year; I
got it off ebay for a
song ($35), but as I didn't know any login name and corresponding
password, it has been a brick. I've thought of a couple ways to break
the security, which isn't all that secure, but didn't due to lack of
time. Finally I made time last night.
The machine specifically is an IMS 5000 IS. It is a very well built
late model S-100 system, aimed at professional applications. This one
came from a dentists office. The main unit contains a 12" CRT, an
intelligent terminal control board (8085 based) which is connected via
an internal serial port to a Z80 CPU card in the main S-100 chassis.
This is a turbodos system, meaning it is a multiprocessing Z80 system.
Serial ports on the back of the machine can connect to remote terminals;
I have one other remote head, also made by IMS.
The machine has a 10MB Rodime hard drive, still working, a single DSDD
floppy (although there is room for another), a master Z80 CPU, a 64KB
parity checked DRAM card, and two MPUs. An MPU is a card containing a
slave Z80 processor with its own 64KB parity checked DRAM and serial
ports, etc.
Although I have the docs showing the gross functionality, I have no
schematics for any of this.
First I rebuilt disk images from Fritz Chwolka's webpage for the IMS
5000, but for whatever reason I couldn't boot these disks. IMS made
more than one configuration of this machine, so it wasn't entirely
unexpected. Next I tried a hardware approach.
The hard disk controller has a 1KB SRAM buffer for holding an inbound or
outbound sector. Programmed IN/OUT transfers fill or drain the buffer,
not DMA. First I verified that the address lines on the RAM were wired
in conventional order by seeing what pins they were wired to on the
74LS193s forming the address counter. The data pin order was more of a
question, but I assumed since the address lines were connected in
consecutive order, so the data pins would be too. I hooked up a logic
analyzer to the RAMs, booted the system, and waited for the password
prompt. I typed some gibberish and hit return, and the logic analyzer
captured the writes to the RAM. I realized the first read or maybe
first few would be reading directory entries to find the USERID.SYS
file, which is a plain text file containing the login names, passwords,
cp/m user area, and privilege level. However, no matter what I did, the
data didn't make sense.
I thought perhaps I messed up the order of the data pins, so I buzzed
out which chip drove the DOn (data out) S100 pins. Again, I did the
login thing, assuming that any time this sector buffer ram was being
read that the data would be appearing on the S100 bus. Apparently not so.
So I switched gears. I shuffled cards around to make space and
connected the logic analyzer to the Z80 and set a trigger for I/O port
operations, triggering on the first IN from the port corresponding to
the sector buffer. Pay dirt. I quickly got the list of users and
passwords, and tried them and they worked.
After disconnecting the logic analyzer, I captured the contents of the
various EPROMs, then called it a night. Bitsavers and Fritz Chwolka
both have interesting web pages, so I won't attempt to duplicate any of
that, but I will be taking some pictures, posting the HEX files for the
EPROMS and making links to the other IMS 5000 resources on the web.
--
Lyle Bickley
Bickley Consulting West Inc.
Mountain View, CA
http://bickleywest.com
"Black holes are where God is dividing by zero"
9:09 a.m.
I've had an IMS 5000 system for about a year; I
got it off ebay for a
song ($35), but as I didn't know any login name and corresponding
password, it has been a brick. I've thought of a couple ways to break
the security, which isn't all that secure, but didn't due to lack of
time. Finally I made time last night.
Fascinating! Seriously, that's a really clever way to go about it.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Don't have a spasm. -- Nabiki, "Ranma 1/2"
---------------------------------
10:53 a.m.
Jim Battle wrote:
I've had an IMS 5000 system for about a year; I
got it off ebay for a
song ($35), but as I didn't know any login name and corresponding
password, it has been a brick. I've thought of a couple ways to break
the security, which isn't all that secure, but didn't due to lack of
time. Finally I made time last night.
I forgot to mention a couple points.
First, the turbodos password system is weak for a couple reasons. One,
the password file is stored as plaintext. Second, when you attempt to
log in, it asks for login name, and if it isn't in the list, rejects it
before asking for the password. Thus rather than having to guess a
combination of (user, password), on only has to guess them sequentially.
Still, CP/M didn't have any type of protection, so it was an improvement.
A given login was marked as either having privilege or not, and also the
user number associated with that user. When a successful login and
password were entered, the user # (turbodos has users 0-31, not just
0-15 like CP/M) associated with the account establishes where your
directory is set to. The privileged accounts get to "USER n" to go
anywhere they want to, but the other accounts can't use USER to change.
Anyway, the final password file was:
(login, password, user#, privilege flag)
SYSTEM,SYSTEM,0,P
USER1,USER1,1,
USER2,USER2,2,
USER3,USER3,3,
DEN,,,
USER4,USER4,4,
WATER,WATER,6,
I don't think I would have guessed any of them, except maybe SYSTEM.
When I first got the machine I had tried about 50 names that came to the
top of my head.
Having looked around at the disk, user 0 has all the utilities. User 3,
DEN (short for dentist, I'm sure) had some bookkeeping files and apps.
User 31 is used by turbodos to hold some other utility files, including
the password file. Other than that, there is nothing on the disk.
There isn't any source code, games, or anything interesting at all.
Having just installed Turbodos on a NS Horizon 8/16 box, it is
interesting to note that this turbodos system is different, even though
both are turbodos 1.3. I'll need more time to explore, but this machine
seems to have a more limited set of utility applications available.
4:48 p.m.
Jim Battle wrote:
I've had an IMS 5000 system for about a year; I
got it off ebay for a
song ($35), but as I didn't know any login name and corresponding
password, it has been a brick. I've thought of a couple ways to break
the security, which isn't all that secure, but didn't due to lack of
time. Finally I made time last night.
[Snip]
So I switched gears. I shuffled cards around to make space and
connected the logic analyzer to the Z80 and set a trigger for I/O port
operations, triggering on the first IN from the port corresponding to
the sector buffer. Pay dirt. I quickly got the list of users and
passwords, and tried them and they worked.
After disconnecting the logic analyzer, I captured the contents of the
various EPROMs, then called it a night. Bitsavers and Fritz Chwolka
both have interesting web pages, so I won't attempt to duplicate any
of that, but I will be taking some pictures, posting the HEX files for
the EPROMS and making links to the other IMS 5000 resources on the web.
Jerome Fine replies:
Thank you for the information. It should be useful in
another context to provide a clue as to how to proceed.
For example, if a duplicate of the hard drive can be produced,
then running under an emulator might be similar to hooking up
a logic analyzer. This would be a software solution.
Of course, having a duplicate of the hard drive would usually
allow a user to run the same software and look at the various
files, such as the one which contains the userid / passwords.
On the other hand, I suspect that the actual clear text of
the userid / passwords should never have been stored in a
file in the first place. If that is what you described (based
on what you specified above), that was a VERY serious error
in the security of the system. Rather, an encrypted set of
values should have been stored with an algorithm which does
not allow a reverse of the values. Then when an actual
userid / password is entered, the algorithm produces the
encrypted values which are extremely difficult to produce
and compares the encrypted values against the file values.
Of course, that is not what you wanted, so you were able to
find a solution. It shows what debugging at the hardware
level can do when the right equipment is available. In
short, don't ever rely on encrypted files on a system which
also contains the code to decrypt the files or the private
passwords required for the algorithm.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
5:16 p.m.
New subject: old school security (was: IMS 5000 system password filed cracked)
In article <462BF461.4090406 at compsys.to>,
"Jerome H. Fine" <jhfinedp3k at compsys.to> writes:
On the other hand, I suspect that the actual clear
text of
the userid / passwords should never have been stored in a
file in the first place. If that is what you described (based
on what you specified above), that was a VERY serious error
in the security of the system. [...]
Lots of systems made that error. For instance, RSTS/E stored the
passwords in cleartext and you could list them out if you were a
privileged (1,*) user. I discovered that when you submitted a batch
job through the @ processor, it ran as user batch on account (1,2).
So it wasn't too hard to submit a batch job that ran the ACCOUN
program to list out the passwords.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
5:47 p.m.
New subject: old school security (was: IMS 5000 system password filed cracked)
In TSS/8, there was an IOT ("WHO") that would return the current user's
username AND password in Rad50. It was simple to walk up to a terminal
someone had stepped away from for a few seconds, deposit and few values
from the command line, jump to it, examine the results,
and walk away with
the values for later decoding to alphanumeric (ascii)
characters.
The TSS/8 o/s at UWM (Milwaukee) was extensively rewritten, in part to
close those gaps. I don't know if it was Dick Bartlein or Sam Milosevich or
other folks (Al would probably know). They gave it real security, replacing
the WHO IOT with (I think) a LOGIN IOT.
They also made it refuse a login request unless you prefaced it with ^B.
That character would always break through to the o/s even if a program was
running, and prevented a form of trojan horse, wherein you could write a
simple program that would simulate the login prompts, capture your
username/password, stash it in a file, and silently log out. If you
attempted a login with that sort of trojan running, the o/s would intercept
the attempt, prevent the trojan from seeing any characters, and respond
?ALREADY LOGGED IN
-t
At 06:16 PM 4/22/2007 -0600, you wrote:
In article <462BF461.4090406 at compsys.to>,
"Jerome H. Fine" <jhfinedp3k at compsys.to> writes:
-----
784. [Kindness] Kind words do not cost much. Yet they accomplish much.
--Blaise
Pascal
--... ...-- -.. . -. ----. --.- --.- -...
tpeters at nospam.mixcom.com (remove "nospam") N9QQB (amateur radio)
"HEY YOU" (loud shouting) WEB: http://www.mixweb.com/tpeters
43? 7' 17.2" N by 88? 6' 28.9" W, Elevation 815', Grid Square
EN53wc
WAN/LAN/Telcom Analyst, Tech Writer, MCP, CCNA, Registered Linux User 385531
On the other hand, I suspect that the actual
clear text of
the userid / passwords should never have been stored in a
file in the first place. If that is what you described (based
on what you specified above), that was a VERY serious error
in the security of the system. [...]
Lots of systems made that error. For instance, RSTS/E stored the
passwords in cleartext and you could list them out if you were a
privileged (1,*) user. I discovered that when you submitted a batch
job through the @ processor, it ran as user batch on account (1,2).
So it wasn't too hard to submit a batch job that ran the ACCOUN
program to list out the passwords.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/> 
9:35 p.m.
New subject: old school security
An early generation of the Tandem (I'm gonna guess TNS-II) running the default shell
"COMINT" had the following pretty big weakness out of the box.
The logins and passwords were stored in cleartext in a file (my fuzzy memory says it was
probably called $SYSTEM.SYSTEM.USERID or USERS). You couldn't read it, however, if
you didn't have the supervisor login (usually called SUPER.SUPER, although at one
place I recall it being called SUPER.DUPER, either way being userid 255,255).
However, anyone could start a new instance of COMINT, which would start up in a logged off
state. The weakness was that you could also manually specify a "swap file" for
any program execution, rather than let the system automatically create a temporary file
for that purpose. You would start COMINT like this:
:COMINT/SWAP $DATA.MYFILES.MYSWAP/
and then it would create that memory swap file in your subvolume as it ran.
Then, attempt to log in. COMINT would read the userid file into memory, which would cause
it to be written into the swap file. Then, stop this instance of COMINT (you might have
to log in successfully as someone first in order to be able to stop the process with
Ctrl-Y (EOF!)), and check out your saved swap file to find the contents of the userid file
somewhere in there in cleartext.
They patched this hole later.
Disclaimer: This is all from memory from almost 30 years ago, and I was only around 9
years old at the time.
- Ken
24 Apr
24 Apr
6:18 p.m.
New subject: - old school security
Richard wrote:
Lots of systems made that error. For instance, RSTS/E
stored the
passwords in cleartext and you could list them out if you were a
privileged (1,*) user. I discovered that when you submitted a batch
job through the @ processor, it ran as user batch on account (1,2).
So it wasn't too hard to submit a batch job that ran the ACCOUN
program to list out the passwords.
Jerome Fine replies:
Perhaps Zane is following this thread or anyone else
who knows VMS well. I seem to remember that the
userid / password were placed through the same algorithm
as the stored values. The results were compared and
that was what produced a match. In addition, I also
understand that it was impossible to reverse the results
of the "encryption" algorithm. And with later versions
of VMS, the choice of the password was restricted, possibly
to a string produced at random by VMS itself; this latter
feature prevented users from having the name of a special
individual as the password.
Does anyone know of any other operating system which requires
secure passwords along with storing only the encrypted
equivalents of the userid / password?
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
6:51 p.m.
New subject: - old school security
At 09:18 PM 4/24/2007, Jerome H. Fine wrote:
It's not reversible because a hash algorithm is used. A hash
deliberately "throws away" information, distilling a string into a
smaller representation. (You can't reconstruct an apple from a bowl of
applesauce.) That's a common operating system concept first employed by
Unix systems.
Richard wrote:
Lots of systems made that error. For instance,
RSTS/E stored the
passwords in cleartext and you could list them out if you were a
privileged (1,*) user. I discovered that when you submitted a batch
job through the @ processor, it ran as user batch on account (1,2).
So it wasn't too hard to submit a batch job that ran the ACCOUN
program to list out the passwords.
Jerome Fine replies:
Perhaps Zane is following this thread or anyone else
who knows VMS well. I seem to remember that the
userid / password were placed through the same algorithm
as the stored values. The results were compared and
that was what produced a match. In addition, I also
understand that it was impossible to reverse the results
of the "encryption" algorithm. And with later versions
of VMS, the choice of the password was restricted, possibly
to a string produced at random by VMS itself; this latter
feature prevented users from having the name of a special
individual as the password.
In other words, forced generated passwords. Many other OSs allow this;
for example, DEC UNIX.
Does anyone know of any other operating system which
requires
secure passwords along with storing only the encrypted
equivalents of the userid / password?
Lots and lots of 'em. Most unix compatible systems, windows, etc.
VMS did not encrypt usernames, BTW. Just passwords.
Here's what I see if I edit SYSUAF.DAT on my system:
**DEFAULT *************
**DGS *************
**FIELD *************
**MURPHY *************
**SYSTEM *************
**SYSTEST *************
**SYSTEST_CLIG *************
**TCPIP$FTP *************
**TCPIP$REXEC *************
**TCPIP$RSH *************
-Rick
25 Apr
25 Apr
12:09 p.m.
New subject: - old school security
On Tue, 24 Apr 2007, Rick Murphy wrote:
It's not reversible because a hash algorithm is
used. A hash
deliberately "throws away" information, distilling a string into a
smaller representation. (You can't reconstruct an apple from a bowl of
applesauce.) That's a common operating system concept first employed by
Unix systems.
Yes, but it is possible, either by brute force or clever programming, to
write a job that will produce a string that will hash to the same hashcode
as the target password. With a 16bit hashcode, a set of 65536 strings can
be made and sequenced that will work for any 16 bit hashcode with that
algorithm. It will most likely be a nonsense string of characters, rather
than the name of the user's canary, but it will work.
In fact, if you were to start filling in the table with a
dictionary/namelist approach, many of the "passwords" will actually match!
Just how common ARE "sex", "love", and "god"?
The remainder of the table can be completed using the nine billion names
of god.
That is why the hashcode algorithm being used should be kept secret, and
access to the hashcodes for accounts shuld be limited.
How many people here remember any of the "master" passwords of TRS-DOS?
--
Grumpy Ol' Fred cisin at xenosoft.com
1:04 p.m.
New subject: - old school security
It's not
reversible because a hash algorithm is used. [...]
Yes, but it is possible, either
by brute force or clever programming,
to write a job that will produce a string that will hash to the same
hashcode as the target password. With a 16bit hashcode, a set of 65536 strings can be
made and
sequenced that will work for any 16 bit hashcode with that algorithm.
Yes and no. This is true provided the algorithm is not salted, or you
consider each salt as a separate algorithm - or as part of the hashcode
size. Otherwise, your dictionary size must be multipled by the number
of possible salts - that's what salts are *for*.
It will most likely be a nonsense string of
characters, rather than
the name of the user's canary, but it will work.
Not necessarily; for example, if it contains NL or NUL characters, it
will not work as a Unix password, even if it does produce the correct
hash when shoved through the algorithm.
In fact, if you were to start filling in the table
with a
dictionary/namelist approach, many of the "passwords" will actually
match!
This has been done. It's why password hashes are salted - to multiply
the necessary dictinoary size by the number of possible salts.
That is why the hashcode algorithm being used should
be kept secret,
Security through obscurity? Doesn't work. Certainly not in a case
like this, where implementations of the algorithm are, perforce,
widespread.
and access to the hashcodes for accounts shuld be
limited.
That helps, a little, but it's a belt-and-suspenders measure.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5 p.m.
New subject: - old school security
On Wed, 25 Apr 2007, der Mouse wrote:
Your brute force algorithm should be limited to keyboardable characters
that are accepted by that OS.
In terms of entry, it makes no difference. But it is helpful if there is
alternate access to the drive (booting with another OS or reading sectors
elsewhere), and it helps to avoid unauthorized rights amplification.
--
Grumpy Ol' Fred cisin at xenosoft.com
By definition, if you can do better than brute force,
you need a better
hash algorithm.
Surprisingly, I've had students who had been taught that ALL one-way
functions are completely and totally uncrackable.
It will most
likely be a nonsense string of characters, rather than
the name of the user's canary, but it will work.
Not necessarily; for example, if it contains NL or NUL characters, it
will not work as a Unix password, even if it does produce the correct
hash when shoved through the algorithm. Security through obscurity? Doesn't work.
Certainly not in a case
like this, where implementations of the algorithm are, perforce,
widespread.
certainly not for long! I should have punctuated that in a manner
that
would imply sarcasm.
and access to
the hashcodes for accounts shuld be limited.
That helps, a little, but it's a
belt-and-suspenders measure.
26 Apr
26 Apr
7:40 a.m.
New subject: - old school security
> By definition, if you can do better than brute
force, you need a
> better hash algorithm.
Actually, this was a slight overstatement. If you can do much better
than brute force, then. For password hashing, slight biases don't
really matter much - a work factor of 2^63 is about as good as a work
factor of 2^64, and most biases won't skew things by as much as a whole
bit.
Surprisingly, I've had students who had been
taught that ALL one-way
functions are completely and totally uncrackable.
I don't find that surprising - which fact I find somewhat depressing.
The only hash function that reveals nothing of its source data is one
that maps everything to the same value - and such a one fails
second-preimage resistance rather catastrophically. :-)
It will most likely be a nonsense string of
characters, rather than
the name of the user's canary, but it will work.
Not necessarily; for example,
if it contains NL or NUL characters, 
8:08 a.m.
New subject: - old school security
On 4/26/07, der Mouse <mouse at rodents.montreal.qc.ca> wrote:
The only hash function that reveals nothing of its
source data is one
that maps everything to the same value - and such a one fails
second-preimage resistance rather catastrophically. :-)
But just *look* at that compression ratio!
-ethan
8:10 a.m.
New subject: - old school security
On 26/04/07, der Mouse <mouse at rodents.montreal.qc.ca> wrote:
Actually, couldn't one argue that if the function is crackable, it is
not one-way?
if f(A) = C and we can find B s.t. f(B) = C then the function is NOT
one-way for B.
Thus, unless you have a reliable way of determining if A is NOT in a
set comprising of all values that can be found by some hypothetical
f^-1() you do not have a one-way function. (Brute force exhaustive
search doesn't count, IMHO)
Thus, all one-way functions are uncrackable. But there are fewer
one-way functions than one would think...
Joe.
Surprisingly,
I've had students who had been taught that ALL one-way
functions are completely and totally uncrackable.
I don't find that surprising - which fact I find somewhat depressing.
12:49 p.m.
New subject: - old school security
> > Surprisingly, I've had students who had
been taught that ALL one-way
> > functions are completely and totally uncrackable.
>
> I don't find that surprising - which fact I find somewhat depressing.
On Thu, 26 Apr 2007, Joachim Thiemann wrote:
Actually, couldn't one argue that if the function
is crackable, it is
not one-way?
Good point.
I should have said "uncrackable systems using one way functions".
The function itself may be uncrackable, but the system using it is
crackable. The issue is not whether the original password can be
reproduced, but whether a working password can be generated.
Since users screw up, multiple attempts must be permitted. Rather than a
finite number of attempts followed by complete lockout, what I prefer is
an increasing delay amount. Each unsuccessful attempt can double the
length of time before another attempt is permitted. 2^^N seconds between
attempts will render brute force attacks futile, while still permitting
average users adequate opportunity to try a reasonable number of guesses.
But, there's prob'ly some basic flaw in that idea, also.
8:32 a.m.
New subject: - old school security
On 26 Apr 2007 at 10:40, der Mouse wrote:
Not that long ago, I was asked to defend a scheme of convolved
checksums and hashes that I used to protect a rather long data file
which would be used in legal actions. This was not a case of
detecting errors; it was also a case of detecting attempts at
intentional manipulation.
It was amazing to hear the "experts" proclaim that if just discarded
the more involved (and harder to manipulate) scheme with a single SHA
or MD5 hash, the file would be virtually bullet proof from any
attempts at manipulation and be much simpler to work with.
My response was that while such hashes do a good job of enabling one
to detect simple errors, we were dealing with a horse of different
color. My data file had no length or content that could be known in
advance. Simply adding an extra record or two to make the hash "come
out right" would be all that was required.
Convolved hashes, while not bulletproof, are considerably more
difficult to manipulate, particularly if one doesn't know where to
begin looking for them and what they are within the file.
But it was surprising to witness the pronoucement by people who had
set themselves up as "experts" made me very cynical about what it
took to be an expert. I later witnessed this when I was called on to
serve as editor on a technical book. The author was pretty much dumb
as a stump--he made extensive use of others' contributions and
thereby gained a reputation as an expert himself.
Cheers,
Chuck
Surprisingly,
I've had students who had been taught that ALL one-way
functions are completely and totally uncrackable.
I don't find that surprising - which fact I find somewhat depressing. 
1:37 p.m.
New subject: - old school security
"Chuck Guzis" wrote:
...
which would be used in legal actions. This was not a
case of
detecting errors; it was also a case of detecting attempts at
intentional manipulation.
It was amazing to hear the "experts" proclaim that if just discarded
the more involved (and harder to manipulate) scheme with a single SHA
or MD5 hash, the file would be virtually bullet proof from any
attempts at manipulation and be much simpler to work with.
Perhaps they where thinkings of a "signed" document, where the MD5
is encrypted with a private key...
but even if they were just talking about an MD5 hash, I think it would
be non-trivial to just add data to make the hash right. I'm not sure
you could do that with MD5, to be honest. hmmm... I'd claim an MD5
hash would pretty good, but should be protected also (via encryption).
(but I am not a crypto expert; hah. i can barely get out the door in the
morning)
-brad
25 Apr
25 Apr
1:15 p.m.
New subject: - old school security
On 25/04/07, Fred Cisin <cisin at xenosoft.com> wrote:
That is why the hashcode algorithm being used should
be kept secret, and
access to the hashcodes for accounts shuld be limited.
Uh-oh. I think you forgot to add a smiley there...
(If you didn't: this is a major security no-no! Keeping the
encryption algorithm secret is NEVER a good idea - didn't work for the
germans, never worked for anybody. There are many many books on the
topic that will explain better than I can in this list about why this
is the case.)
Joe.
5:04 p.m.
New subject: - old school security
> That is why the hashcode algorithm being used
should be kept secret, and
> access to the hashcodes for accounts shuld be limited.
On Wed, 25 Apr 2007, Joachim Thiemann wrote:
Uh-oh. I think you forgot to add a smiley there...
or quotes, to indicate sarcasm
(If you didn't: this is a major security no-no!
Keeping the
encryption algorithm secret is NEVER a good idea - didn't work for the
germans, never worked for anybody. There are many many books on the
topic that will explain better than I can in this list about why this
is the case.)
It's only good as a short term measure. The Navajo code-talkers weren't
cracked, but given sufficient additional time, the Japanese would have
been able. And a single POW could have compromised it totally.
1:16 p.m.
New subject: - old school security
On 4/25/07, Fred Cisin <cisin at xenosoft.com> wrote:
In fact, if you were to start filling in the table
with a
dictionary/namelist approach, many of the "passwords" will actually match!
Just how common ARE "sex", "love", and "god"?
I never found any of those when I used to run Crack on a quarterly
basis to look for weak passwords at a former job. I did find plenty
of trivial passwords like "abc" combined with small numeric suffixes
and/or prefixes, though - all found *very* quickly by Crack. The ones
that took the longest (2 out of 400 users) were dictionary words with
the common 1=i, 0=o sorts of substitutions and no punctuation. They
were cracked during my normal run, but not in the first 15 minutes.
Anything with just "abc" and numbers fell in seconds or minutes. We
did not allow enough time for a strict brute-force attack, so the half
of the users who did not use modified or unmodified words from a
dictionary fared well.
The closest thing I have to a match for the "classic" passwords was a
variant on what could be considered the cynical antonym of love...
"divorce". That user probably used to use 'love'.
How many people here remember any of the
"master" passwords of TRS-DOS?
Not me, but I did spend time with a sector editor/disk image editor to
extract the password in the Personal Software edition of Zork I.
-ethan
1:48 p.m.
New subject: - old school security
On 4/25/07, Fred Cisin <cisin at xenosoft.com>
wrote:
How many people here remember any of the "master" passwords of TRS-DOS?
http://www.tim-mann.org/trs80faq.html#[11]
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/
5:10 p.m.
New subject: - old school security
> How many people here remember any of the
"master" passwords of TRS-DOS?
On Wed, 25 Apr 2007, Mike Loewen wrote:
thank you!
Oddly enough, I don't see any mention of the backdoor password's use in
the copyright easter egg. (Changed from "RANDY COOK" to "TANDY CORP"
when
RS found out about it.)
26 Apr
26 Apr
1:25 p.m.
New subject: - old school security
On Wed, 2007-04-25 at 16:16 -0400, Ethan Dicks wrote:
. . . I did find plenty of trivial passwords like
"abc" combined with small numeric suffixes and/or
prefixes, though - all found *very* quickly by Crack.
The ones that took the longest (2 out of 400 users)
were dictionary words with the common 1=i, 0=o sorts
of substitutions and no punctuation. They were
cracked during my normal run, but not in the first
15 minutes.
Anything with just "abc" and numbers fell in seconds
or minutes. We did not allow enough time for a
strict brute-force attack, so the half of the users
who did not use modified or unmodified words from a
dictionary fared well.
I always loved the cat-and-mouse adventure of passwords... either
on the protection or breaking side -- it makes little difference to me.
One thing I have found that is a good compromise between being able to
remember it easily and being secure is as follows. If this list had
passwords, I might make one up as follows:
It's a list for old computers. My oldest is an IMSAI. It's a list
for OLD computers, so a related keyword would be, for me, "lawn," as in
"you kids get off of my lawn." Two words, and then a number... I got
my old computer in 1977.
So far, I have IMSAI, lawn, and 1977. I would be likely to come up
with those three words again, if I needed them. So, to secure them a
bit, I take one character from each, in rotation. The password thus
generated would be Il1Ma9Sw7An7I. Enjoy cracking THAT. I probably
should not have mentioned it...
Peace,
Warren E. Wolfe
wizard at voyager.net
2:16 p.m.
New subject: - old school security
On 26 Apr 2007 at 16:25, Warren Wolfe wrote:
It's a list for old computers. My oldest is
an IMSAI. It's a list
for OLD computers, so a related keyword would be, for me, "lawn," as in
"you kids get off of my lawn." Two words, and then a number... I got
my old computer in 1977.
That reminded me of something. In my 8" diskette files, I've got an
A1 (SSSD) product diskette from Public Key Systems for a product
called DEDICATE/32. Runs on an 8080 system, circa 1982. Anyone
interested? I may even have the docs for it--but no guarantee.
I've also got a copy of Mike Louder's Prime Factor BASIC for the
Apple ][. This is an arithmetic extension of Apple BASIC that allows
for stuff like modular arithmetic, arbitrary precision numerics, etc.
Cheers,
Chuck
25 Apr
25 Apr
1:53 p.m.
New subject: - old school security
That is why the hashcode algorithm being used should
be kept secret
No, quite the opposite. The hashcode algorithm should be as public as
possible so any weakness can be found. What keeps a hashcode secure is
the amount of time it takes to find collisions. The hashes
themselves, yes, keep those secret.
I have a string that has an MD5 hash of
d373a246bddeed37feec0c1c7c7b92ca. Find a string (this one or any
other) that has that hash. The algorithm for MD5 is well known, and
it is no longer considered to be cryptographic strength. It can't
take significantly more than 2^128 trials to find a match. At a
nanosecond per trial, that's only 10802614822886935348043 years to
complete the job. Certain weeknesses make it less secure than (since
there are ways of generating identical strings with identical MD5s if
you start with a known MD5 collision) you would really like for
passwords. But feel free to try coming up with a match for that one.
Now try to find the one that also has an sha1 hash of
d79b75daa96671379b52210e1e3bf341c061f1cf
Eric
4:38 p.m.
New subject: - old school security
> That is why the hashcode algorithm being used
should be kept secret
On Wed, 25 Apr 2007, Eric J Korpela wrote:
No, quite the opposite. The hashcode algorithm should
be as public as
possible so any weakness can be found. What keeps a hashcode secure is
the amount of time it takes to find collisions.
I REALLY should have put that in quotes or appended a smiley.
Security through obscurity can only work for a very short time.
I have a string that has an MD5 hash of
d373a246bddeed37feec0c1c7c7b92ca.
certainly each bit doubles the strength. I thought that we were talking
about relatively trivial ones of 16 bits, etc.
Now try to find the one that also has an sha1 hash of
d79b75daa96671379b52210e1e3bf341c061f1cf
Would probably have to do significant expansion of Gilmore's "Deep Crack".
2:17 p.m.
New subject: - old school security
Fred Cisin wrote:
In fact, if you were to start filling in the table
with a
dictionary/namelist approach, many of the "passwords" will actually match!
Just how common ARE "sex", "love", and "god"?
The remainder of the table can be completed using the nine billion names
of god.
Well not quite... The universe ended at the end of that story.
Rather quite hard to get the names re-printed again.
That is why the hashcode algorithm being used should
be kept secret, and
access to the hashcodes for accounts shuld be limited.
My gripe is all the stupid passwords needed to access almost anything on the
net, all kept safe until windows crashes.
--
Grumpy Ol' Fred cisin at xenosoft.com
.
4:31 p.m.
New subject: - old school security
> In fact, if you were to start filling in the
table with a
> dictionary/namelist approach, many of the "passwords" will actually
match!
> Just how common ARE "sex", "love", and "god"?
> The remainder of the table can be completed using the nine billion names
> of god.
On Wed, 25 Apr 2007, woodelf wrote:
Well not quite... The universe ended at the end of
that story.
Rather quite hard to get the names re-printed again.
just rerun the code
won't need or want printing (and binding), just generated opn the fly, or
stored in a file.
24 Apr
24 Apr
7:04 p.m.
New subject: - old school security
Jerome H. Fine wrote:
Perhaps Zane is following this thread or anyone else
who knows VMS well. I seem to remember that the
userid / password were placed through the same algorithm
as the stored values. The results were compared and
that was what produced a match. In addition, I also
understand that it was impossible to reverse the results
of the "encryption" algorithm.
That's called a one way function, or
a trap door. Modern day
equivalents would be cryptographic hashes such as MD5, SHA, SHA1,
SHA256. I don't recall the original Unix one, but it was based on some
rotor crypt, possibly inspired by the engima machine.
These were also "salted" which means that the OS would pick some random
byte to prevent dictionary brute force attacks against passwords. Not
sure if VMS had salted passwords. Such attacks exists today and are
called Rainbow-Tables and can be used against systems that lack salted
passwords.
Does anyone know of any other operating system which requires
secure passwords along with storing only the encrypted
equivalents of the userid / password?
Most flavors of Unix, *BSD do that.
8:43 p.m.
New subject: - old school security
On 4/24/07, Ray Arachelian <ray at arachelian.com> wrote:
These were also "salted" which means that
the OS would pick some random
byte to prevent dictionary brute force attacks against passwords. Not
sure if VMS had salted passwords.
My memory from working on COMBOARD software under VMS v3.x, v4.x, and
v5.x was that perhaps it did or didn't use salted password under v3,
but that under v4 and v5 it certainly did. Since our product could
submit take files received over the bisync or SNA link and submit them
to the VMS Batch queue long before there was a documented technique to
do so, we had to hash user-supplied passwords and compare them to what
was in the password file ourselves to ensure the user was authorized
to submit those jobs. ISTR that eventually, sometime after VMS 5.0,
it was possible to hand a plaintext password and username to a system
service call and confirm that the password was valid for that user. I
don't think you could get the hash back to inspect it, but the
important part was that you could make that check.
With enough time, I could probably dig up our code, c. 1983-1984, for
the one-way hash function. Over the timeframe we were doing it, I
also seem to recall that VMS did it more than one way, or at least we
had to make changes in how we did it at least once between 1981 and
1993.
-ethan
11:13 p.m.
New subject: - old school security
I don't recall the original Unix [password-hasing
one-way function],
but it was based on some rotor crypt, possibly inspired by the engima
machine.
The "traditional" Unix password hash is DES-based (the trivialized
Enigma code is crypt(1), not crypt(3)). Was there an even older
version? Did it ever escape Bell Labs?
For that matter, was enough publicly known about the Enigma at the time
to do that then?
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
25 Apr
25 Apr
11:50 a.m.
New subject: - old school security
On Wed, 25 Apr 2007, der Mouse wrote:
The "traditional" Unix password hash is
DES-based (the trivialized
Enigma code is crypt(1), not crypt(3)). Was there an even older
version? Did it ever escape Bell Labs?
For that matter, was enough publicly known about the Enigma at the time
to do that then?
I thought that Unix (1969) was developed well after WW2. Didn't WW2 end
in the 1940s? After WW2, the Enigma was well understood, and was no
longer an enigma.
The basic principles of the Enigma were well known, enough for the British
to make an emulator. It was the details of the wheels and the codes that
were hard to come by.
--
Grumpy Ol' Fred cisin at xenosoft.com
12:40 p.m.
New subject: - old school security
Fred Cisin wrote:
The basic principles of the Enigma were well known,
enough for the British
to make an emulator. It was the details of the wheels and the codes that
were hard to come by.
Indeed - the patent for the machine was granted in 1918 I think, and the
machine was intended as much for business as it was for military purposes;
there was just no interest initially because the price was too high.
1:27 p.m.
New subject: - old school security
On 25 Apr 2007 at 14:40, Jules Richardson wrote:
Indeed - the patent for the machine was granted in
1918 I think, and the
machine was intended as much for business as it was for military purposes;
there was just no interest initially because the price was too high.
There was an article on this subject in "Invention and Technology"
magazine some years ago. Few know that the basic mechanism for the
Enigma was invented by an American and unsuccessfully peddled to the
US Navy, who couldn't conceive of a need for such a thing. Great
minds at work...
Cheers,
Chuck
1:02 p.m.
New subject: - old school security
For that
matter, was enough publicly known about the Enigma at the
time to do that then?
I thought that Unix (1969) was developed well after WW2.
After WW2, the Enigma was well understood, and was no
longer an
enigma.
Not an enigma to the cryptographers who worked on breaking it, no. But
my understanding was that only recently was much of that data
declassified. Note that I said *publicly* known....
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
4:16 p.m.
New subject: - old school security
> After WW2, the Enigma was well understood, and
was no longer an
> enigma.
On Wed, 25 Apr 2007, der Mouse wrote:
Not an enigma to the cryptographers who worked on
breaking it, no. But
my understanding was that only recently was much of that data
declassified. Note that I said *publicly* known....
That makes sense. Many things are publicly known, but still classified.
(cointelpro, CIA cocaine smuggling, and many others, some of which only
hardcore conspiracy nuts know about)
30 Apr
30 Apr
8:51 a.m.
New subject: - old school security
der Mouse wrote:
It was, yes.
David Kahn's "The Codebreakers" published in 1968 (IIRC) had details of
Enigma,
including how rotors were wired. So at least by that time all the details of the
German and Polish military Enigmas were publicly available, if not publicly
known. Called a "dynamic substitution cipher", IIRC. Also had some details
about
PURPLE, the Japanese version of Enigma. The Enigma patent was publicly available
after the war.
First sV system I used had the Enigma two-rotor algorithm to encrypt passwords,
plus salt. That was in the late 1970's. Allowed characters were alphanumeric; no
spaces or punctuation to begin with. Later, punctuation was allowed but still no
spaces. I don't recall any sV or BSD system I used through to the late 80's
having anything but the Enigma style crypt function for passwords. Same for My
First Linux Computer(tm) in 1993. Didn't get hashing until about 1998. No spaces
allowed until after 32 char-plus passphrases were enabled some years later.
I have heard from veterans that ROT-13 was once used to encrypt passwords. I saw
it only once on a SysIII derived single-user system driving a PROM (not EPROM)
burner/tester.
I had fun finding passwords on a HP2000C/F BASIC timeshare system in 1973. Two
others were running brute force methods which were nothing more than programs
punching a few miles of tape for a few accounts using every possible sequential
ASCII character combination, excluding some forbidden combos. (Passwords could
be a mix of printing and nonprinting, or control characters.) Took them a couple
of weeks just to punch the tape on a KSR33--and they used six or so rolls
altogether--but they gave up after a few hours of reading the tape, due to the
problem of handling so much tape, IIRC. I got three admin passwords and one
group admin password (and so got the whole group's passwords) by just thinking
about it for a few days and trying most likely passwords. Got the group admin's
password on the second try and his supergroup account password on the third try.
Old school password cracking: Too trivial to be fun for long. Stack & buffer
overflows and mutating code--now that was fun!
And one could often gain a lot of info from what sysadmins & sysops would not
talk about.
--
jd
A UNIX saleslady, Lenore,
Enjoys work, but she likes the beach more.
She found a good way
To combine work and play:
She sells C shells by the seashore.
For that matter, was enough publicly known about the
Enigma at the
time to do that then?
I thought that Unix (1969) was developed well after WW2.
After WW2, the Enigma was well understood, and
was no longer an
enigma.
Not an enigma to the cryptographers who worked on breaking it, no. But
my understanding was that only recently was much of that data
declassified. Note that I said *publicly* known....
11:28 p.m.
New subject: - old school security
I don't recall any sV or BSD system I used through
to the late 80's
having anything but the Enigma style crypt function for passwords.
The mtXinu 4.3+NFS I used in the late '80s used DES-based password
hashing. Enigma-style encryption was present as crypt(1), but crypt(3)
was quite definitely salted-mutant-DES. SunOS of the same era also
used the same mutant-DES algorithm, but I have no memories to say just
how far back this was true.
I *think* this was also true of 4.2; until now I'd've assumed it was
also true of 4.1c before it, but that was an assumption - I can't
recall ever looking at the password handling code under 4.1c.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
1 May
1 May
4:23 a.m.
New subject: - old school security
One very trivial scheme I saw used once, more to hide from hex dumps
rather than actually encrypt, was to shift the enire bit stream over
by 4 bits. e.g. "memory", 6d 65 6d 6f 72 79, would be stored as 06
d6 56 d6 f7 27 90.
25 Apr
25 Apr
4:34 p.m.
New subject: - old school security
der Mouse wrote:
For that matter, was enough publicly known about the
Enigma at the
time
to do that then?
Didn't someone find out (_after_ the war) that Enigma (or an early
variant)
had been patented? Bletchley and Ultra wouldn't have been known about
then, but Enigma wasn't such a secret was it?
Antonio
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.463 / Virus Database: 269.6.0/775 - Release Date:
24/04/2007 17:43
24 Apr
24 Apr
7:22 p.m.
New subject: - old school security
At 9:18 PM -0400 4/24/07, Jerome H. Fine wrote:
No idea, sounds like that predates my VMS experience. I know there
were some holes in the pre-V5 days, but since V5 I think it's been
fairly secure.
I do know that at least with RSX-11M V4.2 it is possible to boot up
Richard wrote:
Lots of systems made that error. For instance,
RSTS/E stored the
passwords in cleartext and you could list them out if you were a
privileged (1,*) user. I discovered that when you submitted a batch
job through the @ processor, it ran as user batch on account (1,2).
So it wasn't too hard to submit a batch job that ran the ACCOUN
program to list out the passwords.
Jerome Fine replies:
Perhaps Zane is following this thread or anyone else
who knows VMS well. I seem to remember that the
userid / password were placed through the same algorithm
as the stored values. The results were compared and
that was what produced a match. In addition, I also
understand that it was impossible to reverse the results
of the "encryption" algorithm. And with later versions
of VMS, the choice of the password was restricted, possibly
to a string produced at random by VMS itself; this latter
feature prevented users from having the name of a special
individual as the password.
Does anyone know of any other operating system which requires
secure passwords along with storing only the encrypted
equivalents of the userid / password? from the console and dump the logins and passwords.
IIRC, they're
just plain text and you simply need high enough privileges to
view
the file.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
22 Apr
22 Apr
6:31 p.m.
consecutive order, so the data pins would be too. I
hooked up a logic
analyzer to the RAMs, booted the system, and waited for the password
prompt. I typed some gibberish and hit return, and the logic analyzer
captured the writes to the RAM. I realized the first read or maybe
first few would be reading directory entries to find the USERID.SYS
file, which is a plain text file containing the login names, passwords,
cp/m user area, and privilege level. However, no matter what I did, the
data didn't make sense.
What LA did you use, Jim?
Greetings from Brazil,
Alexandre
7:40 p.m.
Alexandre Souza wrote:
It is an HP1631D -- 1K deep trace memory, 25 MHz state, 100 MHz timing
modes, two analog channels, no floppy, gpib I/O only. It works OK for
as infrequently as I use it, but if I ever need to do any significant
work with with a logic analyzer, I'm going to get something a bit more
recent. Although I have five pods (of five) I have only four "wire
sets", and most of those are missing a wire or two, so I can't use some
of the channels. Not having an onboard floppy to save setup state is a
pain too.
Such logic analyzers go for $100 on ebay, and less if it doesn't have
lead sets.
consecutive
order, so the data pins would be too. I hooked up a logic
analyzer to the RAMs, booted the system, and waited for the password
prompt. I typed some gibberish and hit return, and the logic analyzer
captured the writes to the RAM. I realized the first read or maybe
first few would be reading directory entries to find the USERID.SYS
file, which is a plain text file containing the login names,
passwords, cp/m user area, and privilege level. However, no matter
what I did, the data didn't make sense.
What LA did you use, Jim?
Greetings from Brazil,
Alexandre
6445
days inactive
6454
days old
46 comments
26 participants
participants (26)
-
alexandre-listas＠e-secure.com.br -
arcarlini＠iee.org -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
brad＠heeltoe.com -
cclist＠sydex.com -
cisin＠xenosoft.com -
ethan.dicks＠gmail.com -
frustum＠pacbell.net -
healyzh＠aracnet.com -
jhfinedp3k＠compsys.to -
joachim.thiemann＠gmail.com -
julesrichardsonuk＠yahoo.co.uk -
kenzolist＠counterfolk.com -
korpela＠ssl.berkeley.edu -
lbickley＠bickleywest.com -
legalize＠xmission.com -
mloewen＠cpumagic.scol.pa.us -
mouse＠Rodents.Montreal.QC.CA -
onymouse＠garlic.com -
ray＠arachelian.com -
rick＠rickmurphy.net -
robert＠irrelevant.com -
spectre＠floodgap.com -
tpeters＠mixcom.com -
wizard＠voyager.net