Newbie DEC COBOL Question - Indexed files...

[sampsa]

I've got the following code:

IDENTIFICATION DIVISION.
PROGRAM-ID. AddUsers.
AUTHOR. Sampsa Laine.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT UserFile ASSIGN TO "USERS.DAT"
ACCESS MODE IS RANDOM
ORGANIZATION IS INDEXED
RECORD KEY IS UserId.

DATA DIVISION.
FILE SECTION.
FD UserFile.
01 UserDetails.
02 UserId PIC X(10).
02 Name PIC X(30).
02 Password PIC X(30).
02 Email PIC X(50).
02 URL PIC X(50).
WORKING-STORAGE SECTION.
01 PasswordVerify PIC X(30).

PROCEDURE DIVISION.
Begin.
OPEN OUTPUT UserFile
DISPLAY "Enter User details using template below. Enter no data
to end."

PERFORM GetUserDetails
PERFORM UNTIL UserId = "."
WRITE UserDetails
PERFORM GetUserDetails
END-PERFORM
CLOSE UserFile
STOP RUN.

GetUserDetails.
DISPLAY "Username"
ACCEPT UserId.
DISPLAY "Name"
ACCEPT Name.
MOVE "!!!!!" TO PasswordVerify.
PERFORM GetPassword UNTIL PasswordVerify = Password
DISPLAY "Email"
ACCEPT Email.
DISPLAY "URL"
ACCEPT URL.

DISPLAY "Adding User:"
DISPLAY UserId.

GetPassword.
DISPLAY "Password"
ACCEPT Password
DISPLAY "Verify"
ACCEPT PasswordVerify.


Which compiles (and runs) fine under OpenCOBOL.

However under DEC COBOL (on a VMS 8.3 AXP box) I get the following
error:


$ cobol addusers.cbl

SELECT UserFile ASSIGN TO "UserS.DAT"
...........^
%COBOL-F-WRINOLCLH, INVALID KEY clause or USE procedure required for
WRITE on file
at line number 14 in file SYS$SYSDEVICE:[SAMPSA.CBLBRD]ADDUSERS.CBL;1
%COBOL-F-ENDNOOBJ, SYS$SYSDEVICE:[SAMPSA.CBLBRD]ADDUSERS.CBL;1
completed with 1 diagnostic - object deleted


Sampsa

[Stephen Hoffman]

On 2012-09-11 14:07:54 +0000, sampsa said:

> COBOL-F-WRINOLCLH, INVALID KEY clause or USE procedure required for
> WRITE on file

That you need to add an INVALID KEY clause or a USE procedure to the
WRITE seems pretty clear from that message.

Check the docs:

"In Format 2 [which is what you use for indexed files], there must be
an INVALID KEY phrase if there is no applicable USE AFTER EXCEPTION
procedure for the file." -
<http://www.openvms.compaq.com/doc/73final/6296/6296_profile_036.html>,
etc.


--
Pure Personal Opinion | HoffmanLabs LLC

[VAXman-]

In article <k2nivj$7b3$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>On 2012-09-11 14:07:54 +0000, sampsa said:
>
>> COBOL-F-WRINOLCLH, INVALID KEY clause or USE procedure required for
>> WRITE on file
>
>That you need to add an INVALID KEY clause or a USE procedure to the
>WRITE seems pretty clear from that message.

You mean that error messages on VMS actually tell you something? :)

$ SET MESSAGE SYS$MESSAGE:DECC$MSG.EXE
$ EXIT %x003580CC

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[Stephen Hoffman]

On 2012-09-11 15:18:02 +0000, VAXman- @SendSpamHere.ORG said:

> In article <k2nivj$7b3$1...@dont-email.me>, Stephen Hoffman
> <seao...@hoffmanlabs.invalid> writes:
>> On 2012-09-11 14:07:54 +0000, sampsa said:
>>
>>> COBOL-F-WRINOLCLH, INVALID KEY clause or USE procedure required for
>>> WRITE on file
>>
>> That you need to add an INVALID KEY clause or a USE procedure to the
>> WRITE seems pretty clear from that message.
>
> You mean that error messages on VMS actually tell you something? :)
>
> $ SET MESSAGE SYS$MESSAGE:DECC$MSG.EXE
> $ EXIT %x003580CC

