Slashdot Mirror

Knock yourself out.

NIST Releases Final WTC 7 Investigation Report

2 Planes managed to take out 3 buildings, with the third containing much interesting paperwork that conveniently burned up..

There is no genuine mystery here, the facts are available. Perhaps that is inconvenient for you?

NIST Releases Final WTC 7 Investigation Report

The extensive three-year scientific and technical building and fire safety investigation found that the fires on multiple floors in WTC 7, which were uncontrolled but otherwise similar to fires experienced in other tall buildings, caused an extraordinary event. Heating of floor beams and girders caused a critical support column to fail, initiating a fire-induced progressive collapse that brought the building down.

In response to comments from the building community, NIST conducted an additional computer analysis. The goal was to see if the loss of WTC 7's Column 79—the structural component identified as the one whose failure on 9/11 started the progressive collapse—would still have led to a complete loss of the building if fire or damage from the falling debris of the nearby WTC 1 tower were not factors. The investigation team concluded that the column's failure under any circumstance would have initiated the destructive sequence of events.

9/11 "Truthers" are one of the ugliest plagues to curse Slashdot.

First, DES is 56 bit (near enough 60). Triple DES as per first mode (the authorised standard) is 168 bits. The article fails to distinguish, implying the authors are just a little bit naff. 3DES seems to be quite safe, as long as not used in DES emulation mode. And who the hell emulates a mode that was broken in the 80s?

Second, Blowfish was replaced by TwoFish, ThreeFish and Speck. Skein, an entrant to the DES3 challenge, makes use of ThreeFish.

Third, the Wikipedia page states it has been known for a long time that weak keys are bad. This particular attack, though, is a birthday attack. You can find all the ciphers vulnerable or free that you should be using. Anything not on the list is something you are solely responsible for.

http://csrc.nist.gov/archive/a...

In other words, this information is about as useful as telling up that Model T Fords weren't good at cornering at highway speeds. Below are some links, I can't be buggered to HTML-ify them.

https://en.m.wikipedia.org/wik...
http://www.skein-hash.info/
https://en.m.wikipedia.org/wik...
https://en.m.wikipedia.org/wik...

I do not trust most encryption software these days, but that's because programmers these days are sloppy and arrogant.

Just days ago, NIST recommended that SMS no longer be used for authentication

https://pages.nist.gov/800-63-...

I see

Just days ago, NIST recommended that SMS no longer be used for authentication

https://pages.nist.gov/800-63-...

To be fair, the cited (and likely incomplete) list from the summary is "compromise servers and devices running platforms like Drupal, WordPress, Magento, Jetspeed, Exarid, AirOS." The takeaway here is pretty much this: widespread deployment of shitty PHP and Java apps strikes again ... -PCP

This isn't a problem of the "widespread deployment of shitty PHP and Java apps". The vulnerability which this Trojan exploits is CVE-2014-3704 and was patched by Drupal Security Team on the 15th of October in 2014

The circumstances and agents which have led to this Trojan exploiting Linux systems and Drupal frameworks in the wild is, as with many such things, are multiple and varied. They include installations that are underresourced, shops with critical dependencies that cannot easily upgrade, web apps that at first and second glance do not have interfaces outside an intranet, etc. etc. and so on and so forth

The key is to stop pointing fingers and laying blame, unless the fingers point to the creators and distributors of the malware. The exploitation and abuse of computer infrastructure is part of territory. Blaming failures on the vulnerable is a sysadmin's version of victim-blaming and does little to mitigate the problem and much to generate community dysfunction.

Instead of finger pointing, spread the word, inform your unknowing and unwitting colleagues, train junior developers about how to remain secure for multiple computing environments with complex layers of computing infrastructure.

Our great-great-great-great grandchildren will thank you.

There are updates to FIPS 140-2 every few months, as you can see here:
http://csrc.nist.gov/groups/ST...

Therefore you can easily be *compliant* and up-to-date, no problem.

If you want to be *certified* and up-to-date, the low cost option is to use something like the OpenSSL FIPS Object Module, which is recertified every six months or so. (This is a very restricted subset of OpenSSL). That provides the latest certified encryption.

If you want to also certify the product as a whole, you can do that and batch any security-sensitive changes into new versions, then recertify new versions only infrequently.

