Slashdot Mirror

You are making a common mistake. The kilogram is the standard weight, but naming nomenclature is based on the gram:

Names and symbols for decimal multiples and submultiples of the unit of mass are formed by attaching prefix names to the unit name "gram," and prefix symbols to the unit symbol "g."

from https://www.nist.gov/pml/weigh...

.Net is only behind C and Java. VB.Net and C# individually are behind C++ in addition to the first two. Yet not mentioned in the post. Why?

You need to understand their method of quantifying first. You need to follow the 2nd link in the summary and look for another link to get to OWASP A9 site. On the site, you need to scroll down a bit to find National Vulnerability Database which gives you all the list of vulnerabilities found for any languages. From there, you simply collect the data and categorize them into each language/technology/framework. That's it! Though, I believe that TFA doesn't really look into each vulnerability but rather count the number...

Nobody turns off websites during a shutdown, you fucking liar.

https://www.nist.gov/

Since December 31, 2017, contract requirements do require showing engagement in best practices of network and data security.

https://www.nist.gov/mep/cyber...

There are two scoring methods used by CVE, CVSS 2.0 and CVSS 3.0. You may find this link to the vulnerability enlightening: https://nvd.nist.gov/vuln/deta...
Still, your point is well taken. This is not the first.

The underlying paper is here:
https://www.secorvo.de/publika...

The CVE is here:
https://nvd.nist.gov/vuln/deta...

Here's the CVE with a link to the details https://nvd.nist.gov/vuln/deta...

Beat me to it:

CVE-2016-5195
CVE-2013-2094

Seriously, this has nothing to do with "Linux is more secure than Windows". If you're running this old ass code in the wild, you sort of deserve it at this point.

Rust you say... https://github.com/jwilm/alacr... https://nvd.nist.gov/vuln/deta... off by ones, and where were the unit tests? progress in coding... as for how one regards all the "have you heard the good word of Rust" evangelism and that cod of conduct, well now that's opinion territory

It is my understanding that it is, indeed possible. For example, consider the DoD Orange Book security classifications for Operating Systems.

See here.

In fairness, the DoD Evaluation Criteria go back to 1983 - I am sure that there are more recent versions that could be referenced.

But rather than focus on the Orange Book specifically, consider instead as an example of a principle. That principle was a determined effort to design a set of operating criteria and behaviours that would result in a secure operating system. So yes, I think it can be done.

Yes, I know that traditionally kilo was assumed to be 1024 when dealing with bits/bytes. Yes, this new version does sound a bit ridiculous. But it is the standard now: "Because the SI prefixes strictly represent powers of 10, they should not be used to represent powers of 2. Thus, one kilobit, or 1 kbit, is 1000 bit and not 2^10 bit = 1024 bit. To alleviate this ambiguity, prefixes for binary multiples have been adopted by the International Electrotechnical Commission (IEC) for use in information technology.".

Actually, I only knew about this kilo/kibi weirdness a few years back when doing some research to develop a library dealing with units of measurement. Curiously, I am currently studying a reasonably deep mixture of computer/telecommunication engineering and most of the references there are Kbit/Kbyte. I understand that this is an informal convention to indicate that they mean the 1024 versions (because 1000/kilo should be lower k).

Yes, I know that traditionally kilo was assumed to be 1024 when dealing with bits/bytes. Yes, this new version does sound a bit ridiculous. But it is the standard now: "Because the SI prefixes strictly represent powers of 10, they should not be used to represent powers of 2. Thus, one kilobit, or 1 kbit, is 1000 bit and not 2^10 bit = 1024 bit. To alleviate this ambiguity, prefixes for binary multiples have been adopted by the International Electrotechnical Commission (IEC) for use in information technology.".

Actually, I only knew about this kilo/kibi weirdness a few years back when doing some research to develop a library dealing with units of measurement. Curiously, I am currently studying a reasonably deep mixture of computer/telecommunication engineering and most of the references there are Kbit/Kbyte. I understand that this is an informal convention to indicate that they mean the 1024 versions (because 1000/kilo should be lower k).

The USA is technically metric. Just about all of the US units a defined as some number of metric units. Example.1 inch is defined as 25.4 mm and has been that way since 1959. https://www.nist.gov/pml/weigh... https://www.nist.gov/physical-...

The USA is technically metric. Just about all of the US units a defined as some number of metric units. Example.1 inch is defined as 25.4 mm and has been that way since 1959. https://www.nist.gov/pml/weigh... https://www.nist.gov/physical-...