And next you'll tell me that your hovercraft is full of eels.

FWIW... <http://en.wikipedia.org/wiki/Not_a_typewriter>

Free to log a bug with HP, and see if they'll switch it to the more
recent "Inappropriate ioctl for device" description.

Or you could just HTTP 420. Possibly with the results of HTTP 418.

[VAXman-]

In article <k2nmbt$ve9$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>On 2012-09-11 15:18:02 +0000, VAXman- @SendSpamHere.ORG said:
>
>> In article <k2nivj$7b3$1...@dont-email.me>, Stephen Hoffman
>> <seao...@hoffmanlabs.invalid> writes:
>>> On 2012-09-11 14:07:54 +0000, sampsa said:
>>>
>>>> COBOL-F-WRINOLCLH, INVALID KEY clause or USE procedure required for
>>>> WRITE on file
>>>
>>> That you need to add an INVALID KEY clause or a USE procedure to the
>>> WRITE seems pretty clear from that message.
>>
>> You mean that error messages on VMS actually tell you something? :)
>>
>> $ SET MESSAGE SYS$MESSAGE:DECC$MSG.EXE
>> $ EXIT %x003580CC
>
>And next you'll tell me that your hovercraft is full of eels.

My nipples explode with delight! :)

[Hein RMS van den Heuvel]

On Tuesday, September 11, 2012 10:07:54 AM UTC-4, sampsa wrote:
> I've got the following code:
>
>
>
> IDENTIFICATION DIVISION.
>
> PROGRAM-ID. AddUsers.

:

> %COBOL-F-WRINOLCLH, INVALID KEY clause or USE procedure required for WRITE on file

As the others indicate. Read the error message, and act upon it!

Free-advice... worth every penny
- You probably want a USE procedure anyway.
- You'll need to OPEN I-O after a first time
- Consider SCREEN extensions to DISPLAY/ACCEPT such as ERASE and NO ECHO
- COnsider a graceful exit ( ACCEPT ... AT END ... )
See working example below.

IDENTIFICATION DIVISION.
PROGRAM-ID. AddUsers.
AUTHOR. Sampsa Laine.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT UserFile ASSIGN TO "USERS.DAT"

FILE STATUS IS FILE-STATUS

ACCESS MODE IS RANDOM
ORGANIZATION IS INDEXED
RECORD KEY IS UserId.

DATA DIVISION.
FILE SECTION.
FD UserFile.
01 UserDetails.
02 UserId PIC X(10).
02 Name PIC X(30).
02 Password PIC X(30).
02 Email PIC X(50).
02 URL PIC X(50).


WORKING-STORAGE SECTION.
01 PasswordVerify PIC X(30).

01 FILE-STATUS PIC XX.
01 STS PIC 9(9).

PROCEDURE DIVISION.

DECLARATIVES.
ERROR-HANDLER SECTION.
USE AFTER STANDARD EXCEPTION PROCEDURE ON UserFile.
HERE-WE-GO.
MOVE RMS-STS TO STS.
DISPLAY "File status ", FILE-STATUS, " STS=", STS.
END DECLARATIVES.

MAIN SECTION.

Begin.
OPEN I-O UserFile
DISPLAY "Enter User details using template below. Enter no data to end." ERASE SCREEN

PERFORM GetUserDetails
PERFORM UNTIL UserId = "."
WRITE UserDetails
PERFORM GetUserDetails
END-PERFORM
CLOSE UserFile
STOP RUN.

GetUserDetails.

DISPLAY "Username: " WITH NO ADVANCING.
ACCEPT UserId
AT END STOP RUN.
DISPLAY "Name: " WITH NO ADVANCING.

ACCEPT Name.
MOVE "!!!!!" TO PasswordVerify.
PERFORM GetPassword UNTIL PasswordVerify = Password

DISPLAY "Email: " WITH NO ADVANCING
ACCEPT Email.
DISPLAY "URL: " WITH NO ADVANCING
ACCEPT URL.

DISPLAY "Adding User: ", UserId.

GetPassword.
DISPLAY "Password: " WITH NO ADVANCING
ACCEPT Password WITH NO ECHO
DISPLAY "Verify: " WITH NO ADVANCING
ACCEPT PasswordVerify WITH NO ECHO.

[Stephen Hoffman]

