Discussion:
Inverting the Purdy polynomial
(too old to reply)
n***@gmail.com
2017-01-28 05:46:19 UTC
Permalink
Hi,
I haven't read this group for over a decade. I recently returned to some code I wrote to try and invert the Purdy polynomial using distinct degree factorization. You essentially try to calculate gcd(purdy(x),x^p-x) where p=2^64-59. Since x^p-x is a polynomial that contains all the linear factors.
It turns out that Pari/gp can just do the job on it's own now with minimal effort:

(18:15) gp > a = x^16777213 - 24 * x^16777153 - 120 * x^3 - 198 * x^2 - 264 * x + 17748126081817865973
%3 = x^16777213 - 24*x^16777153 - 120*x^3 - 198*x^2 - 264*x + 17748126081817865973
(18:15) gp > FpX_roots(a,p)
%4 = [12299211632350700288, 2027082871304097557]~
(21:32) gp >

That 17748126081817865973 is (-307-h) mod p where h is a password hash.

Most passwords seem to have 1-4 solutions. Looks to take about ~3-4 hours. Code is single threaded. So presumably you could get this down to a relatively short time with some work. The algorithms use the Chinese remainder algorithm to split numbers into multiple parts and each part can be handle by a different processor.
I expect that this isn't the default algorithm now.
Neill.
Baldrick
2017-01-28 11:48:05 UTC
Permalink
Post by n***@gmail.com
Hi,
I haven't read this group for over a decade. I recently returned to some code I wrote to try and invert the Purdy polynomial using distinct degree factorization. You essentially try to calculate gcd(purdy(x),x^p-x) where p=2^64-59. Since x^p-x is a polynomial that contains all the linear factors.
(18:15) gp > a = x^16777213 - 24 * x^16777153 - 120 * x^3 - 198 * x^2 - 264 * x + 17748126081817865973
%3 = x^16777213 - 24*x^16777153 - 120*x^3 - 198*x^2 - 264*x + 17748126081817865973
(18:15) gp > FpX_roots(a,p)
%4 = [12299211632350700288, 2027082871304097557]~
(21:32) gp >
That 17748126081817865973 is (-307-h) mod p where h is a password hash.
Most passwords seem to have 1-4 solutions. Looks to take about ~3-4 hours. Code is single threaded. So presumably you could get this down to a relatively short time with some work. The algorithms use the Chinese remainder algorithm to split numbers into multiple parts and each part can be handle by a different processor.
I expect that this isn't the default algorithm now.
Neill.
Hello Neill !! How is life that side of the pond?

You raise some quite serious and interesting points. password algorithms (and those in use by VMS) while incomprehensibly difficult to brute force attack in the days of sub mip processors and tiny memory, become fair game with new techniques and processor capabilities. I don't pretend to fully understand the mathematics. VSI may or may not be willing to disclose any changes or enhancements / plans to the current UAF.

Security, for what VMS has always been revered, is far more than humble passwords and multiple modes of protection, and social engineering probably the single most dangerous vulnerability that we face. Add in the daily technological frustrations and security is swinging wide open like the proverbial barn door.

The i4 processors are very capable so I'd be interested in seeing how quickly it could be done. We assume here you have full access to a valid and live UAF file. Bear in mind most password recommendations for changes are now at around 90 days. That is to reduce the user frustration but imagine the turmoil if password lifetime had to be lower than the average crack time for a password.

The whole industry needs to visit this, not just VMS. Passwords have perhaps had their day so, the question is, just how do you secure access to systems and data? Many systems now use partial password enquiry to asking the username and password in different transactions to avoid interception of user/password combinations.

Further to this, does this also have implications for the current ssh et al methods of exchanging secure data over the web?

<discuss>

PS if you find yourself back in the north west UK give me a shout and we'll have a beer.
n***@gmail.com
2017-01-28 14:28:04 UTC
Permalink
Post by Baldrick
Post by n***@gmail.com
Hi,
I haven't read this group for over a decade. I recently returned to some code I wrote to try and invert the Purdy polynomial using distinct degree factorization. You essentially try to calculate gcd(purdy(x),x^p-x) where p=2^64-59. Since x^p-x is a polynomial that contains all the linear factors.
(18:15) gp > a = x^16777213 - 24 * x^16777153 - 120 * x^3 - 198 * x^2 - 264 * x + 17748126081817865973
%3 = x^16777213 - 24*x^16777153 - 120*x^3 - 198*x^2 - 264*x + 17748126081817865973
(18:15) gp > FpX_roots(a,p)
%4 = [12299211632350700288, 2027082871304097557]~
(21:32) gp >
That 17748126081817865973 is (-307-h) mod p where h is a password hash.
Most passwords seem to have 1-4 solutions. Looks to take about ~3-4 hours. Code is single threaded. So presumably you could get this down to a relatively short time with some work. The algorithms use the Chinese remainder algorithm to split numbers into multiple parts and each part can be handle by a different processor.
I expect that this isn't the default algorithm now.
Neill.
Hello Neill !! How is life that side of the pond?
You raise some quite serious and interesting points. password algorithms (and those in use by VMS) while incomprehensibly difficult to brute force attack in the days of sub mip processors and tiny memory, become fair game with new techniques and processor capabilities. I don't pretend to fully understand the mathematics. VSI may or may not be willing to disclose any changes or enhancements / plans to the current UAF.
Security, for what VMS has always been revered, is far more than humble passwords and multiple modes of protection, and social engineering probably the single most dangerous vulnerability that we face. Add in the daily technological frustrations and security is swinging wide open like the proverbial barn door.
The i4 processors are very capable so I'd be interested in seeing how quickly it could be done. We assume here you have full access to a valid and live UAF file. Bear in mind most password recommendations for changes are now at around 90 days. That is to reduce the user frustration but imagine the turmoil if password lifetime had to be lower than the average crack time for a password.
The whole industry needs to visit this, not just VMS. Passwords have perhaps had their day so, the question is, just how do you secure access to systems and data? Many systems now use partial password enquiry to asking the username and password in different transactions to avoid interception of user/password combinations.
Further to this, does this also have implications for the current ssh et al methods of exchanging secure data over the web?
<discuss>
PS if you find yourself back in the north west UK give me a shout and we'll have a beer.
Hi!,
Life is good. There is some drinkable beer here but the glasses freeze on the outside.
I recently went to the computer museum in Seattle and stood amongst the VAXen. This might be what prompted me too look at this area having not looked at it for maybe 15 years.