There are classes of secrets for which "decades" is a reasonable threat model. Communications can be an example. If I'm recording everything you send NOW, are you sure there's nothing in there that won't be a problem for you in 20, 30 years? Consider some person is going to be present of the US in 20, 30 years.

If you're on the Nation State side of this, recording everything you can and decrypting later is a totally legitimate strategy, as SOMEONE will be the leader of $otherCountry then, and having all their emails ever is going to be valuable, even if only for putting together a psychological profile.

So people who work for companies whose job it is to protect your information SHOULD be looking ahead. I know I'm writing policy documents with words like "Quantium Horizon" in them and looking at up and coming post-quantum algorithms. You're welcome :).

Min

PS: https://csrc.nist.gov/projects...

Haha, well PHP CVEs certainly don't impact my sleep schedule. For example, I've never needed to use com_print_typeinfo, and it's not used in the framework that our application uses, and even if it did it probably wouldn't take user-supplied data as an argument, and even if it did our servers do not run Windows. So I don't need to worry about arbitrary code execution using this.

This is what I'm talking about. Yes, that vulnerability exists. But the vulnerability is not "run PHP and you're vulnerable to this." It is

1. Run PHP earlier than 5.4.3
2. Do it on Windows
3. Use com_print_typeinfo
4. Allow user-supplied data as a parameter

It's just not as simple as "if you're running PHP, you're vulnerable to this." Slashdot is full of stories of various MacOS vulnerabilities or whatever which require physical access or some other constraint that attackers normally cannot take advantage of. This is the same thing. Yes, there are vulnerabilities, but the requirements for those vulnerabilities mean that the vast, vast majority of servers and sites are not actually vulnerable to them.

Now, SOMEONE was vulnerable to that, and they became aware of that fact apparently in May 2012. But a successful exploit requires several things to happen. In this case, it is enough if someone runs PHP 5.4 on Windows and allows unauthorized people to upload and run PHP files. That's not a vulnerability though, that's stupidity. Sadly, there is no patch for stupidity.