On 2012-09-11 14:07:54 +0000, sampsa said:

> 02 Password PIC X(30).

And FWIW, that's potentially a bug, too.

In general, don't store a password. Store a hash where you can; bcrypt
or scrypt for that, and do not use a SHA nor any other fast hash. Or
store a certificate; a private or public key, as appropriate. Use the
system-provided store where that's available (not so easy on VMS, as
AFAIK there's no generic key store in CDSA or elsewhere). Or if you
must store a password (because you're writing a keystore, and need to
retrieve it for some use), then encrypt it, preferably with AES-grade,
and I'd leave rather more than 30 bytes for that, plus (whether it's
hashed or encrypted) a code or some constant for the identity of the
particular algorithm that used for the encryption, etc.

<http://www.analyticalengine.net/2012/06/should-we-really-use-bcryptscrypt/>

[Rob Brown]

On 2012-09-11, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>
> $ SET MESSAGE SYS$MESSAGE:DECC$MSG.EXE
> $ EXIT %x003580CC

Hah! At first glance, I thought it said:

%C-F-SNOTTY,

[Single Stage to Orbit]

Well, if people must use COBOL :-) *nose up in air*
--
Tactical Nuclear Kittens

[FrankS]

On Tuesday, September 11, 2012 10:07:54 AM UTC-4, sampsa wrote:

> I've got the following code: ...

> Which compiles (and runs) fine under OpenCOBOL.

Perhaps OpenCOBOL is only intended for indexed files which allow duplicates on all the indices? Or which never run out of space? Or which don't need to worry about any errors occurring at all?

On the other hand, it's been stated here previously (by a self-proclaimed expert on the subject) that Cobol is used principally as a reporting tool. I don't see any reporting being done in your application, so perhaps you're best served by rewriting it using some scripting language?

:)

[Fritz Wuehler]

Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:

> On 2012-09-11 14:07:54 +0000, sampsa said:
>
> > 02 Password PIC X(30).
>
> And FWIW, that's potentially a bug, too.
>
> In general, don't store a password. Store a hash where you can; bcrypt
> or scrypt for that, and do not use a SHA nor any other fast hash.

Why should you not use SHAx?

> store a certificate; a private or public key, as appropriate.

Storing an unencrypted private key is worse than storing a password.

[Paul Sture]

On Tue, 11 Sep 2012 15:48:14 -0700, FrankS wrote:

>
> On the other hand, it's been stated here previously (by a
> self-proclaimed expert on the subject) that Cobol is used principally as
> a reporting tool. I don't see any reporting being done in your
> application, so perhaps you're best served by rewriting it using some
> scripting language?
>
> :)

Yup. The real reason COBOL was so popular was that data got in there all
by itself.

;-)
--
Paul Sture

[VAXman-]

In article <1347388872.2...@lithium.local.net>, Single Stage to Orbit <alex....@munted.eu> writes:
>On Tue, 2012-09-11 at 17:18 +0000, Rob Brown wrote:

>> On 2012-09-11, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrot=

>e:
>> >
>> > $ SET MESSAGE SYS$MESSAGE:DECC$MSG.EXE
>> > $ EXIT %x003580CC

>>=20

>> Hah! At first glance, I thought it said:

>>=20

>> %C-F-SNOTTY,
>
>Well, if people must use COBOL :-) *nose up in air*

Wouldn't that be %C-F-SNOOTY

[sampsa]

On Sep 11, 7:49 pm, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
wrote:

> On 2012-09-11 14:07:54 +0000, sampsa said:
>
> >    02      Password                PIC X(30).
>
> And FWIW, that's potentially a bug, too.
>
> In general, don't store a password.  Store a hash where you can; bcrypt
> or scrypt for that, and do not use a SHA nor any other fast hash.  Or
> store a certificate; a private or public key, as appropriate.  Use the
>

I'm aware of these issues :)

Once I have the basic system working I will be storing a salted hash
of the password.

Sampsa

[sampsa]

On Sep 11, 7:22 pm, Hein RMS van den Heuvel

<heinvandenheu...@gmail.com> wrote:

> As the others indicate. Read the error message, and act upon it!
>

I did and was baffled, hence this thread...

> Free-advice... worth every penny
> - You probably want a USE procedure anyway.

Done :) I'm a total COBOL noob, had no idea about USE clauses...

