Slashdot Mirror

HashCat, an open-source password recovery tool, can now crack an eight-character Windows NTLM password hash in less than 2.5 hours. "Current password cracking benchmarks show that the minimum eight character password, no matter how complex, can be cracked in less than 2.5 hours" using a hardware rig that utilizes eight Nvidia GTX 2080Ti GPUs, explained a hacker who goes by the pseudonym Tinker on Twitter in a DM conversation with The Register. "The eight character password is dead." From the report: It's dead at least in the context of hacking attacks on organizations that rely on Windows and Active Directory. NTLM is an old Microsoft authentication protocol that has since been replaced with Kerberos. According to Tinker, it's still used for storing Windows passwords locally or in the NTDS.dit file in Active Directory Domain Controllers. It's dead at least in the context of hacking attacks on organizations that rely on Windows and Active Directory. NTLM is an old Microsoft authentication protocol that has since been replaced with Kerberos. Tinker estimates that buying the GPU power described would require about $10,000; others have claimed the necessary computer power to crack an eight-character NTLM password hash can be rented in Amazon's cloud for just $25.

NIST's latest guidelines say passwords should be at least eight characters long. Some online service providers don't even demand that much. When security researcher Troy Hunt examined the minimum password lengths at various websites last year, he found that while Google, Microsoft and Yahoo set the bar at eight, Facebook, LinkedIn and Twitter only required six. Tinker said the eight character password was used as a benchmark because it's what many organizations recommend as the minimum password length and many corporate IT policies reflect that guidance. So how long is long enough to sleep soundly until the next technical advance changes everything? Tinker recommends a random five-word passphrase, something along the lines of the four-word example popularized by online comic XKCD, "correcthorsebatterystaple." That or whatever maximum length random password via a password management app, with two-factor authentication enabled in either case.

An anonymous reader quotes a report from ZDNet: A zero-day vulnerability present in security cameras and surveillance equipment using Nuuo software is thought to impact hundreds of thousands of devices worldwide. Researchers from cybersecurity firm Tenable disclosed the bug, which has been assigned as CVE-2018-1149. The vulnerability cannot get much more serious, as it allows attackers to remotely execute code in the software, the researchers said in a security advisory on Monday. Nuuo, describing itself as a provider of "trusted video management" software, offers a range of video solutions for surveillance systems in industries including transport, banking, government, and residential areas.

Dubbed "Peekaboo," the zero-day stack buffer overflow vulnerability, when exploited, allows threat actors to view and tamper with video surveillance recordings and feeds. It is also possible to use the bug to steal data including credentials, IP addresses, port usage, and the make & models of connected surveillance devices. In addition, the bug could be used to fully disable cameras and surveillance products. Peekaboo specifically impacts the NVRMini 2 NAS and network video recorder, which acts as a hub for connected surveillance products. When exploited, the product permitted access to the control management system (CMS) interface, which further exposes credentials of all connected video surveillance cameras connected to the storage system.

Researchers have uncovered vulnerabilities in popular virtual private network (VPN) software, ProtonVPN and NordVPN, which can lead to the execution of arbitrary code by attackers. From a report: Last week, Cisco Talos security researchers said the security flaws, CVE-2018-3952 and CVE-2018-4010, permit code execution by attackers on Microsoft Windows machines. The vulnerabilities are similar to a Windows privilege escalation security flaw uncovered by VerSprite, which is tracked as CVE-2018-10169. Security patches were applied in April by both clients to resolve the original security hole, but according to Talos, "despite the fix, it is still possible to execute code as an administrator on the system." The initial vulnerability was caused by similar design issues in both clients. The interface for both NordVPN and ProtonVPN execute binaries with the permission of a logged-in user, and this includes the selection of a VPN configuration option, such as a desired VPN server location. This information is sent to a service when "connect" is clicked by way of an OpenVPN configuration file. However, VerSprite was able to create a crafted OpenVPN file which could be sent to the service, loaded, and executed.

An anonymous reader writes: Current versions of Ubuntu and CentOS are disabling a security feature that was added to the GNOME desktop environment last year. The feature's name is Bubblewrap, which is a sandbox environment that the GNOME Project added to secure GNOME's thumbnail parsers in July 2017, with the release of GNOME 3.26. In recent years, security researchers have proven that thumbnail parses can be an attack vector [1, 2, 3].

Ubuntu Security Tech Lead Alex Murray said the Ubuntu team chose to disable Bubblewrap inside Ubuntu because they did not have the time to perform a security audit. Murray blamed the many CPU bugs (Spectre, Meltdown, etc.), which kept the team busy and prevented them to audit the feature.

New submitter SteveSgt writes: A forum thread on QRZ.com indicates that the shortwave time broadcasts by the National Institute of Standards and Technology (NIST) from stations WWV (Colorado) and WWVH (Hawaii) may be slashed in budget year 2019. [One of the proposed reductions includes "$6.3 million supporting fundamental measurement dissemination, including the shutdown of NIST radio stations in Colorado and Hawaii."] While the WWV broadcasts may seem like an anachronism to some Slashdotters, they remain a crucial component in many unexpected services, from over-the-air broadcasters and traffic signals, to medical devices, wall clocks, and wrist watches. The signals serve as standard beacons for radio propagation, and as a frequency reference for alignment of a broad range of communications equipment. It's easy to imagine that not even the NIST knows every service and device that could be impacted by this decision.

Public exploit code has been published for a severe vulnerability which last year affected Hewlett Packard Integrated Lights-Out 4 (HP iLO 4), a tool for remotely managing the company's servers.

HPE "silently released" patches last August, an anonymous reader reports, adding "details only emerged this spring after researchers started presenting their work at security conferences." The vulnerability is an authentication bypass that allows attackers access to HP iLO consoles. Researchers say this access can later be used to extract cleartext passwords, execute malicious code, and even replace iLO firmware. But besides being a remotely exploitable flaw, this vulnerability is also as easy as it gets when it comes to exploitation, requiring a cURL request and 29 letter "A" characters, as below:

curl -H "Connection: AAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

Because of its simplicity and remote exploitation factor, the vulnerability — tracked as CVE-2017-12542 — received a severity score of 9.8 out of 10.

Remember NIST, the non-regulatory agency of the U.S. Department of Commerce? Their mission expanded over the years to protecting businesses from cyberthreats, including a "Cybersecurty Framework" first published in 2014. "The original goal was to develop a voluntary framework to help organizations manage cybersecurity risk in the nation's critical infrastructure, such as bridges and the electric power grid," NIST wrote in January, "but the framework has been widely adopted by many types of organizations across the country and around the world." Now SC Media reports: The second draft of the update to the National Institute of Standards and Technology's cybersecurity framework, NIST 1.1, is meant "to clarify, refine, and enhance the Cybersecurity Framework, amplifying its value and making it easier to use," according to NIST. Specifically, it brings clarity to cybersecurity measurement language and tackles improving security of the supply chain. Calling the initial NIST CSF "a landmark effort" that delivered "important benefits, such as providing common language for different models" of standards and best practices already in use, Larry Clinton, president and CEO of the Internet Security Alliance, said "it fell short of some of the most critical demands of Presidential Executive Order 13636, which generated its development...

"To begin with, the new draft makes it clear that our goal is not some undefined metric for use of the Framework, but for effective use of the Framework. Moreover, this use-metric needs to be tied not to some generic standard, but to be calibrated to the unique threat picture, risk appetite and business objective of a particular organization"... Clinton praised the process used by NIST as "a model 'use case' for how government needs to engage with its industry partners to address the cybersecurity issue." The internet's inherent interconnectedness makes it impossible for sustainable security to be achieved through anything other than true partnership, he contended.
Slashdot reader Presto Vivace reminds you that public comments on the draft Framework and Roadmap are due to NIST by 11:59 p.m. EST on January 19, 2018. "If you have an opinion about this, NOW is the time to express it."

Remember NIST, the non-regulatory agency of the U.S. Department of Commerce? Their mission expanded over the years to protecting businesses from cyberthreats, including a "Cybersecurty Framework" first published in 2014. "The original goal was to develop a voluntary framework to help organizations manage cybersecurity risk in the nation's critical infrastructure, such as bridges and the electric power grid," NIST wrote in January, "but the framework has been widely adopted by many types of organizations across the country and around the world." Now SC Media reports: The second draft of the update to the National Institute of Standards and Technology's cybersecurity framework, NIST 1.1, is meant "to clarify, refine, and enhance the Cybersecurity Framework, amplifying its value and making it easier to use," according to NIST. Specifically, it brings clarity to cybersecurity measurement language and tackles improving security of the supply chain. Calling the initial NIST CSF "a landmark effort" that delivered "important benefits, such as providing common language for different models" of standards and best practices already in use, Larry Clinton, president and CEO of the Internet Security Alliance, said "it fell short of some of the most critical demands of Presidential Executive Order 13636, which generated its development...

"To begin with, the new draft makes it clear that our goal is not some undefined metric for use of the Framework, but for effective use of the Framework. Moreover, this use-metric needs to be tied not to some generic standard, but to be calibrated to the unique threat picture, risk appetite and business objective of a particular organization"... Clinton praised the process used by NIST as "a model 'use case' for how government needs to engage with its industry partners to address the cybersecurity issue." The internet's inherent interconnectedness makes it impossible for sustainable security to be achieved through anything other than true partnership, he contended.
Slashdot reader Presto Vivace reminds you that public comments on the draft Framework and Roadmap are due to NIST by 11:59 p.m. EST on January 19, 2018. "If you have an opinion about this, NOW is the time to express it."

Remember NIST, the non-regulatory agency of the U.S. Department of Commerce? Their mission expanded over the years to protecting businesses from cyberthreats, including a "Cybersecurty Framework" first published in 2014. "The original goal was to develop a voluntary framework to help organizations manage cybersecurity risk in the nation's critical infrastructure, such as bridges and the electric power grid," NIST wrote in January, "but the framework has been widely adopted by many types of organizations across the country and around the world." Now SC Media reports: The second draft of the update to the National Institute of Standards and Technology's cybersecurity framework, NIST 1.1, is meant "to clarify, refine, and enhance the Cybersecurity Framework, amplifying its value and making it easier to use," according to NIST. Specifically, it brings clarity to cybersecurity measurement language and tackles improving security of the supply chain. Calling the initial NIST CSF "a landmark effort" that delivered "important benefits, such as providing common language for different models" of standards and best practices already in use, Larry Clinton, president and CEO of the Internet Security Alliance, said "it fell short of some of the most critical demands of Presidential Executive Order 13636, which generated its development...

"To begin with, the new draft makes it clear that our goal is not some undefined metric for use of the Framework, but for effective use of the Framework. Moreover, this use-metric needs to be tied not to some generic standard, but to be calibrated to the unique threat picture, risk appetite and business objective of a particular organization"... Clinton praised the process used by NIST as "a model 'use case' for how government needs to engage with its industry partners to address the cybersecurity issue." The internet's inherent interconnectedness makes it impossible for sustainable security to be achieved through anything other than true partnership, he contended.
Slashdot reader Presto Vivace reminds you that public comments on the draft Framework and Roadmap are due to NIST by 11:59 p.m. EST on January 19, 2018. "If you have an opinion about this, NOW is the time to express it."

"The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016," reports BleepingComputer. An anonymous reader writes: The issue at hand is in how some .NET libraries deserialize JSON or XML data, doing it in a total unsecured way, but also how developers handle deserialization operations when working with libraries that offer optional secure systems to prevent deserialized data from accessing and running certain methods automatically. The issue is similar to a flaw known as Mad Gadget (or Java Apocalypse) that came to light in 2015 and 2016. The flaw rocked the Java ecosystem in 2016, as it affected the Java Commons Collection and 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products. The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Now a similar issue was discovered in .NET. This research has been presented at the Black Hat and DEF CON security conferences. On page 5 [of this PDF], researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