I am familiar with algorithm 0, 1 and 2. How does UAI$C_PURDY_S differ? I expect this is algorithm 3 and sounds just like a way of increasing the entropy on input to the polynomial. I don't think increasing the entropy now adds any value.
Kerry Main
2017-01-28 17:40:58 UTC
Permalink
-----Original Message-----
Baldrick via Info-vax
Sent: January 28, 2017 6:48 AM
Subject: Re: [Info-vax] Inverting the Purdy polynomial
Post by n***@gmail.com
Hi,
I haven't read this group for over a decade. I recently returned
to
some code I wrote to try and invert the Purdy polynomial using
distinct
degree factorization. You essentially try to calculate
gcd(purdy(x),x^p-
x) where p=2^64-59. Since x^p-x is a polynomial that contains all
the
linear factors.
Post by n***@gmail.com
It turns out that Pari/gp can just do the job on it's own now with
(18:15) gp > a = x^16777213 - 24 * x^16777153 - 120 * x^3 - 198 *
x^2 -
264 * x + 17748126081817865973
Post by n***@gmail.com
%3 = x^16777213 - 24*x^16777153 - 120*x^3 - 198*x^2 - 264*x +
17748126081817865973
Post by n***@gmail.com
(18:15) gp > FpX_roots(a,p)
%4 = [12299211632350700288, 2027082871304097557]~
(21:32) gp >
That 17748126081817865973 is (-307-h) mod p where h is a password
hash.
Post by n***@gmail.com
Most passwords seem to have 1-4 solutions. Looks to take about ~3-
4 hours. Code is single threaded. So presumably you could get this
down to a relatively short time with some work. The algorithms use
the Chinese remainder algorithm to split numbers into multiple parts
and each part can be handle by a different processor.
Post by n***@gmail.com
I expect that this isn't the default algorithm now.
Neill.
Hello Neill !! How is life that side of the pond?
You raise some quite serious and interesting points. password
algorithms (and those in use by VMS) while incomprehensibly
difficult
to brute force attack in the days of sub mip processors and tiny
memory, become fair game with new techniques and processor
capabilities. I don't pretend to fully understand the mathematics.
VSI
may or may not be willing to disclose any changes or enhancements /
plans to the current UAF.
Security, for what VMS has always been revered, is far more than
humble passwords and multiple modes of protection, and social
engineering probably the single most dangerous vulnerability that we
face. Add in the daily technological frustrations and security is
swinging
wide open like the proverbial barn door.
The i4 processors are very capable so I'd be interested in seeing
how
quickly it could be done. We assume here you have full access to a
valid and live UAF file. Bear in mind most password recommendations
for changes are now at around 90 days. That is to reduce the user
frustration but imagine the turmoil if password lifetime had to be
lower than the average crack time for a password.
The whole industry needs to visit this, not just VMS. Passwords have
perhaps had their day so, the question is, just how do you secure
access to systems and data? Many systems now use partial password
enquiry to asking the username and password in different
transactions
to avoid interception of user/password combinations.
Further to this, does this also have implications for the current
ssh et al
methods of exchanging secure data over the web?
[snip]

Improving server based authentication technology is certainly a
component of the security solution that needs to continue to be
enhanced - on all platforms. Even though brute force attacks typically
assume you have control of the system authentication database (e.g.
SYSUAF) which means the system is already cracked, this is no excuse
for not continuing to enhance the native security of that platform
user database.

Having stated this, security solutions are like a 4 legged stool -
People, Processes, Technology (what most people focus on) and
Financials (what people often forget is not everything is worth the
cost Fort Knox security).

Forget any leg of the stool and the stool will fall over. Remember
that there is truth in the old adage "a chain is only as strong as its
weakest link".

Hence, this is why many companies today are adopting age old
multi-factor solutions that combine and integrate these different legs
of the chair to make a stronger stool.

The more common ones are things like AES level encryption on
servers/client devices combined with double password processes with
the second password being a code sent to your email/phone. Other
solutions include fingerprint readers on phones/laptops, face/hand
scans, eye scans etc. None of these are totally secure, but they do
raise the bar to make it harder to crack.

As technology evolves, one can likely expect other DNA, network
(IPsec?) based solutions to secure not only data at rest (server), but
data in motion (mobile / remote clients) as well.

Re: futures - The discussion on futures will often evolve to the whole
concept of Identity Management (IdM) and Security and Information
Event Management (SIEM): (google these 2 acronyms for extensive
discussions)
Internet Quote "Identity management (ID management) is a broad
administrative area that deals with identifying individuals in a
system (such as a country, a network, or an enterprise) and
controlling their access to resources within that system by
associating user rights and restrictions with the established
identity."

Have not tried either of these, but there are some interesting
commercial IdM products that support OpenVMS today:
http://www.idmworks.com/iam-integration-software/openvms-connector/

http://www.prweb.com/releases/prwebIdentityForge/OpenVMS/prweb9155858.
htm

Personally, I hope OpenVMS's Enterprise Directory (or similar partner
technology) with enhanced LDAP integration is a key part of OpenVMS
future X86-64 platform strategies. As noted above, the security
solutions requirement is not not just simply user authentication, but
also controlling access to server resources and rights in a
distributed model that does not include just clusters.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-01-30 03:04:43 UTC
Permalink
Post by Baldrick
The whole industry needs to visit this, not just VMS. Passwords have
perhaps had their day so, the question is, just how do you secure
access to systems and data? Many systems now use partial password
enquiry to asking the username and password in different transactions
to avoid interception of user/password combinations.
The other standard method is to use a certificate based approach.
Post by Baldrick
Further to this, does this also have implications for the current
ssh et al methods of exchanging secure data over the web?
No. Unlike with current versions of VMS, minimum ssh requirements are
changing as the security environment and hardware changes.

However, VSI do have security enhancements listed for their future
VMS versions and (IIRC) this also includes the UAF password hashing.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2017-01-28 17:17:45 UTC
Permalink
Post by n***@gmail.com
Most passwords seem to have 1-4 solutions. Looks to take about ~3-4
hours. Code is single threaded. So presumably you could get this down
to a relatively short time with some work. The algorithms use the
Chinese remainder algorithm to split numbers into multiple parts and
each part can be handle by a different processor.
I expect that this isn't the default algorithm now.
Ayup.

The OpenVMS password algorithm — currently Purdy_S, which is Purdy with
salt and with the username string folded in — has not tracked with
available computing hardware, nor particularly with the available
attacking software. Purdy far too efficient to run forward with modern
tools; to brute-force it. This in terms of memory usage, as well as
processor efficiency; what a password algorithm should not make even
remotely economic use of. Password hashes are one of the few areas
where performance inefficiency is centrally important to a successful
design. The Purdy algorithm uses far too little virtual memory, and
far too few computes.

The current Purdy variation Purdy_S was first released with the OpenVMS
"Hickory" release; that "Hickory" release was OpenVMS VAX V5.3 from
~1989, IIRC. Details on the algorithm are included in the hpwd
examples below.

The increasing weakness of Purdy has been known for decades, and it's
been application compatibility that's relegated any thoughts of
overhauling this to some future aspirational features list, at best.
How to fix this has been known for many years, too. The available
storage in SYSUAF is eight bytes, which is insufficient for any modern
password hash. Worse still, the hash is openly exposed via API and —
in some configurations — trivially triggered to be transmitted in
cleartext — over the network. There is simply no means to fix this
and to maintain application compatibility; you can't fit a 64-byte or
larger hash into an eight-byte bucket, and there are undocumented and
documented user APIs that fix the size of that eight-byte hash bucket.

Once breaking application compatibility is in play, then replacing
SYSUAF with LDAP and Kerberos or other such implementations — more
modern mechanisms, storage, capabilities — is likely also in play.
Replacing Purdy must allow older hashes to be utilized until all the
passwords have been changed — forced change or otherwise — and the
implementation must work correctly across versions in a mixed-version
cluster. There'll have to be user application code rewritten, too;
code that has assumptions around that eight-byte bucket. Meaning
there's inherently a semi-involved migration required before Purdy and
the rest can be retired and (hopefully eventually) expunged.

There were tools available for brute-forcing OpenVMS passwords back in
the 1980s. The tools that were available back then worked rather too
well for my preferences. That was testing those tools on a MicroVAX
II, too. Found roughly a third of the passwords on some systems back
then, too.

As for newer available brute-forcing tools, have a look at JTR (which
can still brute-force OpenVMS Purdy passwords) or (as an example of
another modern brute-forcing tool, though one that doesn't implement
Purdy) hashcat, for what happens here. JTR and hashcat can try ten
or twenty thousand passwords, then combinations of dictionary words
with permutations for common substitutions, then brute-forcing by
password length. (With modern hashing algorithms, using passwords with
lengths of less than 12 or 13 characters isn't considered particularly
robust, and that's assuming the password isn't subject to the
increasingly-clever optimizations to the brute-forcing tools.)