Federal purchasing, including DoD (military) is done through an open bid process. The acquiring agency publishes a very detailed requirements document. The encryption requirement normally refers to FIPS 140-2 (FIPS: Federal Information Processing Standard). The standard specifies not only which algorithms, but which implementations are acceptable, so you use a FIPS-certified library. FIPS-140-2 can be found here:
http://csrc.nist.gov/groups/ST...

Because most companies and standards bodies aren't run by security specialists, they too often refer to FIPS-140-2. "Must meet DoD security requirements" is a lot easier to specify in a contract than figuring out all the details yourself.

The NIST most certainly can ban their use for government projects

Which part of "of course, some organizations may choose to make those guidelines mandatory" did you not understand?

My point in mentioning this is to say that NIST is a government agency and that certain parts of the government are bound to NIST determinations. Not as a matter of self determination but a matter of law. And that you cannot just say that "NIST can't ban SMS 2FA" because they did exactly that for the US Government.

So it's not just a matter of verifying the phone is a mobile phone. There are more sophisticated attacks that SMS auth allows. Also, you can clone someone's SIM card or use a social engineering attack to get a new SIM issued for a specific number.

Those are not "sophisticated attacks" and other two factor authentication schemes are subject to cloning and social engineering. It is exceptionally stupid to give up the extra security and simplicity of SMS authentication because of such objections.

The problem is not 2FA but doing 2FA over SMS. And those are relatively sophisticated attacks as they require a bit more knowledge and planning than just taking over someone's email account and using the password reset option to capture password reset requests or something like that. You actually have to know who the person is and who their cell phone provider is in order to execute such an attack. If you're overseas, you may need a local accomplice to help you execute the attack. There are better ways to provide 2FA. For instance, you can use an auth system that uses secret information from the server plus a user PIN to help prevent someone from using a auth code captured by something like a MITM attack.

This is pure lip service. Guess where they get all their steel that composes 80% of the car from? Yeah, it's all coming from China anyway, so this is meaningless.

First, steel does not compose 80% of a vehicle. The number is somewhere around 55% on average though it obviously varies by vehicle and it is about 25% of the cost of the vehicle. Second, Japanese car manufacturers do get some steel from China but they also get a very substantial amount domestically. Japan has a fairly robust domestic steel industry including 2 of the 10 biggest steel makers by volume in the world. There are also numerous steel suppliers who have no production in China at all. It's definitely not "all coming from China". Third, "the metals that are primarily supplied by China" they are talking about are rare earth elements, not comparatively common metals like steel. Don't conflate the two. Japan could in principle source all their steel from somewhere other than China if they wanted to. For rare earths, China is basically the only game in town right now. Totally different markets.

In the 60's I'd be scanning the shortwave frequencies and run across WWVand it always made me pause. A station that just tick-tocked and then some dude would say the time and start tick-tocking again. I knew what it was but it always made me stop for a moment. It was just sort of surreal.

There are MANY NTP servers who's primary clock source is NIST ACTS you know, using a analog modem. NTPd supports this directly and is quite reliable as a primary time source.

NTP isn't a primary time source, but a time distribution service.

It's described like there could be potential DOS or "or possibly have unspecified other impact".

While that's not necessarily the advertised "take over your whole system" in the article heading,it does seem like potentially the chrome sandbox would be busted and code could be executed as the user.

http://www.nist.gov/itl/iad/ig...

Jim Cole, Homeland Security Investigations, DHS & Laura Carroll, National Center for Missing and Exploited Children,"The Use of Tattoo Detection and Recognition to Rescue Child Victims"

Hooray for the EFF.

> Windows's remote support

For Windows, here are a few options to take over their system which don't require the user to click anything:

https://web.nvd.nist.gov/view/...

Keep one copy in a safe in a tamper evident container. Either hardcopy or something like a read-only SD card or USB thumb drive will work. Routinely open the safe and verify that the key container hasn't been compromised.

Distribute copies to trusted parties in tamper evident containers. You can also split the key up into multiple pieces and distribute different pieces to different people. Don't let anyone know who else has copies. You will also need to routinely visit these trusted parties and confirm that they have not tampered with the key container.