"The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016," reports BleepingComputer. An anonymous reader writes: The issue at hand is in how some .NET libraries deserialize JSON or XML data, doing it in a total unsecured way, but also how developers handle deserialization operations when working with libraries that offer optional secure systems to prevent deserialized data from accessing and running certain methods automatically. The issue is similar to a flaw known as Mad Gadget (or Java Apocalypse) that came to light in 2015 and 2016. The flaw rocked the Java ecosystem in 2016, as it affected the Java Commons Collection and 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products. The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Now a similar issue was discovered in .NET. This research has been presented at the Black Hat and DEF CON security conferences. On page 5 [of this PDF], researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

"The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016," reports BleepingComputer. An anonymous reader writes: The issue at hand is in how some .NET libraries deserialize JSON or XML data, doing it in a total unsecured way, but also how developers handle deserialization operations when working with libraries that offer optional secure systems to prevent deserialized data from accessing and running certain methods automatically. The issue is similar to a flaw known as Mad Gadget (or Java Apocalypse) that came to light in 2015 and 2016. The flaw rocked the Java ecosystem in 2016, as it affected the Java Commons Collection and 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products. The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Now a similar issue was discovered in .NET. This research has been presented at the Black Hat and DEF CON security conferences. On page 5 [of this PDF], researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

"The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016," reports BleepingComputer. An anonymous reader writes: The issue at hand is in how some .NET libraries deserialize JSON or XML data, doing it in a total unsecured way, but also how developers handle deserialization operations when working with libraries that offer optional secure systems to prevent deserialized data from accessing and running certain methods automatically. The issue is similar to a flaw known as Mad Gadget (or Java Apocalypse) that came to light in 2015 and 2016. The flaw rocked the Java ecosystem in 2016, as it affected the Java Commons Collection and 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products. The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Now a similar issue was discovered in .NET. This research has been presented at the Black Hat and DEF CON security conferences. On page 5 [of this PDF], researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

"The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016," reports BleepingComputer. An anonymous reader writes: The issue at hand is in how some .NET libraries deserialize JSON or XML data, doing it in a total unsecured way, but also how developers handle deserialization operations when working with libraries that offer optional secure systems to prevent deserialized data from accessing and running certain methods automatically. The issue is similar to a flaw known as Mad Gadget (or Java Apocalypse) that came to light in 2015 and 2016. The flaw rocked the Java ecosystem in 2016, as it affected the Java Commons Collection and 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products. The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Now a similar issue was discovered in .NET. This research has been presented at the Black Hat and DEF CON security conferences. On page 5 [of this PDF], researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

"The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016," reports BleepingComputer. An anonymous reader writes: The issue at hand is in how some .NET libraries deserialize JSON or XML data, doing it in a total unsecured way, but also how developers handle deserialization operations when working with libraries that offer optional secure systems to prevent deserialized data from accessing and running certain methods automatically. The issue is similar to a flaw known as Mad Gadget (or Java Apocalypse) that came to light in 2015 and 2016. The flaw rocked the Java ecosystem in 2016, as it affected the Java Commons Collection and 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products. The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Now a similar issue was discovered in .NET. This research has been presented at the Black Hat and DEF CON security conferences. On page 5 [of this PDF], researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

"The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016," reports BleepingComputer. An anonymous reader writes: The issue at hand is in how some .NET libraries deserialize JSON or XML data, doing it in a total unsecured way, but also how developers handle deserialization operations when working with libraries that offer optional secure systems to prevent deserialized data from accessing and running certain methods automatically. The issue is similar to a flaw known as Mad Gadget (or Java Apocalypse) that came to light in 2015 and 2016. The flaw rocked the Java ecosystem in 2016, as it affected the Java Commons Collection and 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products. The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Now a similar issue was discovered in .NET. This research has been presented at the Black Hat and DEF CON security conferences. On page 5 [of this PDF], researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

"The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016," reports BleepingComputer. An anonymous reader writes: The issue at hand is in how some .NET libraries deserialize JSON or XML data, doing it in a total unsecured way, but also how developers handle deserialization operations when working with libraries that offer optional secure systems to prevent deserialized data from accessing and running certain methods automatically. The issue is similar to a flaw known as Mad Gadget (or Java Apocalypse) that came to light in 2015 and 2016. The flaw rocked the Java ecosystem in 2016, as it affected the Java Commons Collection and 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products. The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Now a similar issue was discovered in .NET. This research has been presented at the Black Hat and DEF CON security conferences. On page 5 [of this PDF], researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

chicksdaddy quotes a report from The Security Ledger: With functional, quantum computers on the (distant?) horizon, The National Institute of Standards and Technology (NIST) is asking the public for help heading off what it calls "a looming threat to information security:" powerful quantum computers capable of breaking even the strongest encryption codes used to protect the privacy of digital information. In a statement Tuesday, NIST asked the public to submit ideas for "post-quantum cryptography" algorithms that will be "less susceptible to a quantum computer's attack." NIST formally announced its quest in a publication on The Federal Register. Dustin Moody, a mathematician at NIST said the Institute's main focus is developing new public key cryptography algorithms, which are used today to protect both stored and transmitted information. "We're looking to replace three NIST cryptographic standards and guidelines that would be the most vulnerable to quantum computers," Moody said. They are FIPS 186-4, NIST SP 800-56A and NIST SP 800-56B. Researchers have until November, 2017 to submit their ideas. After the deadline, NIST will review the submissions. Proposals that meet the "post-quantum crypto" standards set up by NIST will be invited to present their algorithms at an open workshop in early 2018.

