Conference 7.286::digital

    
     EDP, 
    
     you forgot to mention: 
    
     Then my manager comes to my cubicle and asks 'Did you close that
     PTT, QAR, CLD ( etc.. ) yet? 
    
     jc

    so what's your problems...
    
    you have accounts on 20 differnt systems of which you only use 
    3 on a regular bases 
    
    but..
    
    1. you are supposed to access all account at least once per month
    2. all accounts are supposed to have different passwords
    3. passwords are not suppose to be written down anywhere
    
    Please don't get me wrong ....
    
    		I'm trying to be positive here ; )
    
    Brian V
     

    Who said?
    
    >3. passwords are not suppose to be written down anywhere
    
    Does your VISA card expect you to memorize its number?  I write
    all my passwords (8 at last count) on a piece of paper and keep
    in it my wallet right next to my VISA, American Express card,
    and cash.  Thats as secure as it gets!
    
    Heck, given that >90% of all breakins are over phone lines, you can
    write your passwords down and tape them to your monitor.  If I have
    physical access to your machine, I can break in password or not...
    Just don't keep your passwords online!
    
    				-John

    re; everybody.
    
    I work on 4 vax systems.  The passwords expire monthly on 2 of them and
    maybe 3 monthly on the others.  I use month keyed variations of the
    same 15 digit password on each of them until (heaven forbid) there is a
    layoff or other mass exodus.  Then the passwords expire immediately and
    I have to throw in a mid month correction.  These passwords are kept in
    the history file for over a year (I don't know how long) because I
    tried to recyle them over once and the new password was found in the
    history file and I had to use another one.  
    
    My voice mail has a password.  It seems to expire monthly.  It is all
    numerical digits, 8 of them, and I can't seem to remember them at all
    from month to month.
    
    If I dial in from home there is a password.  It is changed arbitrarily,
    at least once a month.  There is a password announcement system that
    requires an all digit password. that expires every month.
    
    The payroll system has a PIN that is different from the one for the
    stock purchase plan, which is different from the one for the SAVE plan,
    which is different from the one for the DCU.  Fortunately, these are
    all distributed quarterly or so by mail to my home.
    
    I feel very secure. (B^}

  Actually, the last noter has a VERY valid point. I'm forever
  in a state of having forgotten at least one password/PIN/etc.
  (And then, even when I get it right, if I type it too fast to
  the ZKO voicemail server, it gets it wrong!)

  I'd happily carry around a little challenge/response token
  or time-based-password-generator so long as that could be my
  "universal passkey to everything", or even "universal passkey
  to everything inside Digital Equipment Corporation" but exclud-
  ing ATMs and the like.
                                   Atlant

    
    	Funny...
    
    	I'm not anywhere near as concerned about the password stuff. That's
    part of everyday life in a digital society.
    
    	What bothers me no end about .0 is the *business practices* that
    show a complete lack of common sense, basic native intelligence,
    focused management oversight, and create very expensive solutions
    to rather simple problems.
    
    	Then again, it's just my opinion, I could be wrong...
    
    
    		the Greyhawk

    The corporate re engineering program will fix all of these problems
    any day now.  ;^]
    
    

>    My voice mail has a password.  It seems to expire monthly.  It is all
>    numerical digits, 8 of them, and I can't seem to remember them at all
>    from month to month.

Since all U.S. telephones have letters on the keys, you don't have to
remember a string of digits.  But I've found the easiest passwords for
voicemail are 10-digit phone numbers.  My voicemail doesn't have a history
file, so I can alternate between two familiar phone numbers.

    
    
    I second mr greyhawk ---
    it is NOT a password issue; certainly the rigmarole that edp was
    subjected had made the task at hand more complicated. The fundamental 
    issue are the business practices and the stovepiping infrastructure.
    
    I could for example compare .0 to how HP processes an incoming
    customer support call from beginning to finish (from having worked
    in the field for HP). Ours is definitely BROKEN. It shouldn't have
    taken edp that long to even explain the situation, let alone resolve
    it!
    
    From what I've heard (not seen) the so-call corp. re-eng. does not
    instill much confidence that things will be improved soon. Perhaps
    someone close to the subject can elaborate objectively in this forum.
    
    

    Hey .0, what are you complaining about.... just kidding ;) ,what you have