Be sure to protect your private key with a wrapping passphrase if supported, otherwise use encrypted media. You should also specify a reasonable expiration date for your key and use the appropriate revocation mechanism, e.g. CRLs for x509 certs and revocation certificates for PGP. You shouldn't be too worried about the longevity of your storage media since you should be periodically updating your keys. I would recommend against media with photosensitive dyes and go with the more robust M-Disc based discs.

If at all possible, do not ever let your private key touch a networked/unsecure device. Use a hardware based key manager if possible, e.g. Yubikey. Keep a separate machine booted from read-only media for the sole purpose of key creation in a secured location. You can also use this machine for encryption/decryption, but you need to transfer data via sneakernet. Definitely don't keep a WiFi card or even an audio output device in the machine. Do all of your work inside a Faraday Cage if possible.

Read up on guidance from the various organizations. E.G. NIST's Computer Security Resource Center

TFA:

the newest of which is so accurate, it gains or loses only a second every 300 million years

First of all, that's aspirational (or was) in most of the other articles I found.

Contra TFA: NIST Launches NIST-F2

Primary standards such as NIST-F1 and NIST-F2 are operated for periods of a few weeks several times each year to calibrate NIST timescales, collections of stable commercial clocks such as hydrogen masers used to keep time ... Technically, both F1 and F2 are frequency standards, meaning they are used to measure the size of the SI second and calibrate the "ticks" of other clocks.

Unfortunately, even contra TFA is weak geek tea:

Both NIST-F1 and NIST-F2 measure the frequency of a particular transition in the cesium atom—which is 9,192,631,770 vibrations per second, and is used to define the second, the international (SI) unit of time.

I guess there's a reason why people with tiny UIDs memorize pi to a silly number of places: it helps you not leave off the other five or six significant digits in the rare case where it actually matters. The real frequency standard is only, like, approximately a million times better than that long-assed, dock-tailed string of digits visually implies.

Truly inconceivable—almost—and yet barely able to time slice the total perspective vortex.

Finally, some obligatory geek porn: Atomic fountain

The summary isn't very clear about the nature of the problem. The CVE report is a little better. The problem is a bug in the Qualcomm "performance component", which is in a Linux kernel module. So, it's essentially a driver bug, which is nothing remotely new or surprising. The only noteworthy bit here is that it's a bug in a driver that is used on a huge number of devices, many of which aren't easy to update.

The moral of this story is: bugs happen, updates are crucial for security.

In March 1960, the call sign WWVB was obtained by NBS for the 60 kHz station. The “B” in the call sign probably stands for Boulder, the site of the original transmitter. However, one interesting theory is that the “B” could stand for Brown. W. W. Brown, one of the designers of the Fort Collins station, was employed as a contractor by NBS when the call sign application was submitted. Perhaps not coincidentally, his initials were W. W. B.

Source: http://www.nist.gov/pml/div688...

Just get a quartz clock and calibrate it.

People working on trains and airplanes etc. have to (or at least had to) get their watches calibrated. I remember calibrating my Seiko quartz watches myself back then (1970) to +/- 1 second a month. I could probably have done better.

http://tf.nist.gov/general/pdf...

its probably things like this: http://csrc.nist.gov/publicati...
= determining needed password length based on assumption of using 300 baud modem connection to the server etc

[Citation needed]

When NIST drops the degrees from degrees Celsius then so will I. Until then, I'll still continue to refer to individual temperatures on the Celsius scale as degrees Celsius.

>how, exactly, we'll be able to secure our data once quantum computing becomes widely available

Look here

Summary..
Encryption and symmetric signing will need to double the key size for the same security bound.
RSA, ECDH and ECDSA will be insecure.

So key management goes back to the pre-DH days.

Payment systems upgrades can be year-long projects. Recertifying with your bank and other partners takes months. And with everyone having to do it at the same time, everyone is stretched thin getting it all done.

Well, it's a good thing for them that NIST declared that "SHA-1 shall not be used for digital signature generation after December 31, 2013", back in January of 2011. They should be done with their year-long POS upgrade by sometime in 2012 at the latest.

Maybe businesses should follow actual security best practices instead of waiting for ultimatums.

The balls are highly enriched, consisting of 99.9995% silicon-28 with a minimum of the other isotopes found in natural-abundance silicon.

The CVSS score is a medium of 6.1 for the CVE. So this isn't as bad as Heartbleed