> - You'll need to OPEN I-O after a first time

Done.

> - Consider SCREEN extensions to DISPLAY/ACCEPT such as ERASE and NO ECHO

Was just wondering how to do this - thanks for the tip. Modified the
user-facing code with this (the code in question was a basic debug
tool to init a user database, nothing that would see public use).

> - COnsider a graceful exit ( ACCEPT ... AT END ... )

Will do :)

[sampsa]

Whilst we're on the COBOL noob topic, why does this not add strings
together, read from the standard input one at a time:

GetPayload.
MOVE " " TO Payload.
Move " " TO EditLine.
PERFORM UNTIL EditLine = "."
DISPLAY "> " WITH NO ADVANCING
ACCEPT EditLine
STRING Payload DELIMITED BY SIZE
x"0a0d" DELIMITED BY SIZE
EditLine DELIMITED BY SIZE
INTO NewPayload
END-STRING
MOVE NewPayload TO Payload
END-PERFORM.

[Stephen Hoffman]

On 2012-09-12 05:01:51 +0000, Fritz Wuehler said:

> Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
>> On 2012-09-11 14:07:54 +0000, sampsa said:
>>
>>> 02 Password PIC X(30).
>>
>> And FWIW, that's potentially a bug, too.
>>
>> In general, don't store a password. Store a hash where you can; bcrypt
>> or scrypt for that, and do not use a SHA nor any other fast hash.
>
> Why should you not use SHAx?

Because SHA is intentionally very fast and very efficient and with
intentionally low overhead, and can variously be performed with
hardware assists.
You want slow, ugly, and memory-intensive; bcrypt or scrypt.

>
>> store a certificate; a private or public key, as appropriate.
>
> Storing an unencrypted private key is worse than storing a password.

It depends on what the application is doing; I'd rather use certificate
authentication for the client-server connection than a password,
because folks that are giving you passwords will tend to give you
passwords that they're using elsewhere. If you or the user generates a
certificate pair for the user, you know that "password" won't get
reused.

[Hein RMS van den Heuvel]

On Wednesday, September 12, 2012 8:26:39 AM UTC-4, sampsa wrote:
> Whilst we're on the COBOL noob topic, why does this not add strings
>
> together, read from the standard input one at a time:

Hmmm, it is rare to want to stick embedded CR/LF in strings on OpenVMS.
It can be done, and is done by some system tools as well but it is not the normal approach, and not always correct. Notably, if the target is a 'standard' STREAM_LF file, then just an LF as line end should be used, no CR.


Typically I would expect a WRITE to a variable length records file after each accepts and let RMS worry about the right implied line end

Or have an array of lines being prepared and then write those out.

If I would use STRING then I would use a helper variable initialized to CR/LF

But I would probably use "Reference Modification" with an moving cursor/index variable to stick new chunks of string into the right position of the target string.

http://h71000.www7.hp.com/doc/82final/6296/6296pro_044.html#index_x_527


There must be a way to program (callable) TPU to just work on a memory buffer / single file. This is what EDIT/ACL does right?

I have never needed to figure this out, but would start with the callable util manuals:
http://h71000.www7.hp.com/doc/731final/4493/4493pro_contents.html

When I looked there just now i saw EDT$EDIT has a FILEIO argument.
There you can choose to force/ignore file specific option under program control.
Ditto of TPU... TPU$EDIT and TPU$FILEIO
See http://h71000.www7.hp.com/doc/731final/4493/4493pro_011.html#4493_user_rout

hth,
Hein.



http://h71000.www7.hp.com/doc/731final/4493/4493pro_contents.html

[Ken Fairfield]

On Wednesday, September 12, 2012 5:47:47 AM UTC-7, Stephen Hoffman wrote:
> On 2012-09-12 05:01:51 +0000, Fritz Wuehler said:
> > Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> >> On 2012-09-11 14:07:54 +0000, sampsa said:

[...]

> >> In general, don't store a password. Store a hash where you can; bcrypt
> >> or scrypt for that, and do not use a SHA nor any other fast hash.
>
> > Why should you not use SHAx?
>
> Because SHA is intentionally very fast and very efficient and with
> intentionally low overhead, and can variously be performed with
> hardware assists.