describe is something that ails this company everywhere. Maybe it'll be fixed 
someday, who knows. It just adds to the frustration of doing business both 
internally and externally. We talk about how great our "data integration"
capabilities are, but do we demonstrate it internally,..... humm what a concept.

   Hang in there.


   Rick

    Re :.0
    
       <<< Note 4067.0 by RUSURE::EDP "Always mount a scratch monkey." >>>
                         -< How Digital Does Not Work >-

    ...
>    Anyway, I connect to the QAR system again and try my new password.  Iam
>    greeted with:
                                                                         
>	Your password has expired - contact your system manager
                                                                       
>    That's right, my nice, shiny, brand-new password doesn't work.  I've    
>    left more voice mail. 
                                                                        

>				-- edp
>				June 3, 1994
    
    Well Ed, I for one wouldn't want to have someone else (the help desk in
    this case) know my password.  This is just their way of ensuring that
    you will supply a new one when you first log in.    
    
    		Bill
    

    I have a dream....er a vision,,,something anyway.
    
    How about depending on your job classification you are given
    different security ratings. The security rating would then control
    which databeses you have read access to. When you log on you'll be
    logging onto the network and not a particular system, so it doesn't 
    matter where the database or system is. Everyone would have full
    access to their own directory but noone elses. Use mail to send
    all data and text to the appropriate people or databases.
    
    
    	Nay ... too simple it would never work.
    
    
    Brian V
    

I work with EDP.  I understand and sympathize with every point of what he wrote.
The sad part is that it's even worse on August 23, 1995 than it was on June 3,
1994.

I know that Eric has been holding his breath waiting for the situation to
improve.  Eric, the colour doesn't suit you.  Breath damn it.

Grahame

>    Well Ed, I for one wouldn't want to have someone else (the help desk in
>    this case) know my password.  This is just their way of ensuring that
>    you will supply a new one when you first log in.    

Either I'm missing the humour, or else you didn't quite understand.
He didn't get told 'password expired' after logging in -- he
was refused entr because his (new) password was (still) expired.