First, Heartbleed was actually a 5.0 base score, so this is more serious if you go strictly by CVSS score (which is not necessarily advisable). Reference.

Second, CVSS scores are based on a certain formula and small set of conditions; in particular, vulnerabilities are scored based on their immediate impact and not necessarily things that occur down the line. In other words, CVSS base scores do not include environmental metrics (There is a CVSS environmental score, but almost no one uses it except for CERT). So looking only at the base score is not always a good indication of severity; possibly its a good first approximation, but it's good to look into the details too. Since glibc is part of pretty much everything out there, this is a pretty serious issue.

http://csrc.nist.gov/publicati...

Name and phone number together are considered PII. (Page 2-2)

You are reading the NIST guide wrong. 2-2 has a very important modifier "may be", which is not "is considered".

See the example in 3-5. If the information is publically available as is the case with most government employees, it is a not PII.

http://csrc.nist.gov/publicati...

Name and phone number together are considered PII. (Page 2-2)

Modern day LiG mercury thermometers crafted to NIST specifications have an uncertainty rate of 0.2 degrees C. Which is awfully fucking close to my 0.5 degrees F isn't it? I suppose that the error bars should have been higher a hundred years ago even assuming perfect conditions? We can go with that if you want. Makes the AGW side's argument much worse of course. Had you bothered to look it up yourself you would have known this but you just had to wave your dick around.

http://www.nist.gov/pml/div685...

There are also some IP network connected medical devices with virtually zero security. Check this out. This was definitely a WTF moment.
https://ics-cert.us-cert.gov/a...
https://web.nvd.nist.gov/view/...
and http://www.securityweek.com/se...

That's a lot of commenters. The federal stuff I comment on seems to have about 15 others who care enough to comment. The comments are pretty good though.

NVD and CVE are great tools for finding if there are vulnerabilities that effect you... but they are largely self reported and lumping a bunch of bugs into one "vulnerability" only helps with BS lists like this while hurting the usefulness of the databases.

Please don't use this data for a penis contest.

A second used to be 1/86,400 of a mean solar day (e.g. high noon to high noon). A slowing day would mean a lengthening second, which would screw up measurements of basic physical constants, e.g. the speed of light.

The current definition of a second is http://physics.nist.gov/cuu/Un...

> The second is the duration of 9 192 631 770 periods of the
> radiation corresponding to the transition between the two
> hyperfine levels of the ground state of the cesium 133 atom.

In theory, any sufficiently advanced research lab on the planet can duplicate this measurement.

In recent years people started using k to denote 1000? What kind of drivel is that? Only if 1799 is recent...
http://physics.nist.gov/cuu/Un...

M for Mega or Million has been used for a very long time. MM only makes sense in Roman times, who the hell uses M to denote 1000 besides the Romans? Do you often mix Roman Numerals and Latin Numerals in the same sentence? Also, since when is MM equal to M multiplied by M instead of M plus M as Roman numerals work? MM is 2000, not 1,000,000.

CVE-2015-6988 - CVSS score 10.0 https://web.nvd.nist.gov/view/...

The kernel in Apple iOS before 9.1 and OS X before 10.11.1 does not initialize an unspecified data structure, which allows remote attackers to execute arbitrary code via vectors involving an unknown network-connectivity requirement.

That's just the highest score. I'm not sure why you think OS X does not have any scores above 2. There are large numbers of CVEs above 2.

Wow! you are exactly right! I don't know what I was doing; but I was obviously not "filtering" the CVE Results correctly, sorry!

However, and again I might be looking at the list incorrectly; but when I went to check on the (frankly eye-popping) list of OS X Vulnerabilities for 2015, I couldn't find any that were UNRESOLVED. Is there a way to find a list of Vulnerabilities on the CVE List that you can Filter on whether there was a Solution? Because as it stands, it looks like Apple has cleared up everything as of OS X 10.11.1, iOS 9.0.1 (IIRC) and WatchOS 2.01, and that there are no "outstanding Vulnerabilities".

Is that true?

CVE-2015-6988 - CVSS score 10.0
https://web.nvd.nist.gov/view/...

The kernel in Apple iOS before 9.1 and OS X before 10.11.1 does not initialize an unspecified data structure, which allows remote attackers to execute arbitrary code via vectors involving an unknown network-connectivity requirement.