chicksdaddy quotes a report from The Security Ledger: With functional, quantum computers on the (distant?) horizon, The National Institute of Standards and Technology (NIST) is asking the public for help heading off what it calls "a looming threat to information security:" powerful quantum computers capable of breaking even the strongest encryption codes used to protect the privacy of digital information. In a statement Tuesday, NIST asked the public to submit ideas for "post-quantum cryptography" algorithms that will be "less susceptible to a quantum computer's attack." NIST formally announced its quest in a publication on The Federal Register. Dustin Moody, a mathematician at NIST said the Institute's main focus is developing new public key cryptography algorithms, which are used today to protect both stored and transmitted information. "We're looking to replace three NIST cryptographic standards and guidelines that would be the most vulnerable to quantum computers," Moody said. They are FIPS 186-4, NIST SP 800-56A and NIST SP 800-56B. Researchers have until November, 2017 to submit their ideas. After the deadline, NIST will review the submissions. Proposals that meet the "post-quantum crypto" standards set up by NIST will be invited to present their algorithms at an open workshop in early 2018.

chicksdaddy quotes a report from The Security Ledger: With functional, quantum computers on the (distant?) horizon, The National Institute of Standards and Technology (NIST) is asking the public for help heading off what it calls "a looming threat to information security:" powerful quantum computers capable of breaking even the strongest encryption codes used to protect the privacy of digital information. In a statement Tuesday, NIST asked the public to submit ideas for "post-quantum cryptography" algorithms that will be "less susceptible to a quantum computer's attack." NIST formally announced its quest in a publication on The Federal Register. Dustin Moody, a mathematician at NIST said the Institute's main focus is developing new public key cryptography algorithms, which are used today to protect both stored and transmitted information. "We're looking to replace three NIST cryptographic standards and guidelines that would be the most vulnerable to quantum computers," Moody said. They are FIPS 186-4, NIST SP 800-56A and NIST SP 800-56B. Researchers have until November, 2017 to submit their ideas. After the deadline, NIST will review the submissions. Proposals that meet the "post-quantum crypto" standards set up by NIST will be invited to present their algorithms at an open workshop in early 2018.

chicksdaddy quotes a report from The Security Ledger: With functional, quantum computers on the (distant?) horizon, The National Institute of Standards and Technology (NIST) is asking the public for help heading off what it calls "a looming threat to information security:" powerful quantum computers capable of breaking even the strongest encryption codes used to protect the privacy of digital information. In a statement Tuesday, NIST asked the public to submit ideas for "post-quantum cryptography" algorithms that will be "less susceptible to a quantum computer's attack." NIST formally announced its quest in a publication on The Federal Register. Dustin Moody, a mathematician at NIST said the Institute's main focus is developing new public key cryptography algorithms, which are used today to protect both stored and transmitted information. "We're looking to replace three NIST cryptographic standards and guidelines that would be the most vulnerable to quantum computers," Moody said. They are FIPS 186-4, NIST SP 800-56A and NIST SP 800-56B. Researchers have until November, 2017 to submit their ideas. After the deadline, NIST will review the submissions. Proposals that meet the "post-quantum crypto" standards set up by NIST will be invited to present their algorithms at an open workshop in early 2018.

chicksdaddy quotes a report from The Security Ledger: With functional, quantum computers on the (distant?) horizon, The National Institute of Standards and Technology (NIST) is asking the public for help heading off what it calls "a looming threat to information security:" powerful quantum computers capable of breaking even the strongest encryption codes used to protect the privacy of digital information. In a statement Tuesday, NIST asked the public to submit ideas for "post-quantum cryptography" algorithms that will be "less susceptible to a quantum computer's attack." NIST formally announced its quest in a publication on The Federal Register. Dustin Moody, a mathematician at NIST said the Institute's main focus is developing new public key cryptography algorithms, which are used today to protect both stored and transmitted information. "We're looking to replace three NIST cryptographic standards and guidelines that would be the most vulnerable to quantum computers," Moody said. They are FIPS 186-4, NIST SP 800-56A and NIST SP 800-56B. Researchers have until November, 2017 to submit their ideas. After the deadline, NIST will review the submissions. Proposals that meet the "post-quantum crypto" standards set up by NIST will be invited to present their algorithms at an open workshop in early 2018.

An anonymous Slashdot reader writes: The National Institute of Standards and Technology has its own "Commission on Enhancing National Cybersecurity," and this week they issued a call for public comments on "current and future challenges" involving critical infrastructure cybersecurity, the concept of cybersecurity insurance, public awareness, and the internet of things (among other topics) for both the private and public sector.
Long-time Slashdot reader Presto Vivace quotes The Hill: it is specifically asking for projections on policies, economic incentives, emerging technologies, useful metrics and other current and potential solutions throughout the next decade... Comments will be due by 5 p.m. on September 9.
Internet services "have come under attack in recent years in the form of identity and intellectual property theft, deliberate and unintentional service disruption, and stolen data," writes NIST. "Steps must be taken to enhance existing efforts to increase the protection and resilience of the digital ecosystem, while maintaining a cyber environment that encourages efficiency, innovation, and economic prosperity."

Separately, NIST is also requesting comments on a new process to "solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms... If large-scale quantum computers are ever built, they will be able to break many of the public-key cryptosystems currently in use. This would seriously compromise the confidentiality and integrity of digital communications on the Internet and elsewhere... NIST plans to specify preliminary evaluation criteria for quantum-resistant public key cryptography standards."