https://en.wikipedia.org/wiki/John_the_Ripper
https://en.wikipedia.org/wiki/Hashcat

http://cpansearch.perl.org/src/MIKEM/Authen-DecHpwd-1.0/hpwd.c
http://www.digiater.nl/openvms/freeware/v80/hpwd/freeware_readme.txt

http://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/

http://openwall.info/wiki/john/benchmarks

ps: There's a rather-problematic OpenVMS SHA-1 replacement available
for Purdy. SHA-1 is intended to be very efficient as it's a message
digest and not a password hash, which means its very efficient to
calculate which also means it's easier for attackers to brute-force.
The OpenVMS SHA-1 password-hashing implementation also folds the hash
down to fit in that eight-byte bucket, massively increasing the chances
of hash collisions, too.
pps: The astute reader will note fodder for at least two CVEs in this posting.
--
Pure Personal Opinion | HoffmanLabs LLC
n***@gmail.com
2017-01-28 17:38:51 UTC
Permalink
Post by Stephen Hoffman
Post by n***@gmail.com
Most passwords seem to have 1-4 solutions. Looks to take about ~3-4
hours. Code is single threaded. So presumably you could get this down
to a relatively short time with some work. The algorithms use the
Chinese remainder algorithm to split numbers into multiple parts and
each part can be handle by a different processor.
I expect that this isn't the default algorithm now.
Ayup.
The OpenVMS password algorithm — currently Purdy_S, which is Purdy with
salt and with the username string folded in — has not tracked with
available computing hardware, nor particularly with the available
attacking software. Purdy far too efficient to run forward with modern
tools; to brute-force it. This in terms of memory usage, as well as
processor efficiency; what a password algorithm should not make even
remotely economic use of. Password hashes are one of the few areas
where performance inefficiency is centrally important to a successful
design. The Purdy algorithm uses far too little virtual memory, and
far too few computes.
The current Purdy variation Purdy_S was first released with the OpenVMS
"Hickory" release; that "Hickory" release was OpenVMS VAX V5.3 from
~1989, IIRC. Details on the algorithm are included in the hpwd
examples below.
The increasing weakness of Purdy has been known for decades, and it's
been application compatibility that's relegated any thoughts of
overhauling this to some future aspirational features list, at best.
How to fix this has been known for many years, too. The available
storage in SYSUAF is eight bytes, which is insufficient for any modern
password hash. Worse still, the hash is openly exposed via API and —
in some configurations — trivially triggered to be transmitted in
cleartext — over the network. There is simply no means to fix this
and to maintain application compatibility; you can't fit a 64-byte or
larger hash into an eight-byte bucket, and there are undocumented and
documented user APIs that fix the size of that eight-byte hash bucket.
Once breaking application compatibility is in play, then replacing
SYSUAF with LDAP and Kerberos or other such implementations — more
modern mechanisms, storage, capabilities — is likely also in play.
Replacing Purdy must allow older hashes to be utilized until all the
passwords have been changed — forced change or otherwise — and the
implementation must work correctly across versions in a mixed-version
cluster. There'll have to be user application code rewritten, too;
code that has assumptions around that eight-byte bucket. Meaning
there's inherently a semi-involved migration required before Purdy and
the rest can be retired and (hopefully eventually) expunged.
There were tools available for brute-forcing OpenVMS passwords back in
the 1980s. The tools that were available back then worked rather too
well for my preferences. That was testing those tools on a MicroVAX
II, too. Found roughly a third of the passwords on some systems back
then, too.
As for newer available brute-forcing tools, have a look at JTR (which
can still brute-force OpenVMS Purdy passwords) or (as an example of
another modern brute-forcing tool, though one that doesn't implement
Purdy) hashcat, for what happens here. JTR and hashcat can try ten
or twenty thousand passwords, then combinations of dictionary words
with permutations for common substitutions, then brute-forcing by
password length. (With modern hashing algorithms, using passwords with
lengths of less than 12 or 13 characters isn't considered particularly
robust, and that's assuming the password isn't subject to the
increasingly-clever optimizations to the brute-forcing tools.)
https://en.wikipedia.org/wiki/John_the_Ripper
https://en.wikipedia.org/wiki/Hashcat
http://cpansearch.perl.org/src/MIKEM/Authen-DecHpwd-1.0/hpwd.c
http://www.digiater.nl/openvms/freeware/v80/hpwd/freeware_readme.txt
http://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/
http://openwall.info/wiki/john/benchmarks
ps: There's a rather-problematic OpenVMS SHA-1 replacement available
for Purdy. SHA-1 is intended to be very efficient as it's a message
digest and not a password hash, which means its very efficient to
calculate which also means it's easier for attackers to brute-force.
The OpenVMS SHA-1 password-hashing implementation also folds the hash
down to fit in that eight-byte bucket, massively increasing the chances
of hash collisions, too.
pps: The astute reader will note fodder for at least two CVEs in this posting.
There is a bunch of stuff in this post about brute force bashing of VMS passwords. That's not what I am talking about here. I am saying you can actually calculate the inverse of any hash in 3-4 hours. That's with s/w you can download from the math community. You likely need a machine with say 8gb or so of memory. You just need to know how to frame the Purdy polynomial in mathematics (finding the roots of the polynomial in a finite field).
Post by Stephen Hoffman
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2017-01-28 22:20:20 UTC
Permalink
Post by n***@gmail.com
There is a bunch of stuff in this post about brute force bashing of VMS
passwords. That's not what I am talking about here. I am saying you can
actually calculate the inverse of any hash in 3-4 hours. That's with
s/w you can download from the math community. You likely need a machine
with say 8gb or so of memory. You just need to know how to frame the
Purdy polynomial in mathematics (finding the roots of the polynomial in
a finite field).
I know exactly what you are referring to here.

Whether this three or four hours spent factoring might be faster or
slower than one of the available brute-force tools is an open question.
Given computing improvements, I'm not at all sure which way I'd bet
on.

But Purdy was known to be woefully inadequate more than a decade ago,
and was and is and will only be getting more problematic. I've
certainly been grumbling about this particular problem for more years
than I'd care to admit. I've also heard most (all?) the evasions and
the rationales and the defenses for not fixing this.

The VSI folks undoubtedly knows about most or all of these quagmires,
too. There's been some forward progress in some security-related
areas, and more work remains. Unfortunately, updates in some of these
problematic areas — including this case — will be fundamentally
disruptive to application code and compatibility. Once the breakage of
documented APIs is under serious discussion, I'd hope that a path
involving a complete overhaul is seriously considered, too. Though
that increases the scale and scope and cost of the remediation effort.