According to Wikipedia (https://en.wikipedia.org/wiki/Abramowitz_and_Stegun) "Because the Handbook is the work of U.S. federal government employees acting in their official capacity, it is not protected by copyright in the United States." At the end of the article are links to places you can download it. The successor to A&S, the NIST Handbook of Mathematical Functions (which has an online companion, https://dlmf.nist.gov/) omits the tables (referring to A&S or to other papers.)

Although I omitted WWVB in the summary I submitted, there's no information that it wouldn't be included in the general statement:

...including the shutdown of NIST radio stations in Colorado and Hawaii.

Because WWVB is in Colorado [ https://www.nist.gov/pml/time-... ].

Most of the devices mentioned use WWVB which I understand will continue to operate.

WWVB is one of the, "NIST radio stations in Colorado and Hawaii." [ https://www.nist.gov/pml/time-... ]

What references can you cite that say it won't be shut down?

Or, Megane, you could read not only the source article, but follow the other links and discover that WWVB is also one of the, "NIST radio stations in Colorado and Hawaii."
[ https://www.nist.gov/pml/time-... ]

Someone didn't RTFOA. And I neglected to include WWVB in the summary. But the source document [ https://www.nist.gov/director/... ] indicates that all radio broadcast operations in Colorado and Hawaii are on the chopping block.

According to this page, WWVB is also in Colorado:
[ https://www.nist.gov/pml/time-... ]

NIST radio station WWVB is located on the same site as NIST HF radio station WWV near Fort Collins, Colorado.

Someone didn't RTFOA. And I neglected to include WWVB in the summary. But the source document [ https://www.nist.gov/director/... ] indicates that all radio broadcast operations in Colorado and Hawaii are on the chopping block.

According to this page, WWVB is also in Colorado:
[ https://www.nist.gov/pml/time-... ]

NIST radio station WWVB is located on the same site as NIST HF radio station WWV near Fort Collins, Colorado.

I couldn't disagree more. From the NIST budget request summary:

This budget request is consistent with the administration’s priorities to redirect domestic discretionary resources to rebuild the military and make critical investments in the nation’s security, and keep the nation on a responsible fiscal path.

Funding for discretionary programs is being reduced to allocate more funding for the military and "national security", which I suspect refers largely to the President's idea of border security. That makes it fair game to discuss defense and border security when commenting on the proposed shutdown of the WWV stations.

While we can debate a reasonable level of defense spending, let's use NATO's 2% of GDP standard. US defense spending is around 3.6% of GDP, and President Trump's requested FY 2019 budget increases DOD spending by 13% over 2017 levels. Proposed military spending is outpacing GDP growth. At the same time, President Trump is requesting a long list of reforms and spending cuts.

In fairness, it's necessary to understand the context of proposed cuts. For example, NOAA is proposing to cut VORTEX-SE, which is a project that studies tornadoes in the Southeast US. Taken out of context, one might think NOAA isn't prioritizing the improvement of tornado warnings. In reality, VORTEX-SE was supposed to collect high quality in-situ data for a few events each spring over the span of 2-3 years and fund a number of related research projects, many of which use the data collected during the field campaign. Most field campaigns such as the original VORTEX (1994-5) and VORTEX2 (2009-10) have been just as short in duration. VORTEX-SE has run longer and wasn't cut in FY 2018 because Congress never passed the relevant appropriations bill and kept funding basically at FY 2017 levels in the continuing resolutions. Context is important to understand proposed cuts, such as if a program has already achieved its goals.

I looked for justification for the proposed cutting of WWV stations and I couldn't find anything that explains why these stations are being targeted for shutdown. Absent any good context for why funding cuts for these stations is requested, it's fair to assume it would be a casualty of the President's overall budget goals. For that reason, it's certainly fair game to criticize our excessive defense spending.

The budget proposal says:

...including the shutdown of NIST radio stations in Colorado and Hawaii

So perhaps all broadcast operations in Colorado will be shut down.
According to this page, WWVB is also in Colorado:
[ https://www.nist.gov/pml/time-... ]

NIST radio station WWVB is located on the same site as NIST HF radio station WWV near Fort Collins, Colorado.

So it looks to me like WWVB could also be on the chopping block.

If asked to change the infrastructure for every time there is a bug. The fix will take years to get out, and a new infrastructure will introduce new flaws untested.

Thanks for the bullshit false dichotomy. The guy has found 30 bugs over the last couple years. While it'd be unreasonable to expect that every form of bug that he's discovered to be fixed, it's clear that Apple follows more closely the

You have software that took months/years to plan and develop.
A problem is found.
You need to Fix it Fast, before it goes out to the wild.
It will need to be tested to make sure it doesn't break compatibility or break something else.

approach but without actually learning any lessons for the "plan and develop" step for the future. That's the complaint. Just a few of the exploits he's found old and new seem to suffer from the same sort of incompetence that should have been addressed a long time ago.

I say, look at Microsoft. By no means was or is Microsoft a bastion of bug-free software, but they did in the mid/late-00s actually strive to actually take security seriously and work to minimize bugs and discover what practices were creating them. There's already whole classes of static code analysis tools that likely would have found at least have the bugs Mr Beer found. They didn't/don't need to wait until 2018 to finally do something especially when it was released at precisely the time Microsoft, a clear industry leader, was finally getting its act together and pushing towards the reasonable position that connected devices should put security as a high priority.

Perhaps if Apple was focused less on UI "design" and more on architectural "design" we wouldn't be in this mess? Certainly, they've had plenty of time to shift their focus. Perhaps now with some urging from outsiders, just like how Microsoft had to change maybe Apple will too.

If asked to change the infrastructure for every time there is a bug. The fix will take years to get out, and a new infrastructure will introduce new flaws untested.

Thanks for the bullshit false dichotomy. The guy has found 30 bugs over the last couple years. While it'd be unreasonable to expect that every form of bug that he's discovered to be fixed, it's clear that Apple follows more closely the

You have software that took months/years to plan and develop.
A problem is found.
You need to Fix it Fast, before it goes out to the wild.
It will need to be tested to make sure it doesn't break compatibility or break something else.

approach but without actually learning any lessons for the "plan and develop" step for the future. That's the complaint. Just a few of the exploits he's found old and new seem to suffer from the same sort of incompetence that should have been addressed a long time ago.

I say, look at Microsoft. By no means was or is Microsoft a bastion of bug-free software, but they did in the mid/late-00s actually strive to actually take security seriously and work to minimize bugs and discover what practices were creating them. There's already whole classes of static code analysis tools that likely would have found at least have the bugs Mr Beer found. They didn't/don't need to wait until 2018 to finally do something especially when it was released at precisely the time Microsoft, a clear industry leader, was finally getting its act together and pushing towards the reasonable position that connected devices should put security as a high priority.

Perhaps if Apple was focused less on UI "design" and more on architectural "design" we wouldn't be in this mess? Certainly, they've had plenty of time to shift their focus. Perhaps now with some urging from outsiders, just like how Microsoft had to change maybe Apple will too.

In all seriousness, though, why should we trust Yubikey, Google, or any security key that doesn't publicly post its design and firmware for independent external audit? FST-01 or bust.

The USB flavor of the Yubi key is FIPS-140 certified, so it has been independently audited, albeit not in a public manner.

Yes, and that was done in 2002 with the Help America Vote Act.

https://www.nist.gov/itl/votin...

Yes, this is 2018 and we're still seeing hardcoded passwords in Cisco products. How could anyone be surprised by this?

• CVE-2004-0391 Cisco Wireless LAN Solution Engine (WLSE) 2.0 through 2.5 and Hosting Solution Engine (HSE) 1.7 through 1.7.3 have a hardcoded username and password
• CVE-2006-3286 Cisco Wireless Control System (WCS) for Linux and Windows before 3.2(63) stores a hard-coded username and password in plaintext within unspecified files
• CVE-2007-2032 Cisco Wireless Control System (WCS) before 4.0.96.0 has a hard-coded FTP username and password
• CVE-2012-4088 Cisco Unified Computing System (UCS) has a hardcoded password
• CVE-2015-4196 Cisco Unified Communications Domain Manager (CDM) 8.x has a hardcoded password
• CVE-2015-6316 Cisco Mobility Services Engine (MSE) through 8.0.120.7 allows logins with hardcoded password
• CVE-2016-1394 Cisco Firepower System Software 6.0.0 through 6.1.0 has a hardcoded account
• CVE-2017-6626 Cisco Finesse Notification Service for Cisco Unified Contact Center Enterprise (UCCE) 11.5(1) and 11.6(1) have a hardcoded password

These are just the first page of results for hardcoded passwords relating to Cisco software and appliances [CVE Cisco hardcoded password site:nvd.nist.gov] - according to Google there are over 300 of them. You'd think Cisco would have been burned enough on this already but I guess some companies never learn.

Stay tuned for more exciting hardcoded password shenanigans from Cisco.

Yes, this is 2018 and we're still seeing hardcoded passwords in Cisco products. How could anyone be surprised by this?

• CVE-2004-0391 Cisco Wireless LAN Solution Engine (WLSE) 2.0 through 2.5 and Hosting Solution Engine (HSE) 1.7 through 1.7.3 have a hardcoded username and password
• CVE-2006-3286 Cisco Wireless Control System (WCS) for Linux and Windows before 3.2(63) stores a hard-coded username and password in plaintext within unspecified files
• CVE-2007-2032 Cisco Wireless Control System (WCS) before 4.0.96.0 has a hard-coded FTP username and password
• CVE-2012-4088 Cisco Unified Computing System (UCS) has a hardcoded password
• CVE-2015-4196 Cisco Unified Communications Domain Manager (CDM) 8.x has a hardcoded password
• CVE-2015-6316 Cisco Mobility Services Engine (MSE) through 8.0.120.7 allows logins with hardcoded password
• CVE-2016-1394 Cisco Firepower System Software 6.0.0 through 6.1.0 has a hardcoded account
• CVE-2017-6626 Cisco Finesse Notification Service for Cisco Unified Contact Center Enterprise (UCCE) 11.5(1) and 11.6(1) have a hardcoded password

These are just the first page of results for hardcoded passwords relating to Cisco software and appliances [CVE Cisco hardcoded password site:nvd.nist.gov] - according to Google there are over 300 of them. You'd think Cisco would have been burned enough on this already but I guess some companies never learn.

Stay tuned for more exciting hardcoded password shenanigans from Cisco.

Yes, this is 2018 and we're still seeing hardcoded passwords in Cisco products. How could anyone be surprised by this?

• CVE-2004-0391 Cisco Wireless LAN Solution Engine (WLSE) 2.0 through 2.5 and Hosting Solution Engine (HSE) 1.7 through 1.7.3 have a hardcoded username and password
• CVE-2006-3286 Cisco Wireless Control System (WCS) for Linux and Windows before 3.2(63) stores a hard-coded username and password in plaintext within unspecified files
• CVE-2007-2032 Cisco Wireless Control System (WCS) before 4.0.96.0 has a hard-coded FTP username and password
• CVE-2012-4088 Cisco Unified Computing System (UCS) has a hardcoded password
• CVE-2015-4196 Cisco Unified Communications Domain Manager (CDM) 8.x has a hardcoded password
• CVE-2015-6316 Cisco Mobility Services Engine (MSE) through 8.0.120.7 allows logins with hardcoded password
• CVE-2016-1394 Cisco Firepower System Software 6.0.0 through 6.1.0 has a hardcoded account
• CVE-2017-6626 Cisco Finesse Notification Service for Cisco Unified Contact Center Enterprise (UCCE) 11.5(1) and 11.6(1) have a hardcoded password

These are just the first page of results for hardcoded passwords relating to Cisco software and appliances [CVE Cisco hardcoded password site:nvd.nist.gov] - according to Google there are over 300 of them. You'd think Cisco would have been burned enough on this already but I guess some companies never learn.

Stay tuned for more exciting hardcoded password shenanigans from Cisco.

Yes, this is 2018 and we're still seeing hardcoded passwords in Cisco products. How could anyone be surprised by this?

• CVE-2004-0391 Cisco Wireless LAN Solution Engine (WLSE) 2.0 through 2.5 and Hosting Solution Engine (HSE) 1.7 through 1.7.3 have a hardcoded username and password
• CVE-2006-3286 Cisco Wireless Control System (WCS) for Linux and Windows before 3.2(63) stores a hard-coded username and password in plaintext within unspecified files
• CVE-2007-2032 Cisco Wireless Control System (WCS) before 4.0.96.0 has a hard-coded FTP username and password
• CVE-2012-4088 Cisco Unified Computing System (UCS) has a hardcoded password
• CVE-2015-4196 Cisco Unified Communications Domain Manager (CDM) 8.x has a hardcoded password
• CVE-2015-6316 Cisco Mobility Services Engine (MSE) through 8.0.120.7 allows logins with hardcoded password
• CVE-2016-1394 Cisco Firepower System Software 6.0.0 through 6.1.0 has a hardcoded account
• CVE-2017-6626 Cisco Finesse Notification Service for Cisco Unified Contact Center Enterprise (UCCE) 11.5(1) and 11.6(1) have a hardcoded password

These are just the first page of results for hardcoded passwords relating to Cisco software and appliances [CVE Cisco hardcoded password site:nvd.nist.gov] - according to Google there are over 300 of them. You'd think Cisco would have been burned enough on this already but I guess some companies never learn.

Stay tuned for more exciting hardcoded password shenanigans from Cisco.

Yes, this is 2018 and we're still seeing hardcoded passwords in Cisco products. How could anyone be surprised by this?

• CVE-2004-0391 Cisco Wireless LAN Solution Engine (WLSE) 2.0 through 2.5 and Hosting Solution Engine (HSE) 1.7 through 1.7.3 have a hardcoded username and password
• CVE-2006-3286 Cisco Wireless Control System (WCS) for Linux and Windows before 3.2(63) stores a hard-coded username and password in plaintext within unspecified files
• CVE-2007-2032 Cisco Wireless Control System (WCS) before 4.0.96.0 has a hard-coded FTP username and password
• CVE-2012-4088 Cisco Unified Computing System (UCS) has a hardcoded password
• CVE-2015-4196 Cisco Unified Communications Domain Manager (CDM) 8.x has a hardcoded password
• CVE-2015-6316 Cisco Mobility Services Engine (MSE) through 8.0.120.7 allows logins with hardcoded password
• CVE-2016-1394 Cisco Firepower System Software 6.0.0 through 6.1.0 has a hardcoded account
• CVE-2017-6626 Cisco Finesse Notification Service for Cisco Unified Contact Center Enterprise (UCCE) 11.5(1) and 11.6(1) have a hardcoded password

These are just the first page of results for hardcoded passwords relating to Cisco software and appliances [CVE Cisco hardcoded password site:nvd.nist.gov] - according to Google there are over 300 of them. You'd think Cisco would have been burned enough on this already but I guess some companies never learn.

Stay tuned for more exciting hardcoded password shenanigans from Cisco.

Yes, this is 2018 and we're still seeing hardcoded passwords in Cisco products. How could anyone be surprised by this?

• CVE-2004-0391 Cisco Wireless LAN Solution Engine (WLSE) 2.0 through 2.5 and Hosting Solution Engine (HSE) 1.7 through 1.7.3 have a hardcoded username and password
• CVE-2006-3286 Cisco Wireless Control System (WCS) for Linux and Windows before 3.2(63) stores a hard-coded username and password in plaintext within unspecified files
• CVE-2007-2032 Cisco Wireless Control System (WCS) before 4.0.96.0 has a hard-coded FTP username and password
• CVE-2012-4088 Cisco Unified Computing System (UCS) has a hardcoded password
• CVE-2015-4196 Cisco Unified Communications Domain Manager (CDM) 8.x has a hardcoded password
• CVE-2015-6316 Cisco Mobility Services Engine (MSE) through 8.0.120.7 allows logins with hardcoded password
• CVE-2016-1394 Cisco Firepower System Software 6.0.0 through 6.1.0 has a hardcoded account
• CVE-2017-6626 Cisco Finesse Notification Service for Cisco Unified Contact Center Enterprise (UCCE) 11.5(1) and 11.6(1) have a hardcoded password

These are just the first page of results for hardcoded passwords relating to Cisco software and appliances [CVE Cisco hardcoded password site:nvd.nist.gov] - according to Google there are over 300 of them. You'd think Cisco would have been burned enough on this already but I guess some companies never learn.

Stay tuned for more exciting hardcoded password shenanigans from Cisco.

Yes, this is 2018 and we're still seeing hardcoded passwords in Cisco products. How could anyone be surprised by this?

• CVE-2004-0391 Cisco Wireless LAN Solution Engine (WLSE) 2.0 through 2.5 and Hosting Solution Engine (HSE) 1.7 through 1.7.3 have a hardcoded username and password
• CVE-2006-3286 Cisco Wireless Control System (WCS) for Linux and Windows before 3.2(63) stores a hard-coded username and password in plaintext within unspecified files
• CVE-2007-2032 Cisco Wireless Control System (WCS) before 4.0.96.0 has a hard-coded FTP username and password
• CVE-2012-4088 Cisco Unified Computing System (UCS) has a hardcoded password
• CVE-2015-4196 Cisco Unified Communications Domain Manager (CDM) 8.x has a hardcoded password
• CVE-2015-6316 Cisco Mobility Services Engine (MSE) through 8.0.120.7 allows logins with hardcoded password
• CVE-2016-1394 Cisco Firepower System Software 6.0.0 through 6.1.0 has a hardcoded account
• CVE-2017-6626 Cisco Finesse Notification Service for Cisco Unified Contact Center Enterprise (UCCE) 11.5(1) and 11.6(1) have a hardcoded password

These are just the first page of results for hardcoded passwords relating to Cisco software and appliances [CVE Cisco hardcoded password site:nvd.nist.gov] - according to Google there are over 300 of them. You'd think Cisco would have been burned enough on this already but I guess some companies never learn.

Stay tuned for more exciting hardcoded password shenanigans from Cisco.

Yes, this is 2018 and we're still seeing hardcoded passwords in Cisco products. How could anyone be surprised by this?

• CVE-2004-0391 Cisco Wireless LAN Solution Engine (WLSE) 2.0 through 2.5 and Hosting Solution Engine (HSE) 1.7 through 1.7.3 have a hardcoded username and password
• CVE-2006-3286 Cisco Wireless Control System (WCS) for Linux and Windows before 3.2(63) stores a hard-coded username and password in plaintext within unspecified files
• CVE-2007-2032 Cisco Wireless Control System (WCS) before 4.0.96.0 has a hard-coded FTP username and password
• CVE-2012-4088 Cisco Unified Computing System (UCS) has a hardcoded password
• CVE-2015-4196 Cisco Unified Communications Domain Manager (CDM) 8.x has a hardcoded password
• CVE-2015-6316 Cisco Mobility Services Engine (MSE) through 8.0.120.7 allows logins with hardcoded password
• CVE-2016-1394 Cisco Firepower System Software 6.0.0 through 6.1.0 has a hardcoded account
• CVE-2017-6626 Cisco Finesse Notification Service for Cisco Unified Contact Center Enterprise (UCCE) 11.5(1) and 11.6(1) have a hardcoded password

These are just the first page of results for hardcoded passwords relating to Cisco software and appliances [CVE Cisco hardcoded password site:nvd.nist.gov] - according to Google there are over 300 of them. You'd think Cisco would have been burned enough on this already but I guess some companies never learn.

Stay tuned for more exciting hardcoded password shenanigans from Cisco.

Security isn't about efficiency. If you think least functionality is wrong, take it up with NIST.

The out-of-band authenticator SHALL uniquely authenticate itself in one of the following ways when communicating with the verifier:
...
Authenticate to a public mobile telephone network using a SIM card or equivalent that uniquely identifies the device. This method SHALL only be used if a secret is being sent from the verifier to the out-of-band device via the PSTN (SMS or voice).

The reference is the lates NIST recommendation. https://pages.nist.gov/800-63-...

5.1.1.1 Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.

no amount of wishing will put the AES-256 toothpaste back in the tube

Or the fact that pen & paper cryptography with the Vigenère_cipher and a sufficiently long key of random characters is still considered unbreakable. (Key sharing is a pain, but AES has the same problem)

It's all especially ironic as the "Advanced Encryption Standard" was a US Federal Government program where the world's cryptographers competed & collaborated to come up with unbreakable encryption. Or that other governments have done the same with NESSIE ECRYPT, and CRYPTEC.

And that US Federal Government is sponsoring workshops & standardization on post-quantum cryptography, ostenably so we'll have something secure & standardized before we can crack RSA, DSA, El Gamal, Elliptic Curves, etc. with quantum computers.

It's almost as if law enforcement doesn't want to go back to the heady days of 2006 when they did stake outs.

3) Does anyone have any idea of how difficult it is to leverage this particular vulnerability to do something useful?

NVD doesn't, yet. They have a big banner that says "undergoing analysis".

https://nvd.nist.gov/vuln/deta...

I guess technically the CVSS scale runs from 0 to 10, but still this one wallows in the bottom half of the Low classification.
https://nvd.nist.gov/vuln-metr...

iPhones use AES encryption for the phone, so naturally they should respond with the FIPS AES document

not quite right, how about some experts?
https://www.nist.gov/sites/def...

You can find the source for the topic of this post at the folowing site: https://pages.nist.gov/800-63-...

The updates are broken down into 3 sections, with section “b” being the most relevant to this e-mail.
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...

Extract from section 63b:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to):

Passwords obtained from previous breach corpuses.
Dictionary words.
Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

Context specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

*Verifiers SHALL implement a throttling mechanism that effectively limits the number of failed authentication attempts an attacker can make on the subscriber’s account as described in Section 5.2.2.*
*Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.*
*Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.*

Forcing password changes just to change the passwords also contributes to this security “fallacy”, that in fact does more to weaken our security than anything else.
When both of these are combined, we should find that the rules are in several ways, much like the TSA at airports, good security theater that causes no end of grief for travelers, yet does almost nothing to make people safer or more secure.

As a follow up, I saw an article in the Wall Street Journal regarding this topic.
https://www.wsj.com/articles/t...
That may be pay-walled, so another variant from Gizmodo.
http://gizmodo.com/the-guy-who...
Interesting to find out that the “supposed” strong password rules were developed by a bureaucrat with very little knowledge about computer security.

Finally, a previous paper I composed as an attempt to point out the fallacy of those laughably weak "strong password rules" several years ago.

You know, every time I see people asking for the ability to enforce "strong" password rules like the above, I have to laugh.
Those kinds of rules actually reduce the safety and "strength" of the passwords.

It wouldn't surprise me at all if those "recommendations" came directly from the NSA with the express purpose of making brute-force cracking of the passwords so much easier for them.

Let's do a little math here.

Start with a typical 8 character password requirement - with 95 printable characters in the ascii character set, we subtract 1 for the "space" character, leaving us with 94 character "options" for each of the 8 spaces.

So now, we do the math, 94 characters for each of the 8 positions gives us just a little over 6 quadrillion possibilities.

Now, we start to add in the "rules".
1 uppercase

You can find the source for the topic of this post at the folowing site: https://pages.nist.gov/800-63-...

The updates are broken down into 3 sections, with section “b” being the most relevant to this e-mail.
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...

Extract from section 63b:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to):

Passwords obtained from previous breach corpuses.
Dictionary words.
Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

Context specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

*Verifiers SHALL implement a throttling mechanism that effectively limits the number of failed authentication attempts an attacker can make on the subscriber’s account as described in Section 5.2.2.*
*Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.*
*Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.*

Forcing password changes just to change the passwords also contributes to this security “fallacy”, that in fact does more to weaken our security than anything else.
When both of these are combined, we should find that the rules are in several ways, much like the TSA at airports, good security theater that causes no end of grief for travelers, yet does almost nothing to make people safer or more secure.

As a follow up, I saw an article in the Wall Street Journal regarding this topic.
https://www.wsj.com/articles/t...
That may be pay-walled, so another variant from Gizmodo.
http://gizmodo.com/the-guy-who...
Interesting to find out that the “supposed” strong password rules were developed by a bureaucrat with very little knowledge about computer security.

Finally, a previous paper I composed as an attempt to point out the fallacy of those laughably weak "strong password rules" several years ago.

You know, every time I see people asking for the ability to enforce "strong" password rules like the above, I have to laugh.
Those kinds of rules actually reduce the safety and "strength" of the passwords.

It wouldn't surprise me at all if those "recommendations" came directly from the NSA with the express purpose of making brute-force cracking of the passwords so much easier for them.

Let's do a little math here.

Start with a typical 8 character password requirement - with 95 printable characters in the ascii character set, we subtract 1 for the "space" character, leaving us with 94 character "options" for each of the 8 spaces.

So now, we do the math, 94 characters for each of the 8 positions gives us just a little over 6 quadrillion possibilities.

Now, we start to add in the "rules".
1 uppercase

You can find the source for the topic of this post at the folowing site: https://pages.nist.gov/800-63-...

The updates are broken down into 3 sections, with section “b” being the most relevant to this e-mail.
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...

Extract from section 63b:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to):

Passwords obtained from previous breach corpuses.
Dictionary words.
Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

Context specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

*Verifiers SHALL implement a throttling mechanism that effectively limits the number of failed authentication attempts an attacker can make on the subscriber’s account as described in Section 5.2.2.*
*Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.*
*Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.*

Forcing password changes just to change the passwords also contributes to this security “fallacy”, that in fact does more to weaken our security than anything else.
When both of these are combined, we should find that the rules are in several ways, much like the TSA at airports, good security theater that causes no end of grief for travelers, yet does almost nothing to make people safer or more secure.

As a follow up, I saw an article in the Wall Street Journal regarding this topic.
https://www.wsj.com/articles/t...
That may be pay-walled, so another variant from Gizmodo.
http://gizmodo.com/the-guy-who...
Interesting to find out that the “supposed” strong password rules were developed by a bureaucrat with very little knowledge about computer security.

Finally, a previous paper I composed as an attempt to point out the fallacy of those laughably weak "strong password rules" several years ago.

You know, every time I see people asking for the ability to enforce "strong" password rules like the above, I have to laugh.
Those kinds of rules actually reduce the safety and "strength" of the passwords.

It wouldn't surprise me at all if those "recommendations" came directly from the NSA with the express purpose of making brute-force cracking of the passwords so much easier for them.

Let's do a little math here.

Start with a typical 8 character password requirement - with 95 printable characters in the ascii character set, we subtract 1 for the "space" character, leaving us with 94 character "options" for each of the 8 spaces.

So now, we do the math, 94 characters for each of the 8 positions gives us just a little over 6 quadrillion possibilities.

Now, we start to add in the "rules".
1 uppercase

You can find the source for the topic of this post at the folowing site: https://pages.nist.gov/800-63-...

The updates are broken down into 3 sections, with section “b” being the most relevant to this e-mail.
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...

Extract from section 63b:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to):

Passwords obtained from previous breach corpuses.
Dictionary words.
Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

Context specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

*Verifiers SHALL implement a throttling mechanism that effectively limits the number of failed authentication attempts an attacker can make on the subscriber’s account as described in Section 5.2.2.*
*Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.*
*Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.*

Forcing password changes just to change the passwords also contributes to this security “fallacy”, that in fact does more to weaken our security than anything else.
When both of these are combined, we should find that the rules are in several ways, much like the TSA at airports, good security theater that causes no end of grief for travelers, yet does almost nothing to make people safer or more secure.

As a follow up, I saw an article in the Wall Street Journal regarding this topic.
https://www.wsj.com/articles/t...
That may be pay-walled, so another variant from Gizmodo.
http://gizmodo.com/the-guy-who...
Interesting to find out that the “supposed” strong password rules were developed by a bureaucrat with very little knowledge about computer security.

Finally, a previous paper I composed as an attempt to point out the fallacy of those laughably weak "strong password rules" several years ago.

You know, every time I see people asking for the ability to enforce "strong" password rules like the above, I have to laugh.
Those kinds of rules actually reduce the safety and "strength" of the passwords.

It wouldn't surprise me at all if those "recommendations" came directly from the NSA with the express purpose of making brute-force cracking of the passwords so much easier for them.

Let's do a little math here.

Start with a typical 8 character password requirement - with 95 printable characters in the ascii character set, we subtract 1 for the "space" character, leaving us with 94 character "options" for each of the 8 spaces.

So now, we do the math, 94 characters for each of the 8 positions gives us just a little over 6 quadrillion possibilities.

Now, we start to add in the "rules".
1 uppercase

NIST recently published its four-volume SP800-63b Digital Identity Guidelines . Among other things, it makes three important suggestions when it comes to passwords:

1. Stop it with the annoying password complexity rules. They make passwords harder to remember. They increase errors because artificially complex passwords are harder to type in. And they don't help that much. It's better to allow people to use pass phrases.
2. Stop it with password expiration. That was an old idea for an old way we used computers. Today, don't make people change their passwords unless there's indication of compromise.
3. Let people use password managers. This is how we deal with all the passwords we need.

These password rules were failed attempts to fix the user. Better we fix the security systems.

What is Skip Lot Sampling?

Skip Lot sampling means that only a fraction of the submitted lots are inspected. This mode of sampling is of the cost-saving variety in terms of time and effort. However skip-lot sampling should only be used when it has been demonstrated that the quality of the submitted product is very good.

If the expected (or demonstrated) consistency of the product is poor, either test every sample or fire the supplier.