An anonymous reader writes: "The U.S. National Institute for Standards and Technology (NIST) has released the latest draft version of the Digital Authentication Guideline that contains language hinting at a future ban of SMS-based Two-Factor Authentication (2FA)," reports Softpedia. The NIST DAG draft argues that SMS-based two-factor authentication is an insecure process because the phone may not always be in possession of the phone number, and because in the case of VoIP connections, SMS messages may be intercepted and not delivered to the phone. The guideline recommends the usage of tokens and software cryptographic authenticators instead. Even biometrics authentication is considered safe, under one condition: "Biometrics SHALL be used with another authentication factor (something you know or something you have)," the guideline's draft reads. The NIST DAG draft reads in part: "If the out of band verification is to be made using a SMS message on a public mobile telephone network, the verifier SHALL verify that the pre-registered telephone number being used is actually associated with a mobile network and not with a VoIP (or other software-based) service. It then sends the SMS message to the pre-registered telephone number. Changing the pre-registered telephone number SHALL NOT be possible without two-factor authentication at the time of the change. OOB using SMS is deprecated, and will no longer be allowed in future releases of this guidance."

Tony Isaac writes: "Atomic" clocks that you can buy in stores synchronize time using the WWVB shortwave band from NIST in Boulder. The problem is, this signal is notoriously weak, making these clocks very sensitive to interference by other RF or electronic devices, or less-than-ideal reception conditions. In many locations, these clocks are never able to receive a time signal, making them no better at timekeeping than a cheap quartz clock. There are other ways to synchronize clock time: NTP over WiFi, GPS, or cellular. The cheapest clocks that use NTP over Wi-Fi cost around $400. Really? And while there are plenty of GPS-enabled smartwatches in the $100 price range, there don't seem to be any similar wall clocks. Are there any reasonably-priced wall clock alternatives, that use something other than shortwave to set the time?

An anonymous reader writes: Encryption weighs heavily on the public consciousness these days, as we've learned that government agencies are keeping an eye on us and a lot of our security tools aren't as foolproof as we've thought. In response to this, the National Institute of Standards and Technology has issued a formal update to its document on how to properly generate a random number — crucial in many types of encryption. The update (as expected) removes a recommendation for the Dual_EC_DRBG algorithm. It also adds extra options for CTR_DRBG and points out examples for implementing SP 800-90A generators. The full document (PDF) is available online.

chicksdaddy writes: Security Ledger reports on a recent NIST workshop dedicated to improving the art of automated tattoo identification. It used to be that the only place you'd commonly see tattoos was at your local VA hospital. No more. In the last 30 years, body art has gone mainstream. One in five adults in the U.S. has one. For law enforcement and forensics experts, this is a good thing; tattoos are a great way to identify both perpetrators and their victims. Given the number and variety of tattoos, though, how to describe and catalog them? Clearly this is an area where technology can help, but it's also one of those "fuzzy" problems that challenges the limits of artificial intelligence.

The National Institute of Standards and Technology (NIST) Tattoo Recognition Technology Challenge Workshop challenged industry and academia to work towards developing an automated image-based tattoo matching technology. Participating organizations in the challenge used a FBI -supplied dataset of thousands of images of tattoos from government databases. They were challenged to develop methods for identifying a tattoo in an image, identifying visually similar or related tattoos from different subjects; identifying the same tattoo image from the same subject over time; identifying a small region of interest that is contained in a larger image; and identifying a tattoo from a visually similar image like a sketch or scanned print.

chicksdaddy writes: This is a bad month for the medical equipment maker Hospira. First, security researcher Billy Rios finds a raft of serious and remotely exploitable holes in the company's MedNet software, prompting a vulnerability alert from ICS CERT. Now, one month later, ICS CERT is again warning of a "10 out of 10" critical vulnerability, this time in Hospira's LifeCare PCA drug infusion pump. The problem? According to this report by Security Ledger the main problem was an almost total lack of security controls on the device. According to independent researcher Jeremy Williams, the PCA pump listens on Telnet port 23. Connecting to the device via Telnet, he was brought immediately to a root shell account that gave him total, administrator level access to the pump without authentication. "The only thing I needed to get in was an interest in the pump," he said. Richards found other examples of loose security on the PCA 3: a FTP server that could be accessed without authentication and an embedded web server that runs Common Gateway Interface (CGI). That could allow an attacker to tamper with the pump's operation using fairly simple scripts. Also: The PCA pump stores wireless keys used to connect to the local (medical device) wireless network in plain text on the device. That means anyone with physical access to the Pump (which has an ethernet port) could gain access to the local medical device network and other devices on it. The problems prompted Richards to call the PCA 3 pump "the least secure IP enabled device" he has ever worked with.

First time accepted submitter Jim Fenton writes The National Institute of Standards and Technology (NIST) is poised to make what is expected to be a major revision of Special Publication 800-63-2, Electronic Authentication Guideline. While normative only for the Federal Government, it is widely referenced elsewhere and specifies requirements to meet each of four Levels of Assurance (LOA). Should this structure change? Are there changes in technology or threats that should be considered in the revision? NIST would like to hear from you.

First time accepted submitter Jim Fenton writes The National Institute of Standards and Technology (NIST) is poised to make what is expected to be a major revision of Special Publication 800-63-2, Electronic Authentication Guideline. While normative only for the Federal Government, it is widely referenced elsewhere and specifies requirements to meet each of four Levels of Assurance (LOA). Should this structure change? Are there changes in technology or threats that should be considered in the revision? NIST would like to hear from you.

First time accepted submitter Jim Fenton writes The National Institute of Standards and Technology (NIST) is poised to make what is expected to be a major revision of Special Publication 800-63-2, Electronic Authentication Guideline. While normative only for the Federal Government, it is widely referenced elsewhere and specifies requirements to meet each of four Levels of Assurance (LOA). Should this structure change? Are there changes in technology or threats that should be considered in the revision? NIST would like to hear from you.