To misquote Kerry, there's certainly more than enough "stool" lurking
in the OpenVMS security implementation. This is one, among others.
Unfortunately.
--
Pure Personal Opinion | HoffmanLabs LLC
n***@gmail.com
2017-01-29 02:57:20 UTC
Permalink
Post by Stephen Hoffman
Post by n***@gmail.com
There is a bunch of stuff in this post about brute force bashing of VMS
passwords. That's not what I am talking about here. I am saying you can
actually calculate the inverse of any hash in 3-4 hours. That's with
s/w you can download from the math community. You likely need a machine
with say 8gb or so of memory. You just need to know how to frame the
Purdy polynomial in mathematics (finding the roots of the polynomial in
a finite field).
I know exactly what you are referring to here.
Whether this three or four hours spent factoring might be faster or
slower than one of the available brute-force tools is an open question.
Given computing improvements, I'm not at all sure which way I'd bet
on.
But Purdy was known to be woefully inadequate more than a decade ago,
and was and is and will only be getting more problematic. I've
certainly been grumbling about this particular problem for more years
than I'd care to admit. I've also heard most (all?) the evasions and
the rationales and the defenses for not fixing this.
The VSI folks undoubtedly knows about most or all of these quagmires,
too. There's been some forward progress in some security-related
areas, and more work remains. Unfortunately, updates in some of these
problematic areas — including this case — will be fundamentally
disruptive to application code and compatibility. Once the breakage of
documented APIs is under serious discussion, I'd hope that a path
involving a complete overhaul is seriously considered, too. Though
that increases the scale and scope and cost of the remediation effort.
To misquote Kerry, there's certainly more than enough "stool" lurking
in the OpenVMS security implementation. This is one, among others.
Unfortunately.
--
Pure Personal Opinion | HoffmanLabs LLC
I don't think it's comparable. With an optimized Purdy evaluation using what I think is a near optimal polynomial addition chain on x64 I can do about 3M hashs/second (on a single processor). That's passwords I can pick. If I just want random values I can calculate 2^x, 2^{x+1}, 2^{x+2} at about 30M hashs/sec. Even to try and cover all 7 digit passwords would take 10 hours.
I can just spend 3 and realistically if I wrote the code about 30 mins to get any password even if it's 32 characters. I wouldn't be able to do 8 character passwords in that time even if multi-threaded on my 16 way.
Stephen Hoffman
2017-01-30 01:40:19 UTC
Permalink
Post by n***@gmail.com
I don't think it's comparable. With an optimized Purdy evaluation using
what I think is a near optimal polynomial addition chain on x64 I can
do about 3M hashs/second (on a single processor). That's passwords I
can pick. If I just want random values I can calculate 2^x, 2^{x+1},
2^{x+2} at about 30M hashs/sec. Even to try and cover all 7 digit
passwords would take 10 hours.
I can just spend 3 and realistically if I wrote the code about 30 mins
to get any password even if it's 32 characters. I wouldn't be able to
do 8 character passwords in that time even if multi-threaded on my 16
way.
Anything requiring less than a year and probably less than a hundred
years of computing time is probably too insecure, particularly for any
algorithms that can parallelize. As these can.

Brute-force doesn't do a sequential brute-force through the keyspace
until other and faster approaches have been tried, and all of the
better cracking tools use GPUs to accelerate the efforts.

But you'll get no argument here. Purdy is far too weak. It's been
known to be far too weak for more than a decade.

VSI has more than a little work ahead of them to overhaul OpenVMS and
to help train folks toward better security not the least of which is
that internal networks can no longer be assumed trusted, secure.

They're tied up with the port and with making enough revenue to
continue their efforts with OpenVMS, though. Then they'll have to
decide whether they're willing to break documented APIs to remediate
this.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-01-30 02:02:41 UTC
Permalink
Post by Stephen Hoffman
Post by n***@gmail.com
I don't think it's comparable. With an optimized Purdy evaluation
using what I think is a near optimal polynomial addition chain on x64
I can do about 3M hashs/second (on a single processor). That's
passwords I can pick. If I just want random values I can calculate
2^x, 2^{x+1}, 2^{x+2} at about 30M hashs/sec. Even to try and cover
all 7 digit passwords would take 10 hours.
I can just spend 3 and realistically if I wrote the code about 30 mins
to get any password even if it's 32 characters. I wouldn't be able to
do 8 character passwords in that time even if multi-threaded on my 16
way.
Anything requiring less than a year and probably less than a hundred
years of computing time is probably too insecure, particularly for any
algorithms that can parallelize. As these can.
Brute-force doesn't do a sequential brute-force through the keyspace
until other and faster approaches have been tried, and all of the better
cracking tools use GPUs to accelerate the efforts.
But you'll get no argument here. Purdy is far too weak. It's been
known to be far too weak for more than a decade.
VSI has more than a little work ahead of them to overhaul OpenVMS and to
help train folks toward better security not the least of which is that
internal networks can no longer be assumed trusted, secure.
They're tied up with the port and with making enough revenue to continue
their efforts with OpenVMS, though. Then they'll have to decide
whether they're willing to break documented APIs to remediate this.
Well, one could step back a few more paces, and think on whether attempting to
use any password scheme is a reasonable way forward. One of the first questions
to be asked is whether it's a good task for an OS to control access? Just cause
it's always been done that way is not a good reason.

No, I have no suggestions. Not something I think about.

In some situations, perhaps access might be better implemented in the application.

But, if looking at the issue, why not consider all options, whatever they are.

And, if other method(s) are adopted, then just don't worry about the VMS
password. With the option of not allowing it's use.
Stephen Hoffman
2017-01-30 03:17:04 UTC
Permalink
Post by David Froble
Post by Stephen Hoffman
Post by n***@gmail.com
I don't think it's comparable. With an optimized Purdy evaluation using
what I think is a near optimal polynomial addition chain on x64 I can
do about 3M hashs/second (on a single processor). That's passwords I
can pick. If I just want random values I can calculate 2^x, 2^{x+1},
2^{x+2} at about 30M hashs/sec. Even to try and cover all 7 digit
passwords would take 10 hours.
I can just spend 3 and realistically if I wrote the code about 30 mins
to get any password even if it's 32 characters. I wouldn't be able to
do 8 character passwords in that time even if multi-threaded on my 16
way.
Anything requiring less than a year and probably less than a hundred
years of computing time is probably too insecure, particularly for any
algorithms that can parallelize. As these can.
Brute-force doesn't do a sequential brute-force through the keyspace
until other and faster approaches have been tried, and all of the
better cracking tools use GPUs to accelerate the efforts.
But you'll get no argument here. Purdy is far too weak. It's been
known to be far too weak for more than a decade.
VSI has more than a little work ahead of them to overhaul OpenVMS and
to help train folks toward better security not the least of which is
that internal networks can no longer be assumed trusted, secure.
They're tied up with the port and with making enough revenue to
continue their efforts with OpenVMS, though. Then they'll have to
decide whether they're willing to break documented APIs to remediate
this.
Well, one could step back a few more paces, and think on whether
attempting to use any password scheme is a reasonable way forward.
This particular thread is centrally about the lack of modularity within
a central piece of the authentication subsystem; around the password
hash. This is not particularly about passwords. (Though there are
certainly issues with passwords on OpenVMS, and that two-factor
authentication is an add-on and not integrated, etc.)
Post by David Froble
One of the first questions to be asked is whether it's a good task for
an OS to control access? Just cause it's always been done that way is
not a good reason.
Ponder whether pushing (more? all?) authentication into the
applications is better, though?
Post by David Froble
No, I have no suggestions. Not something I think about.
Here are a few that might provide some fodder for thought...
https://www.cs.columbia.edu/~smb/classes/f16/l_secpgm1.pdf
https://d1b10bmlvqabco.cloudfront.net/attach/ip0b3cx2rk253m/hbzpuemmwrz3b0/ivhmlkpy8qcf/07448339.pdf
Post by David Froble
In some situations, perhaps access might be better implemented in the application.
Applications are increasingly dependent on authentication, and
increasingly part of authentication. This is part of why application
sandboxes and other isolation and hardening details are interesting to
application developers, too. This is also why simpler APIs are
valuable here, too. Being able to work with very simple tools can be
useful...

https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA

but some of the requirements are less than simple. For folks that
haven't, go try using TLS and certificates on OpenVMS, implement
certificate pinning and verification, and let us know what you think of
the available tools. Pushing more of this into the applications is
problematic, as compromised privileged application can be very useful
to an attacker, and trouble for the more sensitive code (formerly)
under the control of the application developers.
Post by David Froble
But, if looking at the issue, why not consider all options, whatever they are.
I'm not sure that pushing more of authentication into the app is the
way to go — we're already headed that way with the way TLS and
certificates already work, given that there's no particular API for
pinning or connection management or the rest. (And no, switching to
host-to-host IPsec doesn't address the problems that the applications
I'm dealing with require and encounter, either.)
Post by David Froble
And, if other method(s) are adopted, then just don't worry about the
VMS password. With the option of not allowing it's use.
Again, this thread was not discussing the password, but rather the
password hash. Apps are certainly free to do what they want. Both ssh
and TLS allow core parts of authentication to be moved into the
application, too.
--
Pure Personal Opinion | HoffmanLabs LLC
IanD
2017-02-05 12:38:08 UTC
Permalink
On Monday, January 30, 2017 at 1:02:44 PM UTC+11, David Froble wrote:

<snip>
Post by David Froble
Well, one could step back a few more paces, and think on whether attempting to
use any password scheme is a reasonable way forward. One of the first questions
to be asked is whether it's a good task for an OS to control access? Just cause
it's always been done that way is not a good reason.
+1 as to the reason to challenge what we have always done

I used to think VMS was really secure but of late, I have started looking more into security. After doing some good security courses of late to better my knowledge in this field (Edx / MIT course-wear / Moocs) and I'm of the opinion that VMS is nowhere near as secure as what the general belief out there is of it. I've had my cage rattled about VMS security, and that's a good thing

When you look at how systems become compromised, you can see VMS has some real needs on it's plate around modernising security and it's security management tools (or lack of).

Humans are still the number one break-point in security holes being exploited, the whole VMS security is so dispersed and piecemeal in it's management, that it opens itself up to attack through people mistakes / misconfiguration. This alone is the biggest need for VMS on the security front IMO

Pushing security in a distributed model (letting applications do it) only increases the surface area for an attack. Having it all in one place is bad news if your security comes unraveling though.
The trend seems to be to try and fortify centrally but also have additional external check measures to notify / shutdown / halt the process when something looks amiss
Post by David Froble
No, I have no suggestions. Not something I think about.
In some situations, perhaps access might be better implemented in the application.
Two factor authentication / biometrics / etc are just some areas. Integrated management tools is highly needed to stop silly mistakes being made

VMS doesn't have an audit checker included with it. If we are looking for ways to add value, then this would be a good include for customers. Buy VMS, get a built-in audit checker for free

For an OS as-pounding to be the ants-pants of secure OS's, then a verification tool should be included, not a bolt / add on (I once worked briefly with one of the people who wrote 'Security Toolkit', which they ended up selling to DEC way way back).

There are some simpler things too. Being able to white listing / black list commands and there qualifiers for a process / user would also help with security.
Removing commands from users is not integrated into the UAF and if anything, it should be the reverse anyhow, you start with nothing and authorize commands upwards.
It's way too granular simply removing the verb if you want to limit commands, I would like the ability to in some cases allow the verb but disallow the qualifier(s) or certain qualifiers

Add decent auditing like capturing commands used as well. Auditing is also part of good security. (yes, I know you can get these out of sda but they are not automatically captured and they vanish when the process exits).

You cannot easily or thoroughly put together how someone has walked through your system with the current tools, not without turning on auditing to a level that will impact the machine performance. Good auditing is almost as important as good lock-down

Work pattern matching is another area, sort of akin to banking / credit card companies and how they monitor out of character spending. Google has done some nice work on account monitoring with their location scanning and device monitoring. I know that for VMS that might prove too difficult to get right since we don't have access to the same types of data but work pattern matching might be something to start to gather for analysis later on?
VMS at the moment wouldn't report an anomaly if the same account logged in from two different locations at the same time, for example

Security on VMS certainly needs a huge revamp. It really has sat still for the past decade or so while the world moved on. In some environments that might be ok if a fully closed shop but who knows how long that closed shop will remain closed to a world that wants to integrate
Post by David Froble
But, if looking at the issue, why not consider all options, whatever they are.
And, if other method(s) are adopted, then just don't worry about the VMS
password. With the option of not allowing it's use.
If VMS wants to differentiate itself then it's going to have to offer more than what the others do in ways that add value. Security adds value IMO

Willingness to look at security is a start, rather than just believing VMS is secure and as you have said, also challenging assumptions makes for a good start

x86-VMS is probably around 12 months away :-) so frame-working ideas on how to bolster it' security needs to be happening now, not after it jois the rest of the planet on x86

When VMS appears in the cloud, it's going to expose itself to a whole new audience, some who will want to take an axe to it to see if they can break it

Perhaps it's time for an overall VMS security thread of it's own?
Jan-Erik Soderholm
2017-02-05 13:28:08 UTC
Permalink
Post by IanD
VMS at the moment wouldn't report an anomaly if the same account logged
in from two different locations at the same time, for example...
What *is* a "location"? A/the remote IP address? Or where the
actual desk/chair where a specific user is sitting is located?

In our environment, all logins comes from the same "location" (an
Citrix application server where the terminal emulator is running),
no matter where on the earth that user actually is sitting. The
IP address changes randomly between 2 or 3 servers.
David Froble
2017-02-05 19:08:00 UTC
Permalink
Post by Jan-Erik Soderholm
Post by IanD
VMS at the moment wouldn't report an anomaly if the same account logged
in from two different locations at the same time, for example...
What *is* a "location"? A/the remote IP address? Or where the
actual desk/chair where a specific user is sitting is located?
In our environment, all logins comes from the same "location" (an
Citrix application server where the terminal emulator is running),
no matter where on the earth that user actually is sitting. The
IP address changes randomly between 2 or 3 servers.
Yeah, it's not just terminal sessions that access computers these days.

We got web services (yes Jan-Erik, I know you don't consider them as such) where
customers connect to a socket and send data which can be inventory inquiry,
place order(s), and such. There is no login. Now, customer data must have been
set up before a user can use such services, so that could be considered for
access. Shipping only to the address on file unless special instructions can be
a security measure.

In a mfg environment perhaps equipment makes connections.

Security can be rather tough, when your business wants people to connect to your
computers. (Just not nefarious users)

:-)