(EDP is Eric, not Ed, btw)

    Re: .14
    
    Hmm, you're right, from a reread, it wasn't just pre-expired, it was
    gone.
    
    And I know it's Eric, just my fingers didn't earlier }8-)}
    
    Bill

    
    Greyhawk - All...
    
    I am an Escalation Manager for part of the UK and I have various levels
    of escalations to Engineering active at present.  Apart from being the
    focal point for chases by account teams and customers, producing
    reports for the local service centres in the whole of the UK
    ... in the UK the job is in place for several additional pitiful reasons...
    
    	1. The systems used do not work 
    
    I spend part/most of my day copying mails with updates from ECSO (
    European Customer Outage System ) that interfaces with the IPMT (
    Intergrated Problem Management Tool ) system onto NICE ( New Integrated
    Call handling for Europe ) system in order for the suppor engineers to
    get their updates !!!
    
    	2.  Engineering have been TFSO'd ( what ever that means) to the
    point of obliteration.
    
    Another portion of my day is spent chasing the already overworked,
    understaffed Engineering groups for updates as they do not have time to
    update the system, this removes them from actively working problems!
    
    	3. The support centres are losing skilled competitors because of
    the cr*p pay here ( sorry BP it's true, 4 years since I had one and I
    am not alone ).  This is causing the remainder of the resources to
    escalate calls to Engineering where as before we had the calls locally
    to resolve these problems.
    
    	On top of these minor points we have 4 levels of Escalations/CLD's
    (Critical Level Disruptions)
    
     1. 4 hourly update      System Down no workaround possible
    			     No production/business possible
     
     2. 5 w/days between     System crashing causing high level disruption.
     	updates 
    
     3. updates 1 an month   Resolution of issues in next release ( QAR )
    
     5.			     Wish list (QAR)
    
    Upside we have 2 wonderful administrators who have driven the database
    from 500 plus outstanding level 3 & 5's to circa 200.  They constantly
    battle against the odds to deliver service and deliver a quality
    service that Digital should be proud of.  I just wish they had a system
    that worked. 
    
    Think 9 people to work a system thats horribly flawed
    
    
    	Hope this helps 
    
    \_spike_/
    

    
    Spike -
    
    	Know very much of what you speak. If it wasn't for my fellow
    "trench rats" at Digital, I would find it almost impossible to
    sell anything to anybody. It is *us* that actually makes things happen
    here.
    
    	Unfortunately, it means that the others are along for the ride.
    
    	The bright spot, of course, is that *we* all know :-) who *we*
    are...
    
    
    		the Greyhawk

    Re .0 - have you entered a QAR/PTT/IPMT against the system ?
    
    [Couldn't resist.... :-)]

    re .0
    
    The 2 concerns you have (if I am not mistaken):
    1. Your donot like the escalation procedures, there are too many levels
    between customer and engineering. The way I see right now is CUSTOMER
    -- LOCAL OFFICE SUPPORT (OR CSC) -- ENGINEERING SCREENING --
    ENGINNERING (the guy who wrote the codes).
    
    I don't think we can have customers log calls to engineering directly.
    A lot of them are not caused by the codes that they wrote.
    
    The processes that has been setup (CLD, QAR etc) are to make sure the
    legit call will reach engineering and will get addressed.
    
    
    2. Your password expired and user support screwed up.
    I think everyone makes mistakes (I do). Here in Canada we can freely
    chooose our password and I have always been making passwords in all
    systems the same.  

    
    Yaacov
    
    I presented myself with an IPMT for the system but I downgraded it to
    level 5 (wish list ;^) 
    
    
    \_spike_/

    	It seems We are to busy putting out fires insted of fixing the fire 
    hydrant and every now and then a house burns to the ground. When are we
    going to learn to use what we make.

Article 3443 of alt.humor.best-of-usenet:
From: Artur Pioro <[email protected]>
Newsgroups: alt.humor.best-of-usenet
Subject: [comp.security.unix] Advice on password security guidelines
Organization: best of usenet humor
Lines: 57

From: Paul Ashton <[email protected]>
Newsgroups: comp.security.unix
Subject: Advice on password security guidelines

Hi,
my boss has asked me for comments and improvements on his new password
security policy. To me, it seems a bit severe. If anyone can offer any
additional suggestions please do, here goes...

For immediate issue:
Password changing guidelines V2.2b

Due to new security policies, the following guidelines have
been issued to assist in choosing new passwords. Please follow
them closely.

Passwords must conform to at least 21 of the following attributes.

1.  Minimum length 8 characters
2.  Not in any dictionary.
3.  No word or phrase bearing any connection to the holder.
4.  Containing no characters in the ASCII character set.
5.  No characters typeable on a Sun type 5 keyboard
6.  No subset of one character or more must have appeared on
    Usenet news, /dev/mem, rand(3), or the King James bible (version 0.1alpha)
7.  Must be quantum theoretically secure, i.e. must automatically change
    if observed (to protect against net sniffing).
8.  Binary representation must not contain any of the sequences 00 01 10 11,
    commonly known about in hacker circles.
9.  Be provably different from all other passwords on the internet.
10. Not be representable in any human language or written script.
11. Colour passwords must use a minimum 32 bit pallette.
12. Changed prior to every use.
13. Resistant to revelation under threat of physical violence.
14. Contain tissue samples of at least 3 vital organs.
15. Incontravertible by OJ Simpsons lawyers.
16. Undecodable by virtue of application of 0 way hash function.
17. Odourless, silent, invisible, tasteless, weightless, shapeless, lacking
    form and inert.
18. Contain non-linear random S-boxes (without a backdoor).
19. Self-escrowable to enable authorities to capture kiddie-porn people
    and baddies but not the goodies ("but we'll only decode it with a
    court order, honest").
20. Not decryptable by exhaustive application of possible one time pads.

Due to the severity of the restrictions, if the password is entered
incorrectly 3 times at login time, you will be asked if you would like to
pick a new one.

Please add guidelines to the above and adjust the minimum conformation
requirement, if applicable.

--
Moderators accept or reject articles based solely on the criteria posted
in the Frequently Asked Questions. Article content is the responsibility
of the submittor.  Submit articles to [email protected]. To write 
to the moderators, send mail to [email protected]. 

    Re .19:
    
    I don't have any concerns.  I used to, but Digital has so many it has
    burned me out, and I really don't care about them any more.
    
    Digital should have some concerns:
    
    	The escalation procedures are wasteful.
    
    		It takes too long for problems to be elevated.
    
    		The wrong problems are elevated.
    
    		The right information is not sent with the problems.
    
    		An overload of distracting information is sent.
    
    		The field staff has been reduced.
    
    			They no longer have the resources to screen
    			problems sufficiently.
    
    			They have lost the expertise to handle many of
    			the problems they used to.
    
    		Management at all levels, field, engineering, and
    		corporate, places priority on the wrong things:
    
    			Interrupting engineers working on a fix to
    			force them to provide an information-void
    			response to a political problem.
    
    			Focusing on the short-term CLD load instead
    			of the long-term product quality.
    
    	The support systems are wasteful.
    
    		Response time to a problem that prevents an employee
    		from working should not be so long.
    
    		Continually changing organization and support so that
    		an employee doesn't know who is managing what system
    		is a mistake.
    
    		Responding to a break-in with hysterical password
    		procedures that don't fix the actual problem has caused
    		countless hours of wasted time.
    
    		Our management failed to put pressure on the management
    		responsible for the system manager to provide better
    		service.
    
    		System management didn't just make a mistake.  They
    		delayed, passed the buck, violated security procedures,
    		failed to understand the problem properly, failed to
    		set the system up correctly in the first place so that
    		it would warn in advance of password expiration, and
    		THEN failed to fix the problem after it occurred.
    
    I'd be delighted to see any of these changed.  The solutions to most
    would come by changing management.  If management wants Digital to cut
    costs, Digital will cut costs.  If, on the other hand, management wants
    Digital to do a good job, Digital will do a good job.  If the managers
    of the maintenance group want us to spend an hour in a conference call
    whose only purpose is to reassure the customer that their CLD is in
    fact assigned to an engineer, who would be working on it if they
    weren't in a conference call, then engineers will spend hours in such
    conference calls.  If, other the hand, the managers want us to fix
    bugs, then we will fix bugs.
    
    Currently, engineers in our group are measured and ranked on CLD
    closures, even though we were assured we would not be.  There is NO
    system in place that tracks or measures the submission of changes to
    our source pools that correspond to closed CLDs.  The work that gets
    done is the work that management indicates it wants.
        
    
    				-- edp
    
    
Public key fingerprint:  8e ad 63 61 ba 0c 26 86  32 0a 7d 28 db e7 6f 75
To find PGP, read note 2688.4 in Humane::IBMPC_Shareware.

    
    	re: .23
    
    	One sad commentary on a company struggling to regain its place in
    the sun.
    
    
    		the Greyhawk

      As far as I can tell, the complete systems is totally broken. 
      
      1 Customers routinely call with "I submitted this problem to the CSC
      a year ago and haven't heard anything back".
      
      2 CSC says "We passed this to Engineering immediately at that
      time...we haven't heard back"
      
      3 When pointed out to Engineering, they say "What's the IPMT/QAR/GFO
      (go figure what the last stands for :^]) number on that?".  Hell, I
      got no idea and no access to find out!
      
      4 Customer calls us and says "We're throwing your product out for
      your competitor's because your support sucks, at best".
      
      5 We wind up on con call with CSC *and* Engineering trying to salvage
      the account.
      
      Our competitor's guarantee a response to most problems in hours.  We
      guarantee "to escalate" which, as far as I can tell, means we
      escalate another beer to our lips and blow the customer off.
      
      Another thing that chaps my *ss is when a problem has been noted and
      reported in the notesfile for the product for two years and it's
      *still* a problem.  If anyone says "why has this bug (small
      one...product won't install without hacking the kit) been kept
      upwardly compatible over multiple releases?" they're told "this is
      not a formal support channel.   What's the IPMT number?" (go to
      number 3, do *not* pass competitor).
      
      When *I* was the manager of delopment and *any* internal person
      reported a problem to me via e-mail, snail-mail, or verbally I either
      asked them to write it up, show me, or if it was simple, I wrote it
      up and *I* entered it as a problem.  The buck stopped with me and I
      was intent on making sure we had a quality product and happy
      customers, thus keeping my skinny butt employed.
      
      C'mon, without customers we're a non-profit charity without a cause. 
      Like Corson says, we know who makes it work *despite* our procedures
      and a lot of people in the organization apparently intent on
      sidestepping blame or responsibility.
      
      Shouldn't the focus be "whatever it takes" as opposed to "have you
      followed the procedures you don't understand to submit the proper
      paperwork that we ignore into a system to which you have no
      access"?????
      
      BP, if you're reading this...* IT'S BROKEN * !!!!  And our customers
      damn well know it as well as we do.  Makes me sick.
      
      								Tex