itwbennett writes: The vulnerability known as CVE-2011-2461 was unusual because fixing it didn't just require the Adobe Flex Software Development Kit (SDK) to be updated, but also patching all the individual Flash applications (SWF files) that had been created with vulnerable versions of the SDK. The company released a tool that allowed developers to easily fix existing SWF files, but many of them didn't. Last year, Web application security engineers Luca Carettoni from LinkedIn and Mauro Gentile from Minded Security came across the old flaw while investigating Flash-based techniques for bypassing the Same-Origin Policy (SOP) mechanism found in browsers. They found SWF files that were still vulnerable on Google, Yahoo, Salesforce, Adobe, Yandex, Qiwi and many other sites. After notifying the affected websites, they presented their findings last week at the Troopers 2015 security conference in Germany.

An anonymous reader writes: Current standards of network timekeeping are inadequate to some of the critical systems that are being envisaged for the Internet of Things, according to a report (PDF) by the National Institute of Standards and Technology (NIST). The report says, "A new economy built on the massive growth of endpoints on the internet will require precise and verifiable timing in ways that current systems do not support. Applications, computers, and communications systems have been developed with modules and layers that optimize data processing but degrade accurate timing." NIST's Chad Boutin likens current network accuracy to an attempt to synchronize watches via the postal system, and suggests that remote medicine and self-driving cars will need far higher standards in order not to put lives at risk. He says, "modern computer programs only have probabilities on execution times, rather than the strong certainties that safety-critical systems require."

chicksdaddy writes Criminals beware: researchers at the National Institute of Standards and Technology (NIST) have figured out how to recover serial numbers obliterated from metal surfaces such as firearms and automobiles — a common problem in forensic examinations. According to this report, NIST researchers used a technique called electron backscatter diffraction (EBSD) to read, in the crystal structure pattern, imprints on steel that had been removed by polishing. ... The more perfect the crystal structure, the stronger and clearer the pattern. Software can then calculate the pattern quality to reveal crystal damage; areas with more damage produce lower quality patterns. In the NIST experiments, described in Forensic Science International, researchers hammered the letter 'X' into a polished stainless steel plate. The letter stamps were as deep as 140 micrometers, meeting federal regulations for firearm serial numbers. The researchers then polished the metal again to remove all visible traces of the letters, and collected the EBSD diffraction patterns and pattern quality data and analyzed them for evidence of the imprints.

New submitter steve_torquay writes: Last week, President Obama signed a new Executive Order calling for "all agencies making personal data accessible to citizens through digital applications" to "require the use of multiple factors of authentication and an effective identity proofing process." This does not necessarily imply that the government will issue online credentials to all U.S. residents.

The National Strategy for Trusted Identities in Cyberspace (NSTIC) is working towards a distributed identity ecosystem that facilitates authentication and authorization without compromising privacy. NSTIC points out that this is a great opportunity to leverage the technology to enable a wide array of new citizen-facing digital services while reducing costs and hassles for individuals and government agencies alike.

The recently disclosed bug in bash was bad enough as a theoretical exploit; now, reports Ars Technica, it could already be being used to launch real attacks. In a blog post yesterday, Robert Graham of Errata Security noted that someone is already using a massive Internet scan to locate vulnerable servers for attack. In a brief scan, he found over 3,000 servers that were vulnerable "just on port 80"—the Internet Protocol port used for normal Web Hypertext Transfer Protocol (HTTP) requests. And his scan broke after a short period, meaning that there could be vast numbers of other servers vulnerable. A Google search by Ars using advanced search parameters yielded over two billion web pages that at least partially fit the profile for the Shellshock exploit. More bad news: "[T]he initial fix for the issue still left Bash vulnerable to attack, according to a new US CERT National Vulnerability Database entry." And CNET is not the only one to say that Shellshock, which can affect Macs running OS X as well as Linux and Unix systems, could be worse than Heartbleed.

hypnosec writes: "National Institute of Standards and Technology (NIST) has removed the much-criticized Dual_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) from its draft guidance on random number generators following a period of public comment and review. The revised document retains three of the four previously available options for generating pseudorandom bits required to create secure cryptographic keys for encrypting data. NIST recommends that people using Dual_EC_DRBG should transition to one of the other three recommended algorithms as quickly as possible."

thomst writes "Kim Zetter of Wired's Threat Level reports that Kaspersky Labs discovered a Spanish-language spyware application that 'uses techniques and code that surpass any nation-state spyware previously spotted in the wild.' The malware, dubbed 'The Mask' by Kaspersky's researchers, targeted government agencies, diplomatic offices, embassies, companies in the oil, gas and energy industries, research organizations, and activists. It had been loose on the Internet since at least 2007 before being shut down last month. It infected its targets via a malicious website that contained exploits — among which were the Adobe Flash player vulnerability CVE-2012-0773, affecting both Windows and Linux machines. Users were directed to the site via spearphishing emails."

An anonymous reader writes "In the process of standardizing the SHA-3 competition winning algorithm Keccak, the National Institute of Standards and Technology (NIST) may have lowered the bar for attacks, which might be useful for or even initiated by NSA. 'NIST is proposing a huge reduction in the internal strength of Keccak below what went into final SHA-3 comp,' writes cryptographer Marsh Ray on Twitter. In August, John Kelsey, working at NIST, described (slides 44-48) the changes to the algorithm, including reduction of the bit length from 224, 256, 384 and 512-bit modes down to 128 and 256-bit modes."

IamTheRealMike writes "In the wake of Bruce Schneier's statements that he no longer trusts the constants selected for elliptic curve cryptography, people have started trying to reproduce the process that led to those constants being selected ... and found it cannot be done. As background, the most basic standard elliptic curves used for digital signatures and other cryptography are called the SEC random curves (SEC is 'Standards for Efficient Cryptography'), a good example being secp256r1. The random numbers in these curve parameters were supposed to be selected via a "verifiably random" process (output of SHA1 on some seed), which is a reasonable way to obtain a nothing up my sleeve number if the input to the hash function is trustworthy, like a small counter or the digits of PI. Unfortunately it turns out the actual inputs used were opaque 256 bit numbers, chosen ad-hoc with no justifications provided. Worse, the curve parameters for SEC were generated by head of elliptic curve research at the NSA — opening the possibility that they were found via a brute force search for a publicly unknown class of weak curves. Although no attack against the selected values are currently known, it's common practice to never use unexplainable magic numbers in cryptography standards, especially when those numbers are being chosen by intelligence agencies. Now that the world received strong confirmation that the much more obscure and less widely used standard Dual_EC_DRBG was in fact an NSA undercover operation, NIST re-opened the confirmed-bad standards for public comment. Unless NIST/the NSA can explain why the random curve seed values are trustworthy, it might be time to re-evaluate all NIST based elliptic curve crypto in general."