This is why I wrote that just one type of access control really isn't all that
helpful.
Jan-Erik Soderholm
2017-02-05 20:12:25 UTC
Permalink
Post by David Froble
Post by Jan-Erik Soderholm
Post by IanD
VMS at the moment wouldn't report an anomaly if the same account logged
in from two different locations at the same time, for example...
What *is* a "location"? A/the remote IP address? Or where the
actual desk/chair where a specific user is sitting is located?
In our environment, all logins comes from the same "location" (an
Citrix application server where the terminal emulator is running),
no matter where on the earth that user actually is sitting. The
IP address changes randomly between 2 or 3 servers.
Yeah, it's not just terminal sessions that access computers these days.
We got web services (yes Jan-Erik, I know you don't consider them as such)...
Yes David, I know *you* think you are running Web Services. I prefer the
general view that is shared by everyone else. That makes things clearer.

https://en.wikipedia.org/wiki/Web_service

Now, it is not uncommon the use false marketing to "sell" something
that isn't realy what it is called... :-)

But you are right that trying to point the security tools against
the old terminal sessions (only) is less and less interesting today.
Post by David Froble
where customers connect to a socket and send data which can be inventory
inquiry, place order(s), and such. There is no login. Now, customer data
must have been set up before a user can use such services, so that could be
considered for access. Shipping only to the address on file unless special
instructions can be a security measure.
In a mfg environment perhaps equipment makes connections.
Security can be rather tough, when your business wants people to connect to
your computers. (Just not nefarious users)
:-)
This is why I wrote that just one type of access control really isn't all
that helpful.
Kerry Main
2017-02-05 14:04:07 UTC
Permalink
-----Original Message-----
IanD via Info-vax
Sent: February 5, 2017 7:38 AM
Subject: Re: [Info-vax] Inverting the Purdy polynomial
On Monday, January 30, 2017 at 1:02:44 PM UTC+11, David Froble
<snip>
Post by David Froble
Well, one could step back a few more paces, and think on whether
attempting to use any password scheme is a reasonable way
forward.
Post by David Froble
One of the first questions to be asked is whether it's a good task
for
Post by David Froble
an OS to control access? Just cause it's always been done that
way is
not a good reason.
+1 as to the reason to challenge what we have always done
I used to think VMS was really secure but of late, I have started
looking
more into security. After doing some good security courses of late
to
better my knowledge in this field (Edx / MIT course-wear / Moocs)
and
I'm of the opinion that VMS is nowhere near as secure as what the
general belief out there is of it. I've had my cage rattled about
VMS
security, and that's a good thing
When you look at how systems become compromised, you can see
VMS has some real needs on it's plate around modernising security
and it's security management tools (or lack of).
Humans are still the number one break-point in security holes being
exploited, the whole VMS security is so dispersed and piecemeal in
it's
management, that it opens itself up to attack through people
mistakes
/ misconfiguration. This alone is the biggest need for VMS on the
security front IMO
Pushing security in a distributed model (letting applications do it)
only
increases the surface area for an attack. Having it all in one place
is bad
news if your security comes unraveling though.
The trend seems to be to try and fortify centrally but also have
additional external check measures to notify / shutdown / halt the
process when something looks amiss
Post by David Froble
No, I have no suggestions. Not something I think about.
In some situations, perhaps access might be better implemented in
the application.
Two factor authentication / biometrics / etc are just some areas.
Integrated management tools is highly needed to stop silly mistakes
being made
VMS doesn't have an audit checker included with it. If we are
looking
for ways to add value, then this would be a good include for
customers. Buy VMS, get a built-in audit checker for free
For an OS as-pounding to be the ants-pants of secure OS's, then a
verification tool should be included, not a bolt / add on (I once
worked
briefly with one of the people who wrote 'Security Toolkit', which
they
ended up selling to DEC way way back).
There are some simpler things too. Being able to white listing /
black
list commands and there qualifiers for a process / user would also
help
with security.
Removing commands from users is not integrated into the UAF and if
anything, it should be the reverse anyhow, you start with nothing
and
authorize commands upwards.
It's way too granular simply removing the verb if you want to limit
commands, I would like the ability to in some cases allow the verb
but
disallow the qualifier(s) or certain qualifiers
Add decent auditing like capturing commands used as well. Auditing
is
also part of good security. (yes, I know you can get these out of
sda
but they are not automatically captured and they vanish when the
process exits).
You cannot easily or thoroughly put together how someone has
walked through your system with the current tools, not without
turning on auditing to a level that will impact the machine
performance. Good auditing is almost as important as good lock-down
Work pattern matching is another area, sort of akin to banking /
credit
card companies and how they monitor out of character spending.
Google has done some nice work on account monitoring with their
location scanning and device monitoring. I know that for VMS that
might prove too difficult to get right since we don't have access to
the
same types of data but work pattern matching might be something to
start to gather for analysis later on?
VMS at the moment wouldn't report an anomaly if the same account
logged in from two different locations at the same time, for example
Security on VMS certainly needs a huge revamp. It really has sat
still for
the past decade or so while the world moved on. In some
environments that might be ok if a fully closed shop but who knows
how long that closed shop will remain closed to a world that wants
to
integrate
Post by David Froble
But, if looking at the issue, why not consider all options,
whatever
they are.
Post by David Froble
And, if other method(s) are adopted, then just don't worry about
the
Post by David Froble
VMS password. With the option of not allowing it's use.
If VMS wants to differentiate itself then it's going to have to
offer
more than what the others do in ways that add value. Security adds
value IMO
Willingness to look at security is a start, rather than just
believing VMS
is secure and as you have said, also challenging assumptions makes
for
a good start
x86-VMS is probably around 12 months away :-) so frame-working
ideas on how to bolster it' security needs to be happening now, not
after it jois the rest of the planet on x86
When VMS appears in the cloud, it's going to expose itself to a
whole
new audience, some who will want to take an axe to it to see if they
can break it
Perhaps it's time for an overall VMS security thread of it's own?
While I agree with you that there are a number of areas that OpenVMS
needs to improve on (Security is definitely one area), one also has to
ask "at what point does the OS have to provide everything when there
are commercial products available that address some of the missing
functionality?"

Case in point - PointSecure offers a few products that can
significantly improve the security and auditing of OpenVMS.

System Detective:
http://pointsecure.com/products/system-detective/

Point Audit:
http://pointsecure.com/products/pointaudit/

Patch Analyzer:
http://pointsecure.com/products/patchanalyzer/

Security Snapshot:
http://pointsecure.com/products/snapshot/

As example - you can define all sorts of security event rules with
Security Detective from PointSecure.

Custom written rules can be triggered by:
- Login (process discovery)
- File access (via the XQP)
- Image activation (via the image activator)
- Image exit (via exit handler)
- Idle time (via one minute timer)

Rule initiated primary actions:
- Idle rules checking on or off
- Delete process
- Force image exit
- Force security event
- Log session temporarily or permanently
- Log session input only
- Stop temporary session logging
- Lock user's keyboard (user unlock)
- Manager lock keyboard
- Exclude rules until end of block
- Ignore this process

Rule initiated secondary actions:
- Send a message to operator(s)
- Notify (send a message to) the user
- Execute a DCL command in a batch job

You can also setup System Detective so that a show system does not
display that it is installed.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
j***@yahoo.co.uk
2017-02-05 16:14:28 UTC
Permalink
Post by IanD
<snip>
Post by David Froble
Well, one could step back a few more paces, and think on whether attempting to
use any password scheme is a reasonable way forward. One of the first questions
to be asked is whether it's a good task for an OS to control access? Just cause
it's always been done that way is not a good reason.
+1 as to the reason to challenge what we have always done
I used to think VMS was really secure but of late, I have started looking more into security. After doing some good security courses of late to better my knowledge in this field (Edx / MIT course-wear / Moocs) and I'm of the opinion that VMS is nowhere near as secure as what the general belief out there is of it. I've had my cage rattled about VMS security, and that's a good thing
When you look at how systems become compromised, you can see VMS has some real needs on it's plate around modernising security and it's security management tools (or lack of).
Humans are still the number one break-point in security holes being exploited, the whole VMS security is so dispersed and piecemeal in it's management, that it opens itself up to attack through people mistakes / misconfiguration. This alone is the biggest need for VMS on the security front IMO
Pushing security in a distributed model (letting applications do it) only increases the surface area for an attack. Having it all in one place is bad news if your security comes unraveling though.
The trend seems to be to try and fortify centrally but also have additional external check measures to notify / shutdown / halt the process when something looks amiss
Post by David Froble
No, I have no suggestions. Not something I think about.
In some situations, perhaps access might be better implemented in the application.
Two factor authentication / biometrics / etc are just some areas. Integrated management tools is highly needed to stop silly mistakes being made
VMS doesn't have an audit checker included with it. If we are looking for ways to add value, then this would be a good include for customers. Buy VMS, get a built-in audit checker for free
For an OS as-pounding to be the ants-pants of secure OS's, then a verification tool should be included, not a bolt / add on (I once worked briefly with one of the people who wrote 'Security Toolkit', which they ended up selling to DEC way way back).
There are some simpler things too. Being able to white listing / black list commands and there qualifiers for a process / user would also help with security.
Removing commands from users is not integrated into the UAF and if anything, it should be the reverse anyhow, you start with nothing and authorize commands upwards.
It's way too granular simply removing the verb if you want to limit commands, I would like the ability to in some cases allow the verb but disallow the qualifier(s) or certain qualifiers
Add decent auditing like capturing commands used as well. Auditing is also part of good security. (yes, I know you can get these out of sda but they are not automatically captured and they vanish when the process exits).
You cannot easily or thoroughly put together how someone has walked through your system with the current tools, not without turning on auditing to a level that will impact the machine performance. Good auditing is almost as important as good lock-down
Work pattern matching is another area, sort of akin to banking / credit card companies and how they monitor out of character spending. Google has done some nice work on account monitoring with their location scanning and device monitoring. I know that for VMS that might prove too difficult to get right since we don't have access to the same types of data but work pattern matching might be something to start to gather for analysis later on?
VMS at the moment wouldn't report an anomaly if the same account logged in from two different locations at the same time, for example
Security on VMS certainly needs a huge revamp. It really has sat still for the past decade or so while the world moved on. In some environments that might be ok if a fully closed shop but who knows how long that closed shop will remain closed to a world that wants to integrate
Post by David Froble
But, if looking at the issue, why not consider all options, whatever they are.
And, if other method(s) are adopted, then just don't worry about the VMS
password. With the option of not allowing it's use.
If VMS wants to differentiate itself then it's going to have to offer more than what the others do in ways that add value. Security adds value IMO
Willingness to look at security is a start, rather than just believing VMS is secure and as you have said, also challenging assumptions makes for a good start
x86-VMS is probably around 12 months away :-) so frame-working ideas on how to bolster it' security needs to be happening now, not after it jois the rest of the planet on x86
When VMS appears in the cloud, it's going to expose itself to a whole new audience, some who will want to take an axe to it to see if they can break it
Perhaps it's time for an overall VMS security thread of it's own?
Have you been around long enough to remember
DECinspect (a security auditing tool from the
early 1990s)? It was in the docset, and in
Europe at least it was probably in the DECdirect
software catalogue for a while.