That's just the highest score. I'm not sure why you think OS X does not have any scores above 2. There are large numbers of CVEs above 2.

It blames the "towelroot" Android exploit as being the fault of Linux

But towelroot was the fault of linux, no?

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3153

Many GPS receivers will output a very accurate 1 sec tic. I've used this to check for multipath drift from WWV in maintaining a cesium beam atomic clock in one installation. The time standards were used to callibrate RF equipment to NIST standards. Multi source verification validates source drift and gives the degree of confidence for the certification paperwork. If your tracable standards are accurate to each other with jitter and drift to 8 9's, you can validate equipment as to being within 7 9's. This would mean a 1 MHZ frequency standard could be validated to be between 999,999.9 hz to 1,000,000.1 hz against national standards.

Multiple calibrated standards would then not hetrodyne with each other more than 1 beat every 10 seconds. Most of the time the max obsurved beat would be less then 1 in 100 seconds.

http://www.nist.gov/pml/mercur...
GPS time is locked to a tracable standard along with WWV.

not sure how this fits into this thread, http://nist.gov/el/isd/cs/wpsm...

However, for a machine I'm giving to a friend or family member, what I wind up doing is just a format command, then a pass with cipher /w (assuming Windows.) Since all my volumes are BitLocker protected, a format command overwrites the areas on the hard drive with the volume master key multiple times. Even with the right BitLocker password or recovery key protector, the data is gone, since the master key cannot be retrieved. The cipher /w just does a simple three pass (zeroes, ones, random numbers), which is good enough for almost anything.

Why? What's the point? Self-entitled "nerds" here keep perpetuating the same old myths that you need to wipe and wipe and wipe and wipe a billion times for the data to be completely inaccessible and are just making themselves look just as ignorant as the people they berate themselves.There is plenty of research on this topic and I wish people would just finally learn something and stop spreading some god damn myths.

The purpose of this paper was a categorical settlement to the controversy surrounding the misconceptions involving the belief that data can be recovered following a wipe procedure. This study has demonstrated that correctly wiped data cannot reasonably retrieved even if it of a small size or found only over small parts of the hard drive. Not even with the use of a MFM or other known methods. The belief that a tool can be developed to retrieve gigabytes or terabytes of data of information from a wiped drive is in error.

        Although there is a good chance of recovery for any individual bit from a drive, the chance of recovery of any amount of data from a drive using an electron microscope are negligible. Even speculating on the possible recovery of an old drive, there is no likelihood that any data would be recoverable from the drive. The forensic recovery of data using electron microscopy is infeasible. This was true both on old drives and has become more difficult over tine. Further, there is a need for the data to have been written and then wiped on a raw unused drive for there to be any hopy of any level of recovery even at the bit level, which does not reflect real situations. It is unlikely that a recovered drive will have not been used for a period of time and the interaction of defragmentation, file copies and general use that overwrites data areas negates any chance of data recovery. The fallacy that data can be forensically recovered using an electron microscope or related means needs to be put to rest. -- https://www.google.com/search?...

Studies have shown that most of today’s media can be effectively cleared by one overwrite.

        Purging information is a media sanitization process that protects the confidentiality of information against a laboratory attack. For some media, clearing media would not suffice for purging. However, for ATA disk drives manufactured after 2001 (over 15 GB) the terms clearing and purging have converged. -- http://csrc.nist.gov/publicati...

For the purposes of clarity, this will be repeated: If every single sector of a modern hard drive is overwritten, then NO DATA can be recovered, and especially not by the police. In fact companies such as Ontrack, who spend millions of dollars on research into data recovery are not able to do this. This wiping does not need to be done 33, 12, or even 3 times. Just once. -- https://whereismydata.wordpres...

These things go on forever if one just bothers to Google a bit, I could keep linking and quoting stuff for several books' worth.

as i cannot see how a simple image... could possibly compromise a target machine

It can. I believe libjpeg was the first image parser to have a vulnerability, but LibPNG has had quite a few. Image and Video parsers are complex, and complex code means high chances for vulnerabilities.

Is your browser complex? You better believe it's full of vulnerabilities. We only hear about Flash vulns because they are the low-hanging fruit.