benrothke writes "It has been about 8 years since my friend Richard Bejtlich's (note, that was a full disclosure 'my friend') last book Extrusion Detection: Security Monitoring for Internal Intrusions came out. That and his other 2 books were heavy on technical analysis and real-word solutions. Some titles only start to cover ground after about 80 pages of introduction. With this highly informative and actionable book, you are already reviewing tcpdump output at page 16. In The Practice of Network Security Monitoring: Understanding Incident Detection and Response, Bejtlich takes the approach that your network will be attacked and breached. He observes that a critical part of your security posture must be that of network security monitoring (NSM), which is the collection and analysis of data to help you detect and respond to intrusions." Read below for the rest of Ben's review. The Practice of Network Security Monitoring: Understanding Incident Detection and Response author Richard Bejtlich pages 376 publisher No Starch Press rating 9/10 reviewer Ben Rothke ISBN 978-1593275099 summary Definitive guide to the new world of Network Security Monitoring (NSM) In this book, Bejtlich details how to design a NSM program from the initiation state. Being a big open source proponent, the book lists no proprietary tools and myriad open source solutions. The book is designed for system and security administrators, CIRT managers and analysts with a strong background in understanding threats, vulnerabilities and security log interpretation.

The book is about the inevitable, that attackers will get inside your network. While it's foreseeable they will get in, it's not inevitable that you have to be caught off-guard. For those who are serious about securing their network, this is an invaluable book that provides a unique and very workable model to create a fully-functioning NSM infrastructure.

The book is a hands-on guide to installing and configuring NSM tools. The reader who is comfortable using tools such as Wireshark, Nmap and the like will be quite at home here.

This is a book about how not to be surprised and its 13 chapters detail how to create and manage a NSM program, what to look for, and details myriad tools to use in the process.

The focus of the book is not on the planning and defense phases of the security cycle, hopefully, that is already in place in your organization, rather on the actions to take when handling systems that are already compromised or that are on the verge of being compromised, as detailed in the preface.

In chapter 1, the book details the difference between continuous monitoring(CM) and NSM; since their terms are similar and many people confuse the two. CM is big in the federal computing space and NIST provides an overview and definition of it here. The book notes that CM has almost nothing to do with NSM or even with trying to detect and respond to intrusions. NSM is threat-centric, meaning adversaries are the discussion of the NSM operation; while CM is vulnerability-centric; focusing on configuration and software weaknesses.

Also in chapter 1, Bejtlich asks the important question: is NSM legal? He writes that there is no easy answer to that questions and anyone using or deploying an NSM solution should first consult with their legal counsel; in order not to potentially violate the US Wiretap Act and other laws and regulations. This is especially true for those who are in European Union (EU) countries, as the EU places a high threshold on information security teams who want to monitor network traffic. Something as simple as running Wireshark on a corporate network in the US, would require court approval if done on an EU-based network.

One of the main NSM tools the book references and details is Security Onion (SO). SO is a Linux distro for IDS and NSM. Its based on Ubuntu and the distro contains Snort, Suricata, Bro, Sguil, Squert, Snorby, ELSA, Xplico, NetworkMiner and many other useful security tools.

The book details and explains how use these tools in an NSM environment. An important point Bejtlich makes in chapter 9 regarding the tools, is that analysts need tools to find intruders. But methodology is more important than just software tools. Tools collect and interpret data, but methodology provides the conceptual model. He explains that CIRT analysts must understand how to use tools to achieve a particular goal, but it is imperative and important to start with a good operational model first, and then select tools to provide data supporting that model.

The book has a short discussion of how cloud computing effects NSM. In a nutshell, the cloud throws a monkey wrench into an NSM effort. For example, it is generally not an option for SaaS offerings since customers are limited to the back-end logs.

The book closes with the observation that NSM is not just about all the tools that the author spent over 300 pages discussing, rather it is more about the workflows, metrics and collaboration. Unfortunately, this title does not detail the necessary workflows for a NSM and it is hoped that the follow-up to this book will.

The only negative in the book is that as CSO of Mandiant, Bejtlich references his firm's products, mainly their MIR appliance for a CIRT. In the spirit of objectivity and not trying to have the book come across as marketing PR, if an author is going to mention a product their firm sells, they should also mention alternative solutions.

For those looking for a comprehensive guide on the topic of NSM, written by one of the experts in the field, The Practice of Network Security Monitoring: Understanding Incident Detection and Responseis an excellent reference that is certain to make the reader a better information security practitioner, and their network more secure.

Reviewed by Ben Rothke.

You can purchase The Practice of Network Security Monitoring: Understanding Incident Detection & Response from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

New submitter bryanandaimee writes "An optical lattice clock like the one discussed earlier on Slashdot has broken the stability record. Comparing two OLC's using trapped atoms of Ytterbium, the stability of the clocks was measured to 2 parts per quintillion (10^18). While the previously reported OLC used strontium, these clocks, built by another group, use Ytterbium. Interestingly, while the stability of the clocks is now the best in the world, the accuracy has yet to be measured."