DECinspect begat POLYcenter Security something or
other, which in due course was sold off like all
the other ahead-of-its time software, because
the future of DEC/CPQ was in selling IA64-based
hardware (according to a certain Bob Palmer).
Lots of saleable systems management stuff just
faded away once it had left DEC (not that it was
particularly visible anyway).

The PointSecure family (as mentioned by Kerry)
seems to share some of the DECinspect concepts
and capabilities. There are presentations around
(even from as recently as 2016).

Seek and ye may find.

DEC/CPQ/HP management may not have understood the
value of things like integrated multi-system
security capabilities but there were architects
and engineers that did. Maybe they're still
available ? Maybe the hooks they designed in are
still there and working, and would be a good
place to start from for the future security work
which VSIVMS will undoubtedly required?

VMS has had auditing built in to the OS
architecture for decades but doesn't have an
auditing GUI built in, and is missing lots of
other handy stuff too. On the other hand...

If an increased attack surface is a bad thing,
then in that respect VMS already has a massive
advantage over Windows - VMS is radically
smaller, and historically has things like a
sensible approach to shared libraries and
multiversioning, one part of which is "don't
***unnecessarily*** break compatibility"
(sometimes it's inevitable).

Compare with Windows. Strategy, interfaces,
and libraries change every year or two, as
does the approach to multi-version
compatibility (side by side was Win7, Win10
has something new and incompatible, right?).

Windows doesn't have a meaningful auditing
or event log architecture in the OS, but has
lots of shiny add-ons, in addition to the
pointless built-in event logging system.

Meanwhile, many in the world of Window boxes
still think "application whitelisting" is
something more than security theatre. It's
going to be an uphill battle defeating that
level of understanding. Where to even start?


For those unfamiliar with Stuxnet, the new
documentary movie Zero Days tells the story
in an approachable way. It was recently on
BBC TV in the StoryVille series [1] and is
available on iPlayer for another ten days:
http://www.bbc.co.uk/programmes/b08bcc18
Available soon in cinemas etc (?).

Where was Windows security there?

More to a lot of this than meets the eye -
but being well informed is a good start :)

Have a lot of fun.

[1] I mention Storyville simply because on
my TV's version of iPlayer, if you search
for Storyville you find Zero Days, but a
search for Zero Days finds no results even
though it's in the program title. Oh well.
Stephen Hoffman
2017-02-06 23:30:19 UTC
Permalink
Post by IanD
<snip>
Post by David Froble
Well, one could step back a few more paces, and think on whether
attempting to use any password scheme is a reasonable way forward. One
of the first questions to be asked is whether it's a good task for an
OS to control access? Just cause it's always been done that way is not
a good reason.
We're going to be using passwords for the foreseeable future.
Increasingly with 2FA. Because there isn't an alternative.
Post by IanD
+1 as to the reason to challenge what we have always done
Always challenge assumptions. Sometimes they're still necessary and
appropriate. Sometimes not.

Doing the same thing usually gives you the same outcome. That might
not be the best outcome, particularly in changing conditions.
Post by IanD
I used to think VMS was really secure but of late, I have started
looking more into security. After doing some good security courses of
late to better my knowledge in this field (Edx / MIT course-wear /
Moocs) and I'm of the opinion that VMS is nowhere near as secure as
what the general belief out there is of it. I've had my cage rattled
about VMS security, and that's a good thing
Get yourself onto the security flaw feeds, and start getting a feel for
where the problems are, and how fast the flaws become known, too.
Post by IanD
When you look at how systems become compromised, you can see VMS has
some real needs on it's plate around modernising security and it's
security management tools (or lack of).
Start looking at how some of the newer systems are being managed, too.
The ones I work with are vastly easier to deal with than OpenVMS, and
do more. That's starting with a base of knowledge around how OpenVMS
works, too.
Post by IanD
Humans are still the number one break-point in security holes being
exploited, the whole VMS security is so dispersed and piecemeal in it's
management, that it opens itself up to attack through people mistakes /
misconfiguration. This alone is the biggest need for VMS on the
security front IMO
This extends well beyond security. We're not going to get more staff,
more experienced staff, better staff. Not easily, nor cheaply. Most
likely, we're going to get what we have, or less. As end-users, we
can't use systems that require more effort. As product producers,
shifting management and development costs onto the end-users is
increasingly intractable, too. Go try setting up clustering some
time. It's an utter train-wreck. Works great once it's all
configured, but getting to the working configuration is just insanely
manual. Sure, if the end-users are willing to wade through the manuals
— and know where the ~24 shared files are documented — clustering is a
fine solution.

But once you have that clustering configured and working, you still
have security problems and double-secret "best practices" — rather
than, you know, just installing and working and being simple and
secure. Just working. Like we'd all prefer. Like OpenVMS used to
do and to be, back when it was a good and cheap and simple alternative
to then-current servers. What many of us remember. Instead, we're
now dealing with configuring and managing and securing management VLANs
and protecting the clustering traffic against rogue printers and
writing our own DCL procedures to correctly secure our keys and encrypt
our backups and the rest of the "you didn't _know_ that?" steps
increasingly involved. This because we're dealing with badly
down-revision iLOs and down-revision SSL and SSH and the rest.

Just getting an OpenVMS system patched to current is a slog, compared
with other systems. What's that tell you?

As a developer, go try to write a secure network-accessed distributed
app on OpenVMS, using cluster features. Go ahead. Try it. I'll
wait. Get 2FA and maybe Kerberos working while you're at it, given
you're going to have to go write your own 2FA or acquire and integrate
some third-party support for that, and sort out how to deal with
delegation.