Due respect, I think you got the parity of Fritz's question
backwards. He asked why *not* use SHAx. (Since I don't
know, other than the implied "it's easy to hack", I'll bow
out here...)

-Ken

P.S. Google Groups has just gotten much worse, yet again.
In quoting previous responses, it's adding an extra
(quoted) blank line for each actual line of the original.
I've judiciously edited those out of this response,
but a warning to GG users if you don't want to annoy
other readers...

[Stephen Hoffman]

On 2012-09-12 16:12:20 +0000, Ken Fairfield said:

> On Wednesday, September 12, 2012 5:47:47 AM UTC-7, Stephen Hoffman wrote:
>> On 2012-09-12 05:01:51 +0000, Fritz Wuehler said:
>>> Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>>>> On 2012-09-11 14:07:54 +0000, sampsa said:
> [...]
>>>> In general, don't store a password. Store a hash where you can; bcrypt
>>>> or scrypt for that, and do not use a SHA nor any other fast hash.
>>
>>> Why should you not use SHAx?
>>
>> Because SHA is intentionally very fast and very efficient and with
>> intentionally low overhead, and can variously be performed with
>> hardware assists.
>
> Due respect, I think you got the parity of Fritz's question
> backwards. He asked why *not* use SHAx. (Since I don't
> know, other than the implied "it's easy to hack", I'll bow
> out here...)

And I answered that.

Fast is *not* Good. Not here.

The reason you don't want to use a SHA is because it is intentionally a
very fast hash. Because it is low-overhead, efficient, and with a good
distribution of the hash values, etc.

All of these are goodness when you're flinging a gazillion messages
around, and want digest hashes,

But for a password? Passwords are different.

You still want the good distribution of the hashes, but you're not
doing a lot of these password hashes yourself, so a hash that's a
performance or memory hog is no big deal to the system that's
legitimately verifying the passwords. You're only doing one or two of
these bcrypt or scrypt sequences to verify the password under normal
circumstances, after all.

But an attacker will try many, many, such hashes. They're going to try
the top 5000 or 10000 passwords first - it is easy to add one of those
dictionaries to your OpenVMS password dictionary, BTW
<http://labs.hoffmanlabs.com/node/1223> - and then the attacker is
going to consider a brute-force. And a fast hash is one that can be
brute-forced easier. Easier, that is, but not easy.

There are cloud services and hardware assists around to help with
brute-forcing. (There's a PPTP VPN password brute-forcing service that
was recently made available, and apparently works quite nicely, and
very quickly, and for very little cost to the person looking for the
PPTP password. But that's another discussion.)

More details <http://labs.hoffmanlabs.com/node/526>

[Ken Fairfield]

On Wednesday, September 12, 2012 9:45:42 AM UTC-7, Stephen Hoffman wrote:
> On 2012-09-12 16:12:20 +0000, Ken Fairfield said:
> > On Wednesday, September 12, 2012 5:47:47 AM UTC-7, Stephen Hoffman wrote:
>
> >> Because SHA is intentionally very fast and very efficient and with
> >> intentionally low overhead, and can variously be performed with
> >> hardware assists.
>
> > Due respect, I think you got the parity of Fritz's question
> > backwards. He asked why *not* use SHAx. (Since I don't
> > know, other than the implied "it's easy to hack", I'll bow
> > out here...)
>
> And I answered that.

Which I missed because of its subtlety...or my slowness. ;-)

> Fast is *not* Good. Not here.

[...]

> But an attacker will try many, many, such hashes. They're going to try
> the top 5000 or 10000 passwords first - it is easy to add one of those
> dictionaries to your OpenVMS password dictionary, BTW
> <http://labs.hoffmanlabs.com/node/1223> - and then the attacker is
> going to consider a brute-force. And a fast hash is one that can be
> brute-forced easier. Easier, that is, but not easy.

Ah, point taken. I'd missed the logic behind the "You want slow, ugly,
and memory-intensive" in your reply.

-Ken

[sampsa]

Actually on this note: What IS the best way to call SHA1 from a COBOL
program on OpenVMS?

Sampsa

[Stephen Hoffman]

On 2012-09-12 17:11:48 +0000, sampsa said:
>
> Actually on this note: What IS the best way to call SHA1 from a COBOL
> program on OpenVMS?

Best? That depends on details and requirements; on information not yet
in evidence.