It doesn't have to be broken if you (development group) don't want it to be.
At least, we (DEC Fortran) have managed to keep the system working for us and
for our customers.  Yeah, the IPMT case descriptions we get contain only
about 1% useful info, but our organization has people (Mick Konrad, in
particular) responsible for making sure that nothing gets lost.  The
Fortran group has a good reputation for responding to problem reports
quickly.  What's our secret?  Partly it's due to our placing problem
resolution at the highest priority - above new development.  Partly it's
that we work to make sure there are few bugs to begin with, which lowers our
case load and keeps us responsive.  We also encourage the use of low-overhead
(notesfiles) methods of reporting problems and work closely with the support
folks at the CSC to ensure customer satisfaction.

My view on this is that if you want to "fix it", do so from the bottom up.

				Steve

    re: <PTT/IPMT...problem escalation etc..>
    
    I do backup support for CSC in engineering, my solution to PTT/IPMT is
    notesfile. I create a basenote when I receive a problem, usually in
    softcopy, then I post everything as replies to the basenote. For
    updating PTT/IPMT, I simply forward (vmsmail) the reply to PTT's
    vmsmail account, use "update <ipmt no.>" as the Subject: line. 
    
    I point everyone interested in the problem or work on the problem to
    this notesfile, so, everone sees the same thing. The timestamping,
    searching, and mailing capabilities of notesfile make it easy to track
    problems. I started this notesfile almost 3 years ago, when lots of
    people in our group were tfso'd and my manager too, as my personal 
    survival measure. Ironically, I didn't get the go-ahead before that 
    round of tfso. 
    
    In fact, I think notesfile on the Web, like Webnotes, can really
    simplify the support (escalation) process for customer satisfaction. 
    My hope is that our competition doesn't do it before us.
    
    Regards,
    Edwin