This whole area needs to be massively simpler to install, configure,
manage, troubleshoot, develop for....
Post by IanD
Pushing security in a distributed model (letting applications do it)
only increases the surface area for an attack. Having it all in one
place is bad news if your security comes unraveling though.The trend
seems to be to try and fortify centrally but also have additional
external check measures to notify / shutdown / halt the process when
something looks amiss
Massively.
Post by IanD
Post by David Froble
No, I have no suggestions. Not something I think about.
In some situations, perhaps access might be better implemented in the application.
Two factor authentication / biometrics / etc are just some areas.
Integrated management tools is highly needed to stop silly mistakes
being made
2FA is about the best that's available, preferably not via SMS.
Post by IanD
VMS doesn't have an audit checker included with it. If we are looking
for ways to add value, then this would be a good include for customers.
Buy VMS, get a built-in audit checker for free
For an OS as-pounding to be the ants-pants of secure OS's, then a
verification tool should be included, not a bolt / add on (I once
worked briefly with one of the people who wrote 'Security Toolkit',
which they ended up selling to DEC way way back).
There are some simpler things too. Being able to white listing / black
list commands and there qualifiers for a process / user would also help
with security.
Command auditing doesn't do what you want. It's useful as part of
DFIR, but it's not going to be a reliable access control mechanism.

If you're not going to actually solve the problem with whatever you're
doing, then aren't you really just adding more complexity?
Post by IanD
Removing commands from users is not integrated into the UAF
See previous comment.
Post by IanD
and if anything, it should be the reverse anyhow, you start with
nothing and authorize commands upwards.It's way too granular simply
removing the verb if you want to limit commands, I would like the
ability to in some cases allow the verb but disallow the qualifier(s)
or certain qualifiers
If you want to disable access, you need to work within the
security-relevant accessors and objects involved, and commands are not
those. That is, ACLs and ownership and identifiers and related, and
files and queues and sections and such. Within what the OpenVMS access
control system is designed to mediate. There's a big diagram in the
OpenVMS security manual. That diagram and the whole OpenVMS model
really needs to be extended out to deal with LDAP and Kerberos, but it
covers local authentication well.
Post by IanD
Add decent auditing like capturing commands used as well. Auditing is
also part of good security. (yes, I know you can get these out of sda
but they are not automatically captured and they vanish when the
process exits).
Logging everything is great if you want to drown yourself in data, and
quite possibly meaningless data.
Post by IanD
You cannot easily or thoroughly put together how someone has walked
through your system with the current tools, not without turning on
auditing to a level that will impact the machine performance. Good
auditing is almost as important as good lock-down
Across all systems, too. Integrated with app failures, too, as
crashes can be an indication of probes. But most folks are not
working with systems that are directly accessed via the command line
for the end-users, with general DCL access increasingly reserved for
developers, administrators, and other trusted folks. And only when
they really need that, if we look forward.
Post by IanD
Work pattern matching is another area, sort of akin to banking / credit
card companies and how they monitor out of character spending. Google
has done some nice work on account monitoring with their location
scanning and device monitoring. I know that for VMS that might prove
too difficult to get right since we don't have access to the same types
of data but work pattern matching might be something to start to gather
for analysis later on?VMS at the moment wouldn't report an anomaly if
the same account logged in from two different locations at the same
time, for example
Heuristics. Distributed logging and correlation. Etc. But that's
so far out ahead of what OpenVMS currently provides, that'll most
likely only ever be available a third-party add-on for the foreseeable
future.
Post by IanD
Security on VMS certainly needs a huge revamp. It really has sat still
for the past decade or so while the world moved on. In some
environments that might be ok if a fully closed shop but who knows how
long that closed shop will remain closed to a world that wants to
integrate
Existing and isolated and task-dedicated servers and shops are a nice
base where they even still exist, but they're not the future.
Post by IanD
Post by David Froble
But, if looking at the issue, why not consider all options, whatever they are.
And, if other method(s) are adopted, then just don't worry about the
VMS password. With the option of not allowing it's use.
Again, it ain't the password that was being discussed in this thread,
it's the password hash.
Post by IanD
If VMS wants to differentiate itself then it's going to have to offer
more than what the others do in ways that add value. Security adds
value IMO
Security isn't a huge selling point for most folks, unfortunately.
It's a nice-to-have, but just as soon as it gets in the way, or gets
too expensive, security tends to either get ignored or otherwise worked
around, or somebody has to mandate the security requirements (e.g. PCI,
financial regulations, etc) and that approach is also certainly
problematic. In many ways, security is similar to insurance. You
want to have enough. Too little or too much is a problem. Each site
invariably ends up making those calculations, too. It'd be really
nice to differentiate on easy-to-use and fully-integrated or other
such, but I'm working with other platforms that already have that.
Post by IanD
Willingness to look at security is a start, rather than just believing
VMS is secure and as you have said, also challenging assumptions makes
for a good start
That's not going to happen easily. I'm sure the folks at VSI are
learning a whole lot about this, and rate of change across the whole
area is not slowing down.
Post by IanD
x86-VMS is probably around 12 months away :-) so frame-working ideas on
how to bolster it' security needs to be happening now, not after it
jois the rest of the planet on x86
I'd be surprised if there was particular new work going on here. Some
incremental work such as 2L1, certainly. Integrating fixes for the
password hash or adopting and integrating LDAP and Kerberos will be
more effort and more disruptive, and there's a constituency that
strongly prefers compatibility over change. That work also pushes out
the port, and you can be certain VSI wants to get the x86-64 port out
the door just as soon as it's stable and supportable and salable.
Post by IanD
When VMS appears in the cloud, it's going to expose itself to a whole
new audience, some who will want to take an axe to it to see if they
can break it
Just as soon as you connect to the network, and have some reason —
credit card data, sensitive information, vulnerabilities that can be
leveraged into a DDoS against others, whatever — you're targeted. No
cloud needed.
Post by IanD
Perhaps it's time for an overall VMS security thread of it's own?
I've been discussing this topic for years here in comp.os.vms, and have
delivered multiple presentations on the topic at boot camp. Others
have posted and presented, too. But then some of us actually have to
use OpenVMS security, and get it connected to other servers. That's
increasingly an adventure, particularly for anyone that's used other
platforms and then has to try the same on OpenVMS. The "cool and
unhackable" mantra quickly runs afoul of the "why can't modern SSH
connect to my OpenVMS system?" or "why aren't my network connections
encrypted?" or "why am I being told to fall back to TCP 80 and disable
TCP 443 when the rest of the world is moving to 443?", and goes rapidly
downhill from there.

VSI is working diligently on the port and on updating the capabilities,
and they've already done some work on security and networking. This
however is a massive effort. VSI needs to get to stable positive and
preferably increasing revenues first, and then they can start looking
at addressing security or whatever other areas will bring them the
revenues they need to build their staff and build their installed base
and — once they get far enough along — start adding wholly new partners
and new apps.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-02-12 02:50:51 UTC
Permalink
Post by IanD
Perhaps it's time for an overall VMS security thread of it's own?
I believe both Stephen and I have said a few things on this subject
over the last year or two. :-)

If you want a really simple example of something which VMS lacks
(at least as far as VSI is concerned) then you might want to ask
VSI why they _still_ don't have a secure security bug public
reporting mechanism in place.

This is an absolutely standard thing to be present on an OS vendor's
website these days and it's omission doesn't exactly give you
confidence that VSI are on the ball when it comes to the security
culture as seen in today's world.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
z***@gmail.com
2017-11-28 07:58:50 UTC
Permalink
Post by n***@gmail.com
(18:15) gp > FpX_roots(a,p)
%4 = [12299211632350700288, 2027082871304097557]~
My pari-gp (v2.7.5) does not know function FpX_roots(a,p)
Any clues?
Thanks.

Loading...