Easiest? Probably a call into a C wrapper routine, and use the CDSA
calls or the OpenSSL API from there.

[sampsa]

On Sep 12, 8:26 pm, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
wrote:

> Best?  That depends on details and requirements; on information not yet
> in evidence.
>
> Easiest?  Probably a call into a C wrapper routine, and use the CDSA
> calls or the OpenSSL API from there.

Yeah, am going down the C route, found some example code that
references cobfunc.h in the DEC COBOL documentation.

However, I'm at a loss to find this file?

Sampsa

[Stephen Hoffman]

On 2012-09-12 17:44:43 +0000, sampsa said:

> On Sep 12, 8:26�pm, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
> wrote:
>
>> Best? �That depends on details and requirements; on information not yet
>> in evidence.
>>
>> Easiest? �Probably a call into a C wrapper routine, and use the CDSA
>> calls or the OpenSSL API from there.
>
> Yeah, am going down the C route, found some example code that
> references cobfunc.h in the DEC COBOL documentation.

The example of that I found
<http://h71000.www7.hp.com/doc/82final/6297/6297pro_092.html> was for
calling COBOL code from C code. Which is not what you want. (FWIW:
please post the URL of whatever you're looking at next time; the harder
you make it for folks to help you here, the easier it becomes for those
same folks to say to themselves "sorry, sampsa, you're on your own
here", and you clearly don't want that to happen)

The #include "cobfunc.h" syntax implies the include is local, and not a
C library include. System #include requests get the <> syntax.

The page you're probably reading has the source code to the include
file in "Example 12-9 C Include File cobfunc.h (Alpha, I64)". It's
local code.

> However, I'm at a loss to find this file?

I'd suggest reading the calling standard and the modular procedures
manuals in the OpenVMS documentation set, and not (initially) the COBOL
manual. Once you grok the basics of how this stuff works, then see the
COBOL chapter
<http://h71000.www7.hp.com/doc/82final/6297/6297pro_095.html#com_lang_env_chap>


Reading the low-level stuff also helps you when you go to debug this
stuff, as you can use your new knowledge of the structures and
pointers, and the debugger, to match up arguments - I've had cases
where the easiest way to build an API was to call (for instance) COBOL
to COBOL and - with the debugger - see what COBOL was doing.

In general, calling anything from COBOL involves a whole lot of "glue
code", and it's "glue code" that's been discussed before, as given
~thirty years of COBOL on VMS means ~thirty years of postings from
folks asking "how do I call {whatever} from COBOL on VMS?" questions.
Put another way, use Bing or Google to search for examples of system
service calls, or other such code, and learn how to use COBOL on VMS.
If you can master (for instance) $getjpi[w] or $getsyi[w] or $getdvi[w]
calls, you'll have examples of the major sorts of argument-passing
mechanisms; by value, by reference, by descriptor, and by itemlist.

[Stephen Hoffman]

On 2012-09-12 16:45:34 +0000, Stephen Hoffman said:

>
>
> But an attacker will try many, many, such hashes. They're going to try
> the top 5000 or 10000 passwords first - it is easy to add one of those
> dictionaries to your OpenVMS password dictionary, BTW
> <http://labs.hoffmanlabs.com/node/1223> - and then the attacker is
> going to consider a brute-force. And a fast hash is one that can be
> brute-forced easier. Easier, that is, but not easy.

Here's some data from DEFCON on hash attacks
<http://contest-2012.korelogic.com/stats.html> - bf is bcrypt; blowfish.
Of 5150 bcrypt/blowfish hashes in the contest, the attackers got to 76.
With SHA1 hashes, the attackers successfully got 4111 of the 8544 hashes.

[Paul Sture]

On Wed, 12 Sep 2012 12:45:34 -0400, Stephen Hoffman wrote:

> There are cloud services and hardware assists around to help with
> brute-forcing. (There's a PPTP VPN password brute-forcing service that
> was recently made available, and apparently works quite nicely, and very
> quickly, and for very little cost to the person looking for the PPTP
> password. But that's another discussion.)
>
> More details <http://labs.hoffmanlabs.com/node/526>

I've just come across Project Erebus:

http://ob-security.info/?p=546

If you scroll down to "Benchmarks" you will see this:

"To give you an idea how fast that is, it would take 12hrs to brute force
the whole key space for any upper, lower, special, or digit password at
length 8 for NTLM. The true magic with the updated chipset is the
increase in multi-hash speeds. Now with even 2M hashes I’m seeing speeds
of 20B/sec. No other updates are planned for a now, but should be more
than enough speed for the next year or so."

There are some interesting articles in the "Recent Posts" section of that
page. In "You expect me to remember that? Part 1" for example, the author
addresses keyboard walking, which is the act of creating a password that
is composed of a string of characters that move in a row or pattern on
the keyboard, and observes that this is most prevalent on Active
Directory systems:

http://ob-security.info/?p=475

--
Paul Sture

[Fritz Wuehler]

Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:

> On 2012-09-12 05:01:51 +0000, Fritz Wuehler said:
>
> > Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> >
> >> On 2012-09-11 14:07:54 +0000, sampsa said:
> >>
> >>> 02 Password PIC X(30).
> >>
> >> And FWIW, that's potentially a bug, too.
> >>
> >> In general, don't store a password. Store a hash where you can; bcrypt
> >> or scrypt for that, and do not use a SHA nor any other fast hash.
> >
> > Why should you not use SHAx?
>
> Because SHA is intentionally very fast and very efficient and with
> intentionally low overhead, and can variously be performed with
> hardware assists.

I don't know what bcrypt or scrypt are, but I will take a standardized,
known-good hash that was approved by trials and a panel of real
cryptographers who's reputations and jobs matter, over unknown people's
stuff even when they base it on established crypto and *especially* when
they work for google. It is fairly well known in cryptography that layering
things when those effects are not fully understood (and understanding their
effects is usually very difficult) often leads to weaknesses that weren't
found in the original cipher. And as Bruce Schneier said, "nobody ever got
fired for using the standard". Don't use whatever crap comes with your OS
unless it is a known good implementation of an official, in-service cipher
or hash.

> You want slow, ugly, and memory-intensive; bcrypt or scrypt.

Just because it's slow, ugly, and memory intensive in whatever OS we're
talking about doesn't mean people with no sense of humor haven't already
written much faster implementations and created lookup tables.

If you have a password authentication scheme then hashing with SHAx is safer
and smarter than xcrypt all other things being equal. If your adversary has
the horsepower to crack 160 bit hashes or has precomputed lookup tables for
SHA1 it's Game Over anyway, so you may as well use the standard since it's
fast, cheap, and the standard.

> >
> >> store a certificate; a private or public key, as appropriate.
> >
> > Storing an unencrypted private key is worse than storing a password.
>
> It depends on what the application is doing; I'd rather use certificate
> authentication for the client-server connection than a password,
> because folks that are giving you passwords will tend to give you
> passwords that they're using elsewhere. If you or the user generates a
> certificate pair for the user, you know that "password" won't get
> reused.

Yes, passwords are usually weak and have other issues. Public key stuff is
fine when deployed properly. But see above, storing an unencrypted private
key is worse than storing a password. In a normal pubkey (certificate)
scenario, the private key doesn't go into a database. It stays with the
user, who sends his public key (certificate) to people who want to
authenticate him and they store that on their database.

[Richard Maher]

"sampsa" <sam...@gmail.com> wrote in message
news:55f8d595-fe0c-4272...@v22g2000vbu.googlegroups.com...

On Sep 11, 7:22 pm, Hein RMS van den Heuvel
<heinvandenheu...@gmail.com> wrote:

> As the others indicate. Read the error message, and act upon it!
>

I did and was baffled, hence this thread...

> Free-advice... worth every penny
> - You probably want a USE procedure anyway.

Done :) I'm a total COBOL noob, had no idea about USE clauses...

[They're like a CATCH around a global TRY for the file. (Leaving nested
programs to the side fo a moment)]

