Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-0324PUBLISHED: 2021-06-14Product: AndroidVersions: Android SoCAndroid ID: A-175402462
CVE-2021-0467PUBLISHED: 2021-06-14
In Chromecast bootROM, there is a possible out of bounds write due to an incorrect bounds check. This could lead to local escalation of privilege in the bootloader, with physical USB access, with no additional execution privileges needed. User interaction is not needed for exploitation.Product: Andr...
CVE-2021-21554PUBLISHED: 2021-06-14
Dell PowerEdge R640, R740, R740XD, R840, R940, R940xa, MX740c, MX840c, and, Dell Precision 7920 Rack Workstation BIOS contain a stack-based buffer overflow vulnerability in systems with Intel Optane DC Persistent Memory installed. A local malicious user with high privileges may potentially exploit t...
CVE-2021-21555PUBLISHED: 2021-06-14
Dell PowerEdge R640, R740, R740XD, R840, R940, R940xa, MX740c, MX840c, and T640 Server BIOS contain a heap-based buffer overflow vulnerability in systems with NVDIMM-N installed. A local malicious user with high privileges may potentially exploit this vulnerability, leading to a denial of Service, a...
CVE-2021-21556PUBLISHED: 2021-06-14
Dell PowerEdge R640, R740, R740XD, R840, R940, R940xa, MX740c, MX840c, and T640 Server BIOS contain a stack-based buffer overflow vulnerability in systems with NVDIMM-N installed. A local malicious user with high privileges may potentially exploit this vulnerability, leading to a denial of Service, ...
Latest Comment: Told them I could code blinfolded. They looked at each other and laughed ... I laughed ... Who knew?
The State of Cybersecurity Incident ResponseIn this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Tweet This
0 Comments
User Rank: Ninja
7/28/2018 | 12:48:44 PM
Passwords - The Necessary Evil of Authentication
• Passwords are an individuals first and most prevalent interaction with security
• Negative impressions tend to stay with individuals
• Passwords remain viable due to their ability to be changed, no need for extra technology, and ease of use
• Biometrics suffer from lack of changeability
• Token based solutions require user to have something with them at all times
• Security professionals have created negative view and challenges associated with passwords
• Focused on impressions of threats instead of research supported evidence
• Implemented irrational complexity rules and requirements
• LophtCrack created password anxiety in late 1990's that still persists today
I'd note that in the article on which we're commenting, some of the same negative impressions are cited, such as: "The situation is equally depressing around the issue of password change." I think that's, to some extent, perpetuating some misconceptions, or outdated assumptions, about best practices concerning passwords; namely that periodic change of passwords provides important security benefits.
Most are aware of the downsides of frequent PW change, most notably that users are confronted with new generated passwords, or they are forced to create something new and memorable; and not just any password, but a "strong" password - that strength metric based largely on complexity - which makes creation more burdensome, and remembering more of a challenge. An almost inevitable side effect (ought to be put on the warning label), of burdening users with this standard password vulnerability Rx, is to promote the far greater predisposition is password reuse. So, the cure ends up doing more harm than the disease!
Is frequent PW change a cure for what ails you (security-wise)? Probably not; not when a strong attack can leverage the cracking power available today. Will you force users to accept or create new strong passwords every day, every hour? Even that won't be frequent enough in all cases.
Also, does a password's strength reside in complexity (mix of different alphanumeric character types)? I've seen studies where the principal protection resides in password length. Anyone around long enough to remember when PW length first was stipulated (even, when you couldn't enter more than 8 characters), saw these "minimums" go from 4 to 6, to 8 to ...; and most users would use exactly the minimum - which meant to crackers that they knew the probable length of the passwords they needed to crack!
Strength in numbers (number of characters in a PW), makes sense, as a variable (not all users will use the same large number), large number will drive up required processing power to crack, more than complexity. Never forget that password reuse can provide a kind of wormhole through the security-spacetime continuum, allowing attackers to arrive at their destination in the blink of an eye.
Adding in complexity helps; but not if that overburdens users, as will happen if you enforce frequent PW changing!
I recommend only enforcing PW change when there is evidence of a data breach (another kind of wormhole through for attackers). Lord help you if that happens every 30 days.
Use passphrases, rather than passwords. Phrases naturally tend to be longer than words, and more immune to dictionary-attacks; even ones factoring in the use of "$" for an "S", or "4" for (do I have to say it?). Phrases without spaces between words are even better (less vulnerable, as the start and end of component words are not delineated), and aren't harder to remember. Throw in some proper nouns, and you've really made things tough for crackers.
Will such passphrases be invulnerable to the most powerful attacks? No. No surprise there. But in targeting an organization with dozens, hundreds, thousands of users, who will ever be able to afford the resources to force all of them? That's just what many attacks do: look for the weakest links, the low hanging fruit, the chinks in the armor.... If all your links are pretty darn strong, fruit high up in the tree - and without wormholes! - you'll be a lot safer than by enforcing assumed "best practices" from yesteryear.