MASRAD@UBVMSC.CC.BUFFALO.EDU (Rad) (07/05/88)
Kevin, > i have a program that im writing (BBS) that attempts to create a file > in my directory [by another user] I've been working slowly but surely on a BBS program during my free time over the last few years. The posting method that was used for a long time was done using an installed program. However, after a while I found this burdensome since I did not have access to the program that actually did the program. So, I went about writing a program to allow posting via other means. What I wanted was this; the ability for a user to make an addition to the file in my account, be able to log that that post was made along with a time stamp etc, and then leave the posting user only with read priveledges on the file. I've created a program (on paper) that does such a thing. I have actually created, and had beta-tested a program that allows certain users to be "sysops" of particular boards, while leaving them with no special priveledges to my account after they are done sysoping. I did this via network logins, aka "edit/password...etc..." My main worry in allowing such a program to be run by someone else was that they would be able to get my password from the program, since it is hardcoded into the program. However, after one failure and several attempts after this failure to break it, several so called "accomplished" hackers here were unable to break it. Is this the sort of beast you were looking for? If so, please let me know! I'll give you all the info and code I have! - Rad (Geoffrey A. Cashman) AT&T : (716) 836-9694 Snail : 361 LaSalle street Buffalo, NY 14215 BITnet: MASRAD@UBVMS (or ubvms(a,b,c, or d)) MASDEV1@UBVM
jmb@beach.cis.ufl.edu (John M Boof) (07/10/88)
( Geoffrey has a program as part of a BBS program which opens files with
his username and password through a network connection. His password
is contained in the code, but nobody there has figured out how to find
it yet... )
Hard-coding your password in a program IS highly dangerous, especially
when you are letting many people run the program. A mistake such as
opening the file to read access for these people would leave your
password out 'in the middle of the road', unless you have encoded it
within your code. Even then, the debugger, or other methods, can be
used to find the location of the password when you store it after
decoding it. Besides all that, no file can be completely safe from
access, and this is basically why no security-conscious systems store
passwords in their original form.
It would be much less risky if you tried to hide access that would only
work for that file, rather than trying to hide access to the whole
account by endangering your password. At our system, people usually
resort to trying to hide the file, by removing it and using the fid
number, burrying it in directories, confuse the SHOW DEV/FIL output by
using pointers and removing latest one, or other ideas. I personally
feel that the MAIL facility keeps a nice record format for a BBS system
that can overlay it, using MAIL's privileges to open the files, a
message pre-processor/editor, and a message post-processor (run in time
intervals or done manually by a board operator). Of course, the
'correct?' way would be to get the program installed with privs, only
using them when opening the files to write to, but I am assuming that
this is not one of your alternatives.
...JMBoof
_____________________________________________________________________________
Addresses in order of preference:
ARPA-InterNet: VAX/VMS: boof%oak.decnet@pine.circa.ufl.edu or
boof@pine.circa.ufl.edu
Gould UNIX: jmb@beach.cis.ufl.edu
UUCP: Gould UNIX: ... !uflorida!beach.cis.ufl.edu!jmb
BITNET: VAX/VMS: boof@ufpine
IBM VM/CMS: $$$YEQ#@NERVM
_____________________________________________________________________________