> - You'll need to OPEN I-O after a first time

Done.

[Then I recommend "select OPTIONAL UserFile assign to "users.dat"]

> - Consider SCREEN extensions to DISPLAY/ACCEPT such as ERASE and NO ECHO

Cheers Richard Maher

[Stephen Hoffman]

On 2012-09-13 21:00:31 +0000, Fritz Wuehler said:
>
> I don't know what bcrypt or scrypt are, but I will take a standardized,
> known-good hash that was approved by trials and a panel of real
> cryptographers who's reputations and jobs matter, over unknown people's
> stuff even when they base it on established crypto and *especially* when
> they work for google. It is fairly well known in cryptography that layering
> things when those effects are not fully understood (and understanding their
> effects is usually very difficult) often leads to weaknesses that weren't
> found in the original cipher. And as Bruce Schneier said, "nobody ever got
> fired for using the standard". Don't use whatever crap comes with your OS
> unless it is a known good implementation of an official, in-service cipher
> or hash.

You'll be happy to know that bcrypt() is based on repeatedly calling
Bruce Schneier's Blowfish, then.

[Fritz Wuehler]

Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:

> You'll be happy to know that bcrypt() is based on repeatedly calling
> Bruce Schneier's Blowfish, then.

I'd be happier if Schneier himself came out and said bcrypt is better than
SHA1 (or SHA256/386/512) for hashing in the specific application we're
talking about. As I wrote, even using known-good crypto in ways it was never
intended to be used is not safe.

[Stephen Hoffman]

I'd suggest not using a published algorithm (SHA1) for a purpose other
than what it was expressly designed for.

[Hein RMS van den Heuvel]

On Thursday, September 13, 2012 6:42:18 PM UTC-4, Richard Maher wrote:
> "sampsa" <sam...@gmail.com> wrote in message

> <heinvandenheu...@gmail.com> wrote:
:

> > - You'll need to OPEN I-O after a first time
:
> Done.
:
> [Then I recommend "select OPTIONAL UserFile assign to "users.dat"]

Thanks Richard. I never used OPTIONAL. Works like a charm.

Hein.

[Fritz Wuehler]

That's good, but it doesn't go far enough. And it seems to contradict what
you said already.

The discussion was on hashing passwords, wasn't it?

SHAx are general purpose hashes. Hashing passwords and passphrases is
certainly in the top 3 most common uses of SHAx. SHA1 is nearing end of life
because computational power has increased faster than expected. It hasn't
been found prone to collisions as MD5, it's just not strong enough. The rest
of the SHAx family are still in good shape.

[Stephen Hoffman]

Re-read your reply. It can be read as suggesting SHA1 for passwords.

[Fritz Wuehler]

SHA1 is still ok for password hashing as much as any hash with an equivalent
output bit size (160 bits). Straight hashing of weak passwords is broken
with any hash, that problem isn't specific to SHA1.

[Stephen Hoffman]

On 2012-09-16 13:58:58 +0000, Fritz Wuehler said:

>>
>> Re-read your reply. It can be read as suggesting SHA1 for passwords.
>
> SHA1 is still ok for password hashing as much as any hash with an equivalent
> output bit size (160 bits). Straight hashing of weak passwords is broken
> with any hash, that problem isn't specific to SHA1.

We will disagree, there.

If I'm rolling new code, I'd use bcrypt or (better) scrypt.

And in any case, I'd implement a way to roll forward to newer
algorithms/hashes/digests as the passwords are changed; VMS has this,
but failed to allocate additional room in SYSUAF for the hash storage.
OpenLDAP has a "scheme" which identifies the algorithm to be used.
(With OpenVMS, this can also get into the "fun" of "fallback"
implementations, for cluster compatibility and rolling upgrades, too;
various Unix systems have implemented fallbacks and shadow hashes, with
all the problems that can cause.)

As for bcrypt and scrypt, some more links:

The following is five+ years old:
<http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html>


The following is ten+ years old:
<http://static.usenix.org/events/usenix99/provos/provos_html/node1.html>

Here's a Microsoft rep recommending bcrypt:
<http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/42557f71-19d3-4145-93f6-b462c99ff42f>


This is ~two years back:
<http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage>


But to your earlier point about questionable implementations of hashing
algorithms, they're certainly around. HP published a password
implementation for OpenVMS in their April 2012 OpenVMS Technical
Journal V18 that had a "EXOR the 32 bytes result into 8 bytes
hashValue" routine in the details of the source code; the SHA-256 hash
that was calculated (and I didn't verify that the calculation itself
was correct) and was then converted/compressed from thirty-two bytes to
eight bytes.
<http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA4-0527ENW.pdf>

Though using a SHA-family hash is likely better than using Purdy. But
then that eight-byte storage in SYSUAF is too small for most any modern
hash.