Trailrunner7 writes "Developers who have not updated their Ruby on Rails installations with a five-month-old security patch would do well to secure the Web development framework now. Exploit code has surfaced for CVE-2013-0156 that is being used to build a botnet of compromised servers. Exploit code has been publicly available since the vulnerability was disclosed in January on Github and Metasploit, yet the vulnerability had not been exploited on a large scale until now, said security researcher Jeff Jarmoc." One reason your web server firewall might want to block IRC connections to arbitrary hosts.

wiredmikey writes "Google on Tuesday announced that it now fully supports DNSSEC (Domain Name System Security Extensions) validation on its Google Public DNS resolvers. Previously, the search giant accepted and forwarded DNSSEC-formatted messages but didn't actually perform validation. 'With this new security feature, we can better protect people from DNS-based attacks and make DNS more secure overall by identifying and rejecting invalid responses from DNSSEC-protected domains,' Yunhong Gu, Team Lead, Google Public DNS, wrote in a blog post. According to Gu, about 1/3 of top-level domains have been signed, but most second-level domains remain unsigned. According to NIST, there has been no progress in enabling DNSSEC on 98 percent of all 1,070 industry domains tested as of March 18, 2013. 'Overall, DNSSEC is still at an early stage and we hope that our support will help expedite its deployment,' Gu said."

hypnosec writes "The US government's National Vulnerability Database (NVD) maintained by National Institute of Standards and Technology (NIST) has been offline for a few days because of malware infestation. The public-facing site has been taken offline because traces of malware were found on two of the web servers that house it. A post on Google+ containing an email from Gail Porter details the discovery of suspicious activity and subsequent steps taken by NIST. As of this writing the NVD website is still serving a page not found message."

An anonymous reader writes "The National Institute of Standards and Technology (NIST) has just announced the winner of the SHA-3 competition: Keccak, created by Guido Bertoni, Joan Daemen and Gilles Van Assche of STMicroelectronics and Michaël Peeters of NXP Semiconductors. 'Keccak has the added advantage of not being vulnerable in the same ways SHA-2 might be,' says NIST computer security expert Tim Polk. 'An attack that could work on SHA-2 most likely would not work on Keccak because the two algorithms are designed so differently.' For Joan Daemen it must be a 'two in a row' feeling, since he also is one of the authors of AES."

Trailrunner7 writes with this excerpt from Threatpost: "For the last five years, NIST, the government body charged with developing new standards for computer security, among other things, has been searching for a new hash function to replace the aging SHA-2 function. Five years is a long time, but this is the federal government and things move at their own pace in Washington, but NIST soon will be announcing the winner from the five finalists that were chosen last year. Despite the problems that have cropped up with some versions of SHA-2 in the past and the long wait for the new function, there doesn't seem to be much in the way of breathless anticipation for this announcement. So much so, in fact, that Bruce Schneier, a co-author of one of the finalists not only isn't hoping that his entry wins, he's hoping that none of them wins. ... It's not because Schneier doesn't think the finalists are worthy of winning. In fact, he says, they're all good and fast and perfectly capable. The problem is, he doesn't think that the world needs a new hash function standard at all. SHA-512, the stronger version of the SHA-2 function that's been in use for more than a decade, is still holding up fine, Schneier said, which was not what cryptographers anticipated would be the case when the SHA-3 competition was conceived. 'I expect SHA-2 to be still acceptable for the foreseeable future. That's the problem. It's not like AES. Everyone knew that DES was dead — and triple-DES was too slow and clunky — and we needed something new. So when AES appeared, people switched as soon as they could. This will be different,' Schneier said via email."

MrSeb writes "The U.S. Federal Bureau of Investigation has begun rolling out its new $1 billion biometric Next Generation Identification (NGI) system. In essence, NGI is a nationwide database of mugshots, iris scans, DNA records, voice samples, and other biometrics that will help the FBI identify and catch criminals — but it is how this biometric data is captured, through a nationwide network of cameras and photo databases, that is raising the eyebrows of privacy advocates. Until now, the FBI relied on IAFIS, a national fingerprint database that has long been due an overhaul. Over the last few months, the FBI has been pilot testing a face recognition system, which will soon be scaled up (PDF) until it's nationwide. In theory, this should result in much faster positive identifications of criminals and fewer unsolved cases. The problem is, the FBI hasn't guaranteed that the NGI will only use photos of known criminals. There may come a time when the NGI is filled with as many photos as possible, from as many sources as possible, of as many people as possible — criminal or otherwise. Imagine if the NGI had full access to every driving license and passport photo in the country — and DNA records kept by doctors, and iris scans kept by businesses. The FBI's NGI, if the right checks and balances aren't in place, could very easily become a tool that decimates civilian privacy and freedom."

hypnosec writes "The U.S.'s National Institute of Standards and Technology has come up with a set of proposed guidelines for security of server BIOSes— the mechanism on which most modern day computers rely during boot up. Recently quite a few instances of malware have been known to persistently infect computer systems, and cannot be removed even on OS re-installs. NIST is proposing a set of measures through which the BIOS can be made more secure and resistant to such firmware manipulating attacks. Mebromi is one such Trojan. NIST published the draft guidelines [PDF] earlier this week and has proposed four different features through which the server BIOSes can be made more secure: authenticated update mechanism; secure local update mechanism (optional); firmware integrity protections; and non-bypassability features."

An anonymous reader writes "Thanks to advances in experimental design, physicists at the National Institute of Standards and Technology have achieved a record-low probability of error in quantum information processing with a single quantum bit (qubit) — the first published error rate small enough to meet theoretical requirements for building viable quantum computers. 'One error per 10,000 logic operations is a commonly agreed upon target for a low enough error rate to use error correction protocols in a quantum computer,' said Kenton Brown, who led the project as a NIST postdoctoral researcher. 'It is generally accepted that if error rates are above that, you will introduce more errors in your correction operations than you are able to correct. We've been able to show that we have good enough control over our single-qubit operations that our probability of error is 1 per 50,000 logic operations.'"