If only there were some kind of national institution that set standards for technology... That theoretical organization could theoretically define a scale of high, medium, and low for confidentiality, integrity, and availability. With that in place the organization might go further and define security controls for meeting those objectives. Perhaps they should even have some kind of national database listing well-known vulnerabilities and standards for automating security.

If only there were some kind of national institution that set standards for technology... That theoretical organization could theoretically define a scale of high, medium, and low for confidentiality, integrity, and availability. With that in place the organization might go further and define security controls for meeting those objectives. Perhaps they should even have some kind of national database listing well-known vulnerabilities and standards for automating security.

If only there were some kind of national institution that set standards for technology... That theoretical organization could theoretically define a scale of high, medium, and low for confidentiality, integrity, and availability. With that in place the organization might go further and define security controls for meeting those objectives. Perhaps they should even have some kind of national database listing well-known vulnerabilities and standards for automating security.

If only there were some kind of national institution that set standards for technology... That theoretical organization could theoretically define a scale of high, medium, and low for confidentiality, integrity, and availability. With that in place the organization might go further and define security controls for meeting those objectives. Perhaps they should even have some kind of national database listing well-known vulnerabilities and standards for automating security.

Are they going with something lattice based?

Hm.. An internet search finds this one: http://research.microsoft.com/...
The headline is "Post-quantum key exchange for the TLS protocol from the ring learning with errors problem", so it doesn't seem to have strictly to do with a lattice-based problem if it's the algorithm that was meant in the article above.
And this is an explanation: http://csrc.nist.gov/groups/ST...

I haven't understood the problem that deeply but when I do I will post it here.

This article is about a waste of time. Microsoft has developed an encryption method resistant to quantum computers, it claims. Alright? What is that method? How does it differ from current encryption techniques? Why is that well suited to encrypting against quantum computers? How did you come to that conclusion, given that you don't have one to test against? Are we just supposed to believe Microsoft when they say "Trust us, this is secure"?

No of course not. You're meant to read this article, understand that it's an example of bad science journalism, and because of your innate geekiness and intellectual curiosity you should use the power of Google or Bing to find the scientific research in question:

http://csrc.nist.gov/groups/ST...

Setup with a noVNC web interfaces, and sshkey management in the web management panel (so users can employ their personal ssh keys post-deployment)

[Unbalanced parentheses.] Which guide to configuring keys in popular SSH clients does your documentation link to?

We don't provide one. Support refers users to the official security guides for the appropriate distro, general questions are answered using this as the main source. Documentation for users is almost identical to that on Digital Ocean (they target the same market segment). We don't write subject documentation for users. They do, if we approve it we pay them and publish it (it's the low cost end of the market, minimal SLA).

Internally we follow NIST procedures and are audited to meet several ISO 27K standards (mainly for insurance purposes). We don't own any data centres, or control the hardware. That's a very common practise, with all but the high-end hosting providers (usually).
Our internal procedures are more stringent with the main (non-hosting) business as most of the clients are Defence related (this is Canberra, the majority of work here is Defence related).

However I was (redundantly) asking why someone who calls themselves a security professional and system administrator does not follow BP.

Because BP got hacked by Chinese? Naaah.

[smile] where following BP means jumping in a tug and telling the captain to "follow that slick".

Stronger for everyone except them, perhaps.

They did something similar, put a couple of specific constants, into the Dual_EC_DRBG random number generator. It was later shown that they amounted to a skeleton key - if you knew the numbers used to derive the constants, you could predict the future output of a given RNG instance with only a small amount of sample data. So any encryption based on Dual_EC_DRBG could be considered to be broken by the NSA (somewhat conveniently, in a way that only the NSA could actually prove).

Despite the poor performance of this algorithm which lead most implementers to ignore it, it managed to end up as the default in the product of one of the most trusted vendors, RSA. There was speculation that the NSA bribed them to make this design choice. [1]

Unsurprisingly, it was withdrawn from the standard in 2014.

[1] The only comment on that story makes the same point - that the NSA, in the past, had reinforced weaknesses in DES. In the light of the later evidence about Dual_EC_DRBG, that may bear further examination - if the change was the tweaking of constants, it's entirely possible that this reinforced the standard for everyone but the NSA.

I thought we weren't supposed to use flash any more. CVE's & mozilla & facebook

I don't want to have unprotected vids.