On the other hand, there are organizations we work with whose response
to a problem report is "gee, that's definitely a bug.  Please enter a
QAR so I'll be allowed to fix it."

Yep - initiative (like pro-actively trying to fix bugs) tends to be
a casualty of the "everyone's basically a contractor and may be out
the door at any time" mentality (i.e. lack of long-term focus.)
(No, this isn't universally true, but there is a definite tendency
in that direction - particularly for people that weren't hired
as contractors...)  (Short-duration mentality has a lot of drawbacks
when it comes to little things like "accountabilty" as well.)

Personally, I suspect it will be very hard to make significant,
sustained improvement in internal systems until there is a fairly
distinct change in this attitude.  "Going the extra mile" is a two
way street.

    re: .27
    
    fix it from the bottom up...
    
    your right BUT alot of people above you get teed off cause
    your taking away their importance, reason for being, etc.

    .25
    
    please copy into the 'Bob asks the troops for questions for his video'
    note, and change text to capitals.
    
    HP and IBM are all over us in my account. 64 bit, VLM, VLDB, NT blah
    blah, Microsquish alliance blah blah... Open client server blah blah..
    is fine and dandy, but when it breaks...... HP and IBM are better than
    us. Period.
    
    Banks need to be able to rely on their systems (gee!), and the support
    they get and can rely on is *the* most critical factor when buying.
    
    Anyway,.... 64 bit blah blah......
    
    
    AW

>It doesn't have to be broken if you (development group) don't want it to be.
      
      I agree.  I'm no longer in development, though.
      
>...but our organization has people (Mick Konrad, in
>particular) responsible for making sure that nothing gets lost.  The
      
      *EVERY* org should.  I commend yours.
      
>...What's our secret?  Partly it's due to our placing problem
>resolution at the highest priority - above new development.  Partly it's
      
      Bingo!  No since releasing a new one when the old one's broken.  Our
      clients have learned to let new releases mellow, like wine, before
      they upgrade, based on their past experiences.
      
> ...We also encourage the use of low-overhead
>(notesfiles) methods of reporting problems and work closely with the support
>folks at the CSC to ensure customer satisfaction.
      
      We are specifically *discouraged* from using notesfiles and
      constantly reminded "this is not an official support channel".  I've
      actually been told "we didn't fix it because we never heard of it". 
      I then forward that person's responses they entered in notes to them,
      demonstrating they have.  I then get "submit to IPMT".  B*****T!
      
>... to make sure there are few bugs to begin with, which lowers our
      
      Concepts.  The auto companies found this out some years ago.
      
>My view on this is that if you want to "fix it", do so from the bottom up.
      
      Steve, your notes are dead ringer right on.  Unfortunately, I can't
      fix from the bottom up, as I live in a valley and you-know-what rolls
      down hill.  I've bitched up and down the ladder to no avail, so I'm
      clueless as to what to do (except continue bitching).
      
      Today I watched an extremely experienced software developer spend six
      hours attempting to install a small, cheap piece of software.  It's
      still not working.  Our group loses cash every time we "Field QA" a
      new release.  Our customers love being Alpha test sites.
      
      
      Imagine buying a car from Digital:
      
      Customer: "It won't start".
      Us: "Submit an SPR on that"
      
      Customer: "It only turns left"
      Us: "That'll be fixed in the next release"
      
      Customer: "The transmission dropped out"
      Us: "Upgrade"
      
      Customer: "Where do I buy a transmission?"
      Us: "We sold our transmission facility...call Oracle Transmissions".
      
      Customer: "OK, I bought Oracle"
      Us: "That's too bad.  The next version uses Informix Transmissions".
      
      Customer: "Why won't the next version have gauges?"
      Us: "All gauge reading will be through your PC, no more direct
           reading".
      
      Customer: "I don't *have* or *want* a PC!"
      Us: "Tough"
      
      Customer: "But then I can only read my gauges when I'm home!  I need
      		 to read them when I'm driving!"
      Us: "Buy a laptop with a SLIP connection.  No bisynch."
      
      Customer: "OK, OK, I'll upgrade!  When's the next release?"
      Us: "September...but it's not an upgrade version and won't run in
      your country."
      
      Customer: "Why didn't you fix the problems I have instead of creating
      a new version that I can't use anyway?"
      Us: "Had to say we got one out that runs with a Unix engine"
      
      Customer: "You can shove this up...."
      Us: "Sorry.  Too many already there, we're out of room".
      
      							disgusted in Texas

    I don't (and am not eligible to) claim credit for the way our project
    is run - it is based on principles already in place when I started
    working with the "VAX-11 FORTRAN IV-PLUS" team in 1978.  Through all of
    the changes in the methods of reporting problems, we've kept to the
    same philosophy.  Minimize overhead, get the job done, keep the
    customers delighted.  It's a formula which has worked for us for 17
    years.
    
    					Steve

    Thanks, Steve, that was the problem.  Philosophy and principles.  You
    got a DEC order number on those? :^]
    
    								Tex

Sure - QL-100AA-2B. :-)

			Steve

SEGway...

Digital is broke because we do not have and cannot get current demo systems 
out here in the field to put in front of customers. The customers are 
interested and want to see our products. Our competitors have the demo 
equipment readily available. We don't. This needs to be fixed immediately.

Here's hoping,

Jim

    I don't claim that this is a panacea, but for at least a couple of
    years now, DIGITAL has been making Alpha systems (both OpenVMS and
    Digital UNIX) available via the Internet, so that prospects can verify
    the portability of their code to Alpha and so that they can be blown
    away by its performance thereon.  (The prospects are vetted so we can
    be sure that there are none from proscribed countries, etc.)
    
    The practice is being extended, even as we speak, to more and more
    software products.  
    
    This takes nothing away from the need to put the latest hot box in
    front of the eyes & fingers of prospects, but helps in the cases where
    what draws their attention to our hot-boxes could also be software. 
    
    Web browsers are becoming ubiquitous, and we can help them become
    ubiQUOTEous if we let them be used not only to DEMO, but to TAKE ORDERS
    for and to SELL our stuff.  It's happening!
    
    

    re .34 - Thanks Steve, your Fortran IV for the VAX was a major saving
    grace back in the early '80s when I had to get a project out (convert
    apps from DG to DEC in about 3 days).
    
    Alan
    

    http://www.digital.com/info/alpha-demo.html
    
    Try it, you'll like it... :-)