This may sound mysterious, but once you understand the threat model that they're talking about, it all makes sense.  The web page you link to is talking about preventing people from hacking your app to bypass the in-app billing.

Example: Let's suppose you've built a fun game that people can play, by installing your app on their Android phones.  You use in-app billing to let people buy cool items that make the game more fun: "The Sword of Truth", or something like that.  Of course, a hacker could always try to make a copy of your .apk and modify it to change your code so that they get The Sword of Truth, without having to pay you for it.  You might not be very happy about that.  What can you do to protect yourself against that threat?

Well, the Android security manual tells what you can do to make that kind of hacking harder and thus protect your revenue stream.  The important thing to understand is: there is no strong defense.  In this situation, a dedicated and motivated attacker will always win.  The most you can hope for is to introduce a speedbump, to make it slightly harder for someone to hack your game.  The hope is that this will be enough to reduce (but not eliminate) hacking, and thus protect your revenue stream about as well as is reasonably possible.  That's what the web page you linked to is trying to help you do.

The Android web page you linked to actually explains this pretty well.  You've quoted selectively from it, but if you keep reading the nearby sentences, there is a good explanation: it says "The [public] key itself is not secret information, but you do not want to make it easy for a hacker or malicious user to replace the public key with another key."  It's true that they didn't explain why you might care about that; hopefully my explanation has made this clearer.

Also, at the very top, the web page says, "If practical, you should perform signature verification on a remote server and not on a device. Implementing the verification process on a server makes it difficult for attackers to break the verification process by reverse engineering your .apk file."  In general, this is the only way you can reliably defend against hacks that reverse-engineer and modify your game.

For more on the general topic of preventing hackers from cheating in online games, I highly recommend the following article (it is readable, insightful, still relevant today, and just all-around fantastic):

"How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It".  Matthew Pritchard, Gamasutra, July 2000.


How to prevent unauthorized users from accessing an image on my server just by URL?

You have to work with that images the same as it should be for restricted content. There are two major points:

Protect access to the content (the images)
Protect content against brute force not to allow user guess about image path.

The both points could be covered with proxy request through php script.
The first point can be solved with authentication and protection content with a token and ACL (access control level). Make sure the images out of webserver visibility not to access image directly. It could be helpful to rename image after upload and save original name and new name in DB. In this case you can call it from app by original name and access it by new unique real name.


I've read this article a while ago (I think it's about 7 years old), and with all respect to Shreeraj Shah (the author) I completely disagree, and I extend my disagreement to most of his "security" methodology. Security by obscurity isn't the answer!

Here's something taken from the original (IN)SECURE article (page 25) explaining the benefit of this technique

  This fingerprinting technique helps in determining the type of client
  code that has sent this request. It is possible to lockdown resources
  for just the right client on the server-side as well. This type of
  header is harder to add by automated crawlers and bots since the logic
  and calls need to be understood first. Consequently, automated attacks
  on your Ajax resources can be avoided.

Mr. Shah is assuming that his method adds security because he's leveraging the attacker's ignorance of his request method.

My personal opinion is to treat this as false information, or outdated information at best.

Update:

Now that I think about it a bit more, I think I haven't targeted your exact question

  Are there any Benefits of Ajax Fingerprinting?

I don't see any security benefits for that at all. There might be some benefits regarding the usage of the application. One example would be a URL like this

example.com/article/124

You might wanna view the article when the page is visited normally and provide the information in JSON or XML if the same URL was requested with Ajax.


AWS S3 Server-side Encryption - Client Provided Keys PHP

As per official documentation there is three request header require for SSE with customer provided key:

x-amz-server-side-encryption-customer-algorithm : AES256
x-amz-server-side-encryption-customer-key : base64(secretkey)
x-amz-server-side-encryption-customer-key-MD5 : base64(md5(secret
key))

Please update code as per above

'SSECustomerAlgorithm' => 'AES256',
'SSECustomerKey'       => base64($somerandom32bitkey)
'SSECustomerKeyMD5     => md5(base64($somerandom32bitkey))

Hope this will help.


How does this simple buffer overflow work?

That's due to an alignment to 16 bytes, which compilers do on x86(_64) for compatibility with SIMD instructions that operate on 128 bits (16 bytes). Due to that there is some "padding" between the buffer and the saved registers, 12 bytes in your case.

Technically, you already overflow the buffer if you pass 500 A characters to the program because the string is null-terminated. But that zero byte only overwrites the first of the padding bytes. Between these padding bytes and the saved rip there is also the saved rbp (8 bytes). So the layout is basically like this (if canaries are in use - -fstack-protector - then the canary value is placed between the padding and saved registers):

buffer [500 bytes] | padding [12 bytes] | saved rbp [8 bytes] | saved rip [8 bytes]

So with 520 A characters you overwrite first the padding and the saved rbp before the first byte of the saved rip is overwritten with a zero byte.


You weren't the only one who noticed this message had malicious content: Office 365 noticed it, too:

To help protect your privacy, some content in this message has been blocked. To re-enable the blocked features, click here.
To always show content from this sender, click here.

Unless you enabled the harmful content or clicked any links on the email, you should be safe. If you clicked something, then it depends: this question doesn't have enough information  to say anything about the harmful content itself. However, you should not try and get this information by clicking anything.


Is a self-signed certificate from my ISP-provided router a security threat?

Not only is the certificate you show self-signed, but it's also a certificate authority, which means that it can issue more certificates for any website.

If you install that certificate into your browser as a trusted certificate authority, then yes, your ISP will be able to do the kind of MitM attacks that you're referencing.

I don't know whether simply clicking through the cert warning on that one page will install in, or simply ignore the warning for that one page. My guess is that if you click through this warning, this certificate will then show up in your browser's Trust Store of trusted Certificate Authorities, which would be bad.

I would be inclined to say that your ISP is not malicious, but rather they don't really understand how certificates work. If they were trying to MitM you, they would have persuaded you to install the cert when you first set up the router saying "The internet won't work without it", and indeed, you'd probably see all sorts of weird certs errors on otherwise normal websites, like google.com.


Real-world risk of a Cisco ASA 5505 running IKEv1 aggressive mode with PSK

Answers to your questions with their respective numbers:

Yes. Prefer plain mode and IKEv2.
These are defined through crypto map on your Cisco router.
port 500 opened is more precisely 500/udp/IP necessary for ISAKMP (the key exchange protocol used).
Yes. The opening of port 500/udp/IP has no reason to be public. It should be opened just for the allowed public IP from the allowed remote admin.
Moreover the ISAKMP and esp control ACL should be closed by a closing rule:

access-list 112 permit esp host authorized_origin_IP host router_IP
access-list 112 permit udp host authorized_origin_IP host router_IP eq isakmp
access-list 112 deny esp any any log
access-list 112 deny udp any any eq isakmp log

to log any attack attempt.
Depending on how skilled you are in writing crypto map your advice (and official policy) could be to become the admin in charge of configuring any VPN enabling access to any of your firewalls. Because this is an access point to the most important point of securing your company network.


It depends on the users you expect to connect to your server. If you are in control of the clients (you can verify which algorithms do they support and/or update them), your proposed list is security very reasonable (quite much all you excluded have some security weakness).

If you do not have control of the clients, you can still log the supported list of algorithms for some time and verify you will not cut out most of the clients. These days is no reason why an up-to-date client should not support your proposed algorithms so issuing some message "Please, update your client" would make sense.

The backward compatibility is important mostly for the clients, because there are ancient devices running SSH server unable to update their software. But this should not be a problem for SSH clients.


Is there any need to penetration test a GoogleAppEngine solution?

Just because Google hosts the site doesn't make it anymore secure.

It is still your code that is open to exploitation. If it contains business critical information or user data then it is prudent to use secure programming methods and other practice's to ensure the security of the system and your data. This could include penetration testing.

But be sure you are carrying out the testing against your own system and not Google's underlying infrastructure. Also be sure to check the terms and conditions for Google App Engine to ensure penetrating testing your site/app is not in breach of them.

Terms: https://developers.google.com/cloud/terms/

Google Audits: http://googleenterprise.blogspot.co.uk/2011/08/security-first-google-apps-and-google.html

Note: the above audit blog post doesn't mean insecure code hosted on Google's systems is guaranteed. It means their overall infrastructure has been audited and certified. Your code can still be vulnerable.


What's the use of certificate on Load Balancer and Keystore on Service?

Terminating HTTPS (presumably, you didn't state which protocol) on the load balancer has many advantages, a subset relevant here:

request inspection, protocol clean up/enforcement, URL restrictions and WAF capability
reply inspection, DLP capability
inspection of cookies/URLs for server assignment and session stickiness
(probably) common TLS session cache, hardware assisted RSA and symmetric cipher support

If you don't terminate TLS on the load-balancer, you will not have any inspection capability, and you will have limited session assignment options.

Using a certificate on the back-end (content/application) servers as well has some advantages:

the content/application back-end server uses the same protocol as the client, this can have an effect on the generation of absolute URLs, and change the behaviour of some protocol aware systems (e.g. OWA, but there are workarounds for this)
development and testing is usually easier if everything uses one protocol
you can keep everything in the front-end DMZ encrypted, which may be required by security policy
if there is no front-end DMZ (i.e. your load-balancer is outside your perimeter firewall) then this configuration is almost certainly required

and at least one disadvantage:

TLS overheads (mostly RSA key generation). On a trusted network it may be acceptable to use shorter RSA keys or quicker (less robust) symmetric ciphers though. Persistent connections or longer session times mitigate also.

In the general case, load-balancing or reverse-proxying is simplest when both the front-end and the back-end server use the same protocol (URI scheme), host name, port and URI path. This simplifies or eliminates the need for rewriting of headers, content, cookie paths, error messages etc.

The clients will (should) only see the public CA certificate on the front-end (load balancer). You can use a no-cost self-signed certificate on the back-end web server(s). There's usually no reason you cannot also use the same commercial CA certificates here too, though some CAs used to require a "licence" to use a certificate on more than one device.

All connections will be encrypted from client to load-balancer, and again from load-balancer to back-end server.
See also: Should SSL be terminated at a load balancer?


Protecting my machine from running untrusted applications

VPN is to virtual machine as air conditioning is to a couch. Very different things.
You have to get clear on what you want to be protected from:

Traffic coming from your machine (to something malicious)
Malware installed on your machine

Those are 2 very different problems. And a VPN protects you from neither.
A Virtual Machine can be used to limit the damage an infection can cause. Unless the infection is extremely advanced, it can only damage the VM. Dual Booting does not provide any isolation at all.


You are trying to combine a couple of different types of risk that you need to keep separate:

inherent risk (risk without treatment/mitigations/controls)
residual risk (risk after treatment/mitigations/controls)

You are also defining your threats far too specifically to the vulnerability, which is causing you further chicken/egg confusion.

You state that the threat is "an intruder can exploit". That's not the threat. The threat is that a potential intruder will test passwords using brute force methods.

Also, your risk analysis suddenly expands the scope beyond the threat and vulnerability. Modification and deletion is a potential secondary effect to the unauthorised access risk that the threat and vulnerability describe.

This makes your inherent risk analysis:

Threat – an intruder tests passwords using brute force
Vulnerability – password is discoverable to brute-force methods in a short time frame
Risk – by exploiting weak passwords, an attacker gains unauthorised access to the system

So, using this modular method, you do not have a chicken/egg problem with threats and vulnerabilities. Threats do what they do. Vulnerabilities exist or not. When they align, then you have a "hazard condition" that can result in harm.

If you do not have this vulnerability (i.e. if you only use key authentication, not password authentication), then this particular threat does not apply to the system. Other threats exist, but there is no risk of this type.

If you have controls in place to treat this risk (2FA, password auditing, brute-force detection and lock-out, etc,.) then your residual risk is lowered: risk = threat x vuln - mitigations


Self-signed certificates and ephemeral Diffie–Hellman key exchange protocol

Unless the users connecting to your site have imported your self-certificate from a trusted source, then yes, you will be vulnerable to MITM attacks. The reason for this is that an attacker could use his own self-signed certificate, and there would be no way for end users to tell that it is not the correct one.

Don't use a self-signed certificate. Teaching users to ignore the browser warnings and click through teaches them bad habits. If you don't want to spend money on a certificate, you can use a free service like Let's Encrypt. This is a CA which provides free domain validation-based certificates.


Verifying Security of a Custom Network Protocol

As with everything, you engage the control that is proportionate to the risk. We can't really advise on the appropriate control without understanding more about the risks.

These are a few processes that are commonly used:

3rd party review (be it professors, friends, or paid reviewers)
threat modelling/vulnerability modelling (standard frameworks exist for this)
researching similar protocols to see what threats/vulnerabilities they identified and how they countered them in their design
agile, reactionary design ("just putting it in the hands of users")

The last point is a valid option, but you have to employ it in such a way that respects the risks/costs involved. Will you be reactive enough to mitigate problems? In the worst case scenario, what are the potential impacts? Will you be able to identify problems or will vulnerabilities be exploited "under the radar"? You also have to be aware of any ancillary impacts that you might not be accounting for, like the impacts to user's private data, etc.

And all that said, the same considerations apply to all the other points. If you miss something in a review, modelling, or research, what will the impacts be? If you are comfortable with those impacts, then use those controls. If you are not comfortable with those impacts, then you need to use the control that provides better assurance that your risks are known and properly treated.


Why is my firewall blocking on some files but not others?

A firewall is "a device or set of devices designed to permit or deny network transmissions based upon a set of rules". These rules are usually written by your network administrators, and, depending on the sophistication of the firewall, can be very simple or very clever.

Your admins have probably written a set of rules designed to allow DropBox traffic through. Perhaps an important business process (or a senior person in the business, alas!) requires Dropbox. Or they may have concluded that an executable file you have deliberately put in your dropbox is more likely to be safe than something you downloaded from the Internet.

They might have done this by writing a rule that looks at the URL (modern firewalls can do this). More likely is that they have a rule that looks at the site you are connected to. Or, they might allow secure HTTPS traffic, which Dropbox uses, but not regular HTTP traffic. Or they might only block the downloading of executables from your web browser, and allow dropbox through. Modern (third generation) firewalls can do lots of fancy things.

Also, of course, it is possible that they do not want DropBox to get though, but have made a mistake in their rule set. Network admins are human!

For a definitive answer, you'll need to ask your network admins. You might also check if you have an Acceptable Use Policy for the Internet - that may give some clues at what is filtered.


Securing an OAuth / OpenID Connect identity in a cookie for easy login

Yes and no.

If done right it will be, but what you are describing is simply an authentication cookie.

I would suggest to not reinvent the wheel. The framework/programming language that you use probably already have a way to manage authentication cookie. I would go with that instead of creating it yourself.


Where and How is data stored in a session?

This depends on the webserver used. If we take PHP on Unix as an example it may store the session on the filesystem in the /tmp folder. It creates a file here with the name of the users session ID prefixed with sess_ (Example: /tmp/sess_9gk8f055hd61qll6a8pjpje2n2).The contents of the session can be optionally encrypted before being placed on the browser. For Apache sessions (not necessarily PHP) you may use the mod_session_crypto module (Read more here).

The owner of the session can not change the session variables as he feels like unless the application allows him to do it. The application logic has to provide means to change the session in order for the user to change the variables.

The session object is never transmitted to the client and only a reference to the session (e.g. PHPSESSID) is passed to the client. The session ID should have high entropy and minimum 16 bytes of length in order to be very hard to guess. See OWASP Top 10 - Broken authentication and session management for more information about that. Also see this OWASP Cheat sheet for specific information on how to secure sessions.

Attacks against session storage:

If there exists a flaw like for example LFI (Local File Inclusion) it may be possible for an attacker to read their own and other users session objects by including the file on the file system. For example if the following example worked I could possibly read my own session data:

http://<victim>/?page=../../../../../../../../tmp/sess_<my sessionid>


Security issues related to public keys and SSH

You should trust the default options of ssh-keygen and not try to fiddle with random sources and so on. These are delicate matters. You can rely on the OpenSSH developers for having done things correctly -- you can rely because you already rely on them for having done a proper, leak-free implementation of the OpenSSH protocol, something which is far from easy.

For RSA, DSA, ElGamal, Diffie-Hellman, and similar algorithms, 2048-bit keys are enough. Estimating the strength of such algorithms in a meaningful way is not easy, because the best known attack algorithms rely on an awful lot of raw CPU power but also memory, storage, data bandwidth, and applicability of parallel computing of linear algebra on huge spare matrices. So such estimates must guess how future computing architectures and envisioned specialized circuits will fare against a number of more-or-less orthogonal scales, and the whole thing is more about divination than scientific prediction. Nevertheless, some have tried to establish guidelines, see this site for a compendium of existing rulesets that have been published. For instance, NIST states that 2048-bit RSA or DSA keys are fine until at least year 2030; note that the same NIST says that 1024-bit RSA keys should not be used beyond 2010, and yet we are now in 2012 and nobody still knows how to actually crack a 1024-bit RSA key (current record is for a 768-bit RSA key).

You are right in protecting your private key storage. This does not necessarily calls for a passphrase, though: in some contexts, the private key may reside in a desktop systems which is physically protected, and that could be deemed secure enough. Yet, strong passphrases are a nice reflex to have, and I can only encourage them.

As for key renewal, I would rather advise against it. Key renewal is a relatively complex operation because you have to transport the public keys to all relevant places (the .ssh/authorized_keys on the servers to which you want to connect); if you forget one, then you will have to engage in a recovery procedure later on, and recovery procedures are, by definition, breaches of security. Controlled breaches, but breaches nonetheless. So you should renew your key only insofar as it helps you sleep at night, but key renewal is likely to be overdone. Remember that if an attacker can obtain your private key once, then he can plant his own public key in all the servers himself: changing your key will not stop him. So key renewal has relatively little impact on security anyway.


If CORS is set to * your browser can't read the response if cookies are sent over. Why is the wildcard considered insecure?

An application should never revoke their rights over to the Same-Origin Policy, unless there is no other option.  In order for personal information to be disclosed with CORS,  an attacker must "ride" on an authenticated session,  which would require a session cookie.

An Access-Control-Allow-Origin: * could be exploited by an attacker to view an application that is only accessible on a local network,  or VPN.   In a sense this insecure rule-set creates a tunnel to an affected application, where an attacker could access a sensitive HTTP server on a private network segment.


In the company I work for, we use SAML 2.0 authentication across all systems. If an employee is using the company's laptop, a client certificate is used for single sign-on with SAML 2.0.

However we still provide the fallback option to the user that if no certificate is sent in the SAML 2.0 authentication request, the corporate username and password can be used to authenticate in the Identity Provider.

SAML 2.0 support many single sign-on technologies to be used with it, some may be available only within your company's laptop (like a Kerberos token or client certificate). The SAML 2.0 authentication request cannot be modified during runtime since it will be created by the Service Provider or Identity Provider.

You can check with your company if providing the corporate user and password is supported.


Are private pastes on pastebin.com vulnerable? Can you trust pastebin?

Are private pastes on pastebin.com vulnerable?

Absolutely. Remember, if you are using a free service, then you are the product. Pastebin as a free service is definitely vulnerable. Personally, I use pastebin quite often. It's a very good service, and I am not worried about the website owners running off with my private information because I do not provide it.

However, since you are paying... I doubt a company would go out of their way to hurt their customers. Still, we can't see what the admins of the website are able to do, so we likely can't inform you.

  I am also worried because some private pastes from my account have +10 'unique visitors'. That souldn't be.

Do not rely on free services like this for things that need to be kept private/safe.

I understand Pastebin.com has a private paste option for paid accounts. Private and unlisted pastes are different.

Are my pastes truly private?

The owner(s) and moderator(s) of the website can easily know what you're pasting. And they can even do this without it showing up on the website counter if they wanted to. They could do something like this:

// finds all the latest private pastes first.
LoadFiles(db.Query("SELECT [file_name] from [paste_data]
where [access_type] = 'Private' ORDER BY [date_posted] ASC"));

If your machine is infected, or your internet connection is being monitored, people can find your pastes and pass them on to others. In the case of private pastes, your login can be shared.
The URLs, even if unlisted, can be enumerated. You can "guess" Urls. If someone stumbles across yours, they may eventually find your paste. This may not work for private pastes.

I think #1 and #2 are the most likely. However, I just wouldn't expect my pastes to be private once they go online. "Unlisted" in the context of Pastebin simply means they won't be listed on the main website, not that you can't visit them or guess the URL.

With private pastes, it's interesting that others can view your pastes. I would suspect website admins at this point.

Side note: The extra unique visitors may be an after-effect of you visiting the pastes in question under incognito/VPN. If you have a dynamic IP address or VPN, and the website counts all unique IP addresses visiting the pages, regardless of account, then it will likely update the counter. Why not test this?

Product Recommendations

Unfortunately, this isn't really a place for product recommendations. However, I would not expect anything I post online to be truly private.

If you want some decent privacy, my recommendation is to create your own website, encrypt the pastes you upload, and give people keys; one to to access files, and one to decrypt them. One Key to view them, One Key to decrypt them and on the website unbind them, In the Land of Mordor where the Shadows lie.


Is it possible to protect against rogue mobile base stations?

Note that I am not an expert in this field, this information is gleaned from other sources.

3G Interception tools are about to appear (or may well have already done so).

The "Stingray" from Harris is the most commonly quoted product and is widely used by US "law enforcement" (or maybe that should be law ignorement!)

The tech blog Techdirt is a blog I regularly follow and is an excellent source of information regarding government use of these devices.

I've found at least one article on some tools that claim to detect and protect against rogue cell towers. Another article here talks about some ideas on protection against the reasons for using fake towers. Such as monitoring for constant tower resets (location tracking), disabling GPS (location tracking again) and secondary voice encryption.

Incidentally, such devices are not only a US problem. A recent wardrive through London found at least 20 fake towers (see the article on Techdirt).


Lowercase 'w' seen in C:\windows application paths from wmic services list

Windows is not case sensitive by default. If the only symptom you have is a lowercase w and nothing else, it's not an issue to be worried about.

You don't need to remove the drive to inspect on a Linux machine. Download any modern Linux iso, create a bootable USB drive on another machine, and boot on the suspect machine.


Is the Litecoin Scrypt hashing technique a threat to hashed passwords?

No.

Litecoin uses an algorithm called scrypt which has variables that determine the amount of CPU/RAM required to compute  hash. Litecoin's scrypt parameters are fixed at N = 1024; p = 1; r = 1. (http://cryptocur.com/litecoin/)

Users of Scypt for password hashing purposes should have the parameters set much, much higher which will put password cracking out of range of Scrypt ASICs designed for Litecoin mining. After all, this is the key behind Scrypt's design, having a tunable hashing cost.


What do people mean when they talk about "hackers gaining access to our network" (at home)?

Do normal people actually set up complex local networks in their homes where they have some kind of "trust anyone with an internal IP address" security scheme going on?

They do. Many have a PC or notebook, mobile phone, a printer, smart speaker (Alexa etc), SmartTV, IP camera for surveillance, smart home devices ... and these are typically all connected to the same router.  Especially the cheaper devices are often vulnerable enough so that they can be hacked and recruited to be part of a botnet, see  Mirai.

Routers are often vulnerable too. If these get hacked they allow an attacker not only to be part of a botnet but to intercept and change traffic. With luck one will only get lots of advertisements on your computer but links you click might also lead to phishing sites or downloads might be replaced with malware in transit.

And devices in the same LAN are usually configured to trust each other. Windows ask for the type of network and if private network is configured it will share folders to other systems in the same network etc and thus also to an attacker located on one of these systems.

  At best, they can maybe read plaintext traffic, but how much such is there these days? I shall hope 0% of all traffic.

If you look at "HTTPS usage in Chrome worldwide" in the Google transparency report you'll see that about 90% of the traffic is currently encrypted in western countries but that it might be much different in other areas, like currently only around 75% in Indonesia. And this is amount of traffic, not number of different websites. Especially many of the smaller sites are still HTTP only.

And this is for internet facing traffic only. Most traffic in the LAN itself (like Windows file sharing) is still not encrypted.


What are requirements of Key Usage extension of parent and child certificates?

https://tools.ietf.org/html/rfc5280.html#section-4.2.1.3 has this to say:

If the keyUsage extension is present, then the subject public key
MUST NOT be used to verify signatures on certificates or CRLs unless
the corresponding keyCertSign or cRLSign bit is set.  If the subject
public key is only to be used for verifying signatures on
certificates and/or CRLs, then the digitalSignature and
nonRepudiation bits SHOULD NOT be set.  However, the digitalSignature
and/or nonRepudiation bits MAY be set in addition to the keyCertSign
and/or cRLSign bits if the subject public key is to be used to verify
signatures on certificates and/or CRLs as well as other objects.

So the expectation is that a CA's KeyUsage will assert { keyCertSign | cRLSign } without asserting digitalSignature.  And the end-entity/leaf cert will of course want to assert digitalSignature, therefore there's no expectation of subsetting.


If a hacker steals data i keep on a server, can i be held liable by the UK data protection act?

IANAL, but it seems that you can't be held liable for a data breach as long as:

you can demonstrate that you took appropriate measures to prevent the data from being accessed,

you periodically review these measures to ensure they are up to date, and

you deal with breaches in an a suitable way (including informing the people that have been affected)

Here are a couple of extracts from the ico.org.uk website on the subject:
What does the Data Protection Act say about the right to compensation?

If an individual suffers damage because you have breached the Act, they are entitled to claim compensation from you. This right can only be enforced through the courts. The Act allows you to defend a claim for compensation on the basis that you took all reasonable care in the circumstances to avoid the breach.

What does the Data Protection Act say about information security?

The Data Protection Act says that:

Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

This is the seventh data protection principle. In practice, it means you must have appropriate security to prevent the personal data you hold being accidentally or deliberately compromised. In particular, you will need to:

design and organise your security to fit the nature of the personal data you hold and the harm that may result from a security breach;

be clear about who in your organisation is responsible for ensuring information security;

make sure you have the right physical and technical security, backed up by robust policies and procedures and reliable, well-trained staff; and

be ready to respond to any breach of security swiftly and effectively.


Remember first of all that a failure of your firewall will have an impact on your entire network. From that perspective, you should either purchase extremely reliable server-grade hardware with redundant and hot-swap wear parts — or build a pair of machines, and use a protocol like CARP to control failover between them.

That said, the first critical choice regards network interface cards. Performance varies widely. I have been a fan of the Intel PRO series NIC's for ages. They are expensive, but they perform. Simple choice.

The next choice regards CPU. The number of CPU cycles per packet will depend highly on your firewall rules. If we're talking about the simplest possibility of a dozen rules with some state-keeping, the cheapest Core i5 will probably get the job done. But if you're approaching a hundred rule evaluations per packet, or plan to run proxies, network intrusion detection, heavy logging, or other such things, you will need more CPU power. How much more? The answer is to prototype and benchmark.


XSS when some keywords are prevented on the server side

The problem is that there are a whole load of ways to get XSS in such a case:


Can Veracode detect vulnerabilities in jsp files?

Hi and thanks for your feedback. I can offer you some general information here and provide suggestions about how we can dig into your specific application.

First, Veracode does have support for JSPs. We generally precompile the JSPs upon your submission so that we can ensure we have all the necessary supporting pieces, then we analyze the resulting bytecode alongside the rest of your compiled Java code.

There are a few things that can go wrong when a customer uploads JSPs:

JSPs cannot be compiled. This happens when either a supporting
library required by the JSP is not present in the upload, or the JSP
is in an uncompilable state. We report back any JSP compilation
failures in the prescan report, so if you see these it's generally a
sign that we won't be able to analyze the content of the JSPs. If
you see these warnings, check to see if you are missing a class
dependency and see if you can upload it so we can get a good
compiled version of your JSP.
There's a packaging issue. While we can handle a few different ways to package your application, the Veracode service gets best
results if you upload a web application as a properly packaged WAR
file, including the web.xml. If you upload the application packaged
in a different way we may not be able to put the JSPs in their
proper context for analysis. This is an area we're working on,
because we realize that not every Java application server requires
WARs, and you may be deploying using a different model.
We don't support one of your frameworks. Because Veracode does a full data- and control-flow analysis of the application, we need to
have an understanding of everything that might impact the control
flow, including frameworks. We typically try to call out unsupported
frameworks at upload time as well; obviously that's not something
you'll be able to address with a quick fix, but we try to be as
transparent as we can about what we can analyze and what we can't.

All of that aside, we may simply have an issue in our engine when it comes to your application. The best thing to do is to schedule a readout with our service team so we can look at your results with you and offer you advice for your specific application. Depending on your subscription, you may have a "Request a Readout" button directly in the UI; if you don't, please contact us at support at veracode.com and we'll see what we can do to answer your concerns.


Why Antivirus Detects Simple Java Program as Trojan?

Just a bit of conjecture here, but there may be some common patterns the av uses for all languages it can analyze deeply, and the pattern displayed in your program is quite similar to the sort of encoding one sees in obfuscated javascript (where they will have a string, perform some operations on it, and eventually end up evaling it). This is a heuristic signature we're talking about, so it could be something like that.

Does the signature still fire without the code which counts the 1s (specifically the call to str.replaceAll)?


Powershell says microsoft's own ps1 script is insecure, should I proceed with running the script?

An expired signature should always trigger a warning for signed code, whether it is compiled or interpreted. This is normal and expected.

On top of that, the CA cert used to sign that cert is also expired.

Since the file came directly from the vendor, it is probably safe to use. This is especially true since it was countersigned by their time stamp PCA, which acts as a witness that this file existed at the date specified and was already signed by Microsoft at that point. (Countersignatures are usually done by third parties, but whatever.)

While it is bad form to distribute code signed with expired certs, it is not unheard of. In this case, the signer and the distributor are the same company, so they could simply cease distribution if they believed the file was altered.

Overall, this is bad form, but it is not terribly surprising.


If you can put 2 interfaces on the Linux box, poisoning and attacks are not needed at all. Setup interfaces for WAN & LAN, add DHCP server and some NAT rules and you can easily monitor traffic with any tools including ethercap, tcpdump, wireshark, etc and later block those undesired streams.

If 2 interfaces are not handy, do the same above on one interface: Disable DHCP on the router, give Linux a static address, do the rest just like above and let the Linux do the job.


Does current PCI code require SSH connections be restricted to
enumerated (specific) client IP addresses on the unsecure, dirty side?

Not really.  PCI dictates that there should be firewall rules in place to limit access, but if you can justify an any -> 22/ssh rule, then you've satisfied PCI.

Isn't that outside the scope of the PCI code?

Well, requiring firewall controls is within PCI scope; see §1.2 and §1.2.1 specifically.  Interpreting whether the rules you've implemented are secure or insecure is up to the QSA; if you permit protocols like FTP or Telnet which are unencrypted, you need to show compensating controls.  But there's no blanket prohibition of any -> rules, which seems to be what you're asking about.
This of course assumes that the device falls within scope, e.g., is part of or connected to your CDE.  It sounds from your comments as if the device is completely disjointed from the CDE, in which case DSS doesn't apply.  If you're trying to determine if something is in scope or not, I recommend the Guidance for PCI DSS Scoping and Network Segmentation


WD My Cloud Vulnerabilities - What is at risk?

MyCloud is a service that runs on the NAS. The exploits documented on the site you link to allow three different things:

1) Bypass login and pose as a MyCloud administrator

2) Place files anywhere on the NAS

3) Execute commands on the NAS

These exploits are limited to the NAS device itself, but as you point out, once an attacker has gained access to the NAS, he can use that as a stepping stone into your home network / your connected devices.

For example, the ability to place any file he wants on the NAS allows him to place viruses, trojans and other malware on your NAS. Once you open the affected files on your other devices, they might become infected.

Having access to the NAS itself allows an attacker to spy on your unencrypted network traffic unless your network is very well protected against various spoofing techniques. For example, if you're using a local mail program to send and receive mail and you communicate with your mail server unencrypted, an attacker can potentially read (and change) all your incoming and outgoing e-mail.

The compromised NAS does NOT give an attacker immediate direct access to data sitting on devices that simply connect to the NAS via a file-exchange protocol such as SMB, NFS, FTP in order to use network storage. However, the NAS will (most likely) have an unfiltered view of the network services running on the devices in your home network. If, for example, you're using windows and you've enabled file sharing on all computers in your home network, this service will also be visible to an attacker sitting on the NAS.

Access to the NAS also gives an attacker access to the password database of the NAS. Depending on how well passwords are protected by the NAS software, this might allow an attacker to recover your passwords, and since it's not a stretch to assume that you reuse this password elsewhere, he could gain access to other services you use.

For these reasons, I would never ever run a cloud solution of one of the consumer grade NAS providers on my home network. If you really want to do that, you should at the very least put a firewall between the NAS and the rest of your home network. While this won't help against the NAS passively infecting your other devices with trojans, it will at least make actively attacking your other devices from the NAS, and spying on your network traffic from the NAS, much harder.

The firewall can also be used to deny any connections from the NAS into the internet (except the ones needed to do file sharing), which will help against your NAS being coopted as part of a botnet.


How to confirm that my router is vulnerable to the glibc vulnerability (CVE-2015-7547)?

Testing if the router is vulnerably requires the ability to run (and usually also compile) some proof of concept code at the router and watching the output. How this can be done is described in GHOST bug: is there a simple way to test if my system is secure?.

But since there is usually no way to do this at most home routers (at least not for most users) you will probably not be able to test the router yourself. Instead you need to check with the vendor for more information like a statement that the router is not vulnerable or an updated firmware.


Opening window from secure site domainA.com, to partner site domainB.com - with short TTL encrypted query string

I think that a side-channel may be a better means of passing the data than trying to pass everything in a query string. The flow would be:

Domain A sends all relevant data directly to Domain B over HTTPS.
Domain B stores the data in a temporary session and creates a secure random ID for the session. (Note that this is not a regular session for Domain B, just a temporary list with a very short timeout.)
Domain B returns the session ID to Domain A.
Domain A then opens the new window with the URL https://domain-B/landingpage?tempID=XXXXX.
When Domain B receives the token, it removes the matching temporary session and uses the data. If the temp session doesn't exist, then it was a stale URL or a replayed URL and should be handled appropriately.

This way the data is secure because we trust HTTPS, you can pass any amount of data because the side-channel doesn't have query string limitations, there is no need to mess around with encryption keys or similar because HTTPS handles all of that for you, and replay protection is just a natural part of the process.


Simple methods of preventing infection from external drives

To avoid infection from storage devices, don't execute any files from them, and configure your operating system to not do so automatically. But storage devices aren't the only threat in form of USB. For example, take a look at this USB keyboard:

"But that's not a keyboard! That's a USB thumb drive!" Are you sure? "Of course! I can tell a keyboard apart from a thumb drive when I see them!" Really? It might look like a thumb drive to you, but when you connect it to a PC, it says it's a keyboard, and the PC has no reason to believe that it is anything else.

As soon as this device is recognized as a keyboard by the operating system, it will automatically start typing. What's it typing? That's up to the one who programmed it. Common payloads are the keyboard shortcut to open a text editor, type a malicious script, save it, perform the shortcut to open a command shell and execute what it just wrote. Others are to open a web browser, enter the URL of an executable on a FTP server, download it and execute it.

The only software-method to protect you from this is to disable plug&play of USB devices. You will then have to enable any new USB device manually. When you plug in a thumb drive and it appears as a HID device, you have reason to be suspicious and can choose to not enable it.

But there are also hardware-solutions. There are USB adapter plugs which only allow certain types of USB devices to pass through. Unfortunately I have never used such a device, so I don't feel comfortable to give any specific product recommendations.


What potential threats lie ahead after the hack of equifax in 2017?

Disclaimer: There is a lot of speculation involved with this one.

TL;DR:

A truckload of very useful data has been stolen. We don't really know who the attackers are and Equifax wasn't really helpful to provide transparency to customers. It might be different, when they interact with law enforcement (let's all hope so). If a well-organized group of hackers has the right tools and a cause, identity theft might become even more common that it is now, just because of the sheer mass of people affected. If you are one of them, take action, freeze your credit files and stay informed! In any case, a lot of money will be lost through credit card fraud. The only question is: how much? The amount will be determined by the actions of policy makers and credit reporting agencies in the near future. Hopefully they will learn from this event and take action as well.

At first we have to look at, what has been stolen from Equifax. According to this NYT article, as of the 7th of October we are talking about:

  According to the company, thieves took names, Social Security numbers,
  birth dates and addresses for up to 145.5 million people. They also
  helped themselves to some smaller number of driver’s license numbers.

  Thieves may have your credit card number, too; this is the case for
  more than 200,000 people, and Equifax has said that it let those
  people know by mail.

  Equifax has said that it has no evidence of a breach in its core
  consumer or commercial credit reporting databases, so your payment
  history is not floating around in the ether somewhere. Nor did the
  thieves get PINs that people use to unlock their frozen credit files.

Emphasis mine.

Wikipedia also mentions between 400,000 and 44 million(!) British residents whose data may have been compromised.

You could argue, that this information has a lot of potential to be incorrect. Equifax hasn't been the most transparent and trustworthy institution while handling this whole mess. But let's be faithful and hope this is all there is.

After gathering the information that we have been given until now, let's get to the real questions here:

What can one bad guy do with a name, a birth date, an address and:

one social security numer?
one credit card number?
one driver's license number?

What can a group of bad guys do with a million names, addresses, birthdays and all of the above?
What can a big group of bad guys do with a hundred million names and all of the above?

1.1. What can a bad guy do with a name, a birth date, an address and one social security numer?

You can do a whole lot of crazy stuff with this dataset. Apart from identity theft you can apply for a credit card, for a loan, open a bank account, rent a flat and so on and so forth. But: A service provider - for basically every kind of finance related service in the US - needs to access your credit files beforehand. That is why Equifax and most media outlets recommend to freeze your credit files if you are a victim of the breach[but this may be also a good idea if not]. As far as I understand the matter, if your files are frozen, no such services can be used.

1.2. What can a bad guy do with a name, a birth date, an address and one credit card number?

I'm not a 100% familiar with credit card fraud, but typically the most crucial part beside the data mentioned above is the 3-digit security number that is on the back of a credit card, typically known as the CVV (card verification value) or CSC (card security code). And, as far as the leaks go, they seem to be safe. But: As an attacker you could just start guessing the CVVs. I've found this article, that describes how a distributed guessing attack works. (In short: a webshop gives you five attempts before you get locked out, you guess 5 times, if you are lucky: hooray, if not, you move on to the next shop.) If you have 200,000 credit card numbers (plus names and everything else), you compile a big list of webshops, get a good ip range or some bots, start guessing today, and have all the CVVs in a week's time tops.

What then? You either start buying some nice gear or you get some inspiration here or from a lot of other sources around the web.

1.3. What can one bad guy do with a name, a birth date, an address and one driver's license number?

I'm not entirely sure how valuable/useful this information is. From what I've read, it seems that it's not that hard to come by. So this is probably the least of your concerns.

2. What can a group of bad guys do with a million names, addresses, birthdays and all of the above?

Now it gets in-te-res-ting! So far we have seen, that it is pretty easy to use the data that has been obtained from Equifax. But how big is the impact, if it is used in the most harmful towards customers and corporations way?
After large breaches of data most users typically don't change their login credentials[citation needed]. This has several reasons: 1. they are not aware of the situation, 2. they don't know that they are affected, 3. they are just too lazy. I assume that we will see the same behavior in regard to credit file freezes. This is highly speculative, but I would say, that a generous estimate would be, that maybe a third of the affected population freezes their credit files.
Let's do a little math, people!: 145M - (145M * 0,33) = 97,15M so this would leave roughly 100 Million people affected! A possible scenario for a big number (one million) of cards can be found in this wikipedia article (under Fraud). To give a short summary: on a very large amount of credit cards, a relatively low amount of money was charged. This amount was so low that it was just under the estimated threshold of when a credit card company would start a fraud investigation, if they suspect suspicious behavior ($9 vs. $10). The money was then transferred overseas and could not be traced by the authorities. This seems like an operation that can be done by a small team of not more than 10 people. The more manpower you have, the faster you can attack each credit card. This is one possible scenario. There are plenty of others.
The damage done in this case would be $1,800,000. That's a lot at first glance, but it is evenly distributed over a lot of people and several companies. So this will definitely not hurt the American economy as a whole. It gets problematic, if a malicious group starts targetting a small group of individuals or companies.
You want to ruin any medium sized company X with a webshop? Start ordering their products with a 100,000 credit cards over 6 months. This will be joyful for them at first. Company X thinks, they somehow made the deal of the century, selling all their products and making new ones as fast as they can, but when customers start to phone them 24/7, because they got some weird stuff in their mail that they never ordered and got charged 50 bucks as well, this will get ugly quickly.
With great money, comes great responsibility. Hackers oftentimes don't have any.

3. What can a big group of bad guys do with a hundred million names and all of the above?

The scenarios I mentioned before, can probably be done by a well-organized small group of people. We have seen big scale attacks that have been planned and executed by small groups of hackers. If you have a big (>15), well-organized group (or groups) of hackers with a cause, a lot of time and good equipment, they could do some serious work. Imagine this: what if 200,000 Americans were using their credit cards right now online in a concerted action? That could DDoS a lot of financial services, shops or banks. Or: You could donate a lot of money somewhere. These are only the sets of data, where the credit card data is available. If the bad guys are somehow able to open up bank accounts or to apply for a looooot of credit cards and use these, the damage could be really big. But this is a point, where the speculation gets probably a bit out of hand, so I will stop here.

One last thing I want to mention is the sale of compromised data.
A phenomenon we could observe after a significant breach, is that one single group of hackers was not able to make use of all the data they had stolen or they didn't even try to use the data at all. So what they did was this: Either they kind of "sorted" the stolen data Cinderella-style. The good ones go into the pot, the bad ones go into your crop. Everything that went into the crop was put into neat purchaseable portions. After a while bits and pieces of the once big chunk of compromised data was then found scattered over the dark net. Or they just sold everything there. If this happens, this might be good news, because less data in a lot of people's hands might be better, than all of the data in the hands of one small group.


Does MS16-087 imply Windows 7 computer vulnerable from Internet?

IMHO, the risk can be maintained reasonably low, because the attack vector needs that the user connects to an infected printer server or installs an infected driver on his machine.

That means that provided that the user is an educated one of has no administrative priviledge, either he will not even try to install a new printer on its machine, or will not be able to.

It can only be seen as a workaround and documented because if the machine should be reused later it would be critical to pass the patch. But it can be helpful if for any reason it is not possible to path a specific machine.


How to guarantee counter synchronisation between client and server for counter in hmac-based one time password implementation?

See HOTP, section E.4. This is reasonably well explained. The gist of the solution: when the counter on the server contains n, the server actually accepts as valid the one-time passwords corresponding to values n, n+1, n+2... up to (say) n+99. If what the client sent matches the one-time password for value n+37, then the client is accepted, and the new counter value in the server is set to n+38. The width of the range accepted by the server is a trade-off: a larger range tolerates clients which are widely out of synch, but it is more expensive on the server side (more potential one-time passwords to compute) and decreases security (since more distinct passwords will, at any time, be deemed "acceptable").


What's the safest way to inform a new user of their password on an invite-only website?

The best practice in this instance is to send them a link to a page where they can set their own password.

You should ensure that after they have used this link to register, that the link cannot be used for account takeover. One way of achieving this is including a time limited, single use token in the URL.


In this case should I worry about the XSS possibility? Should I check the inputs and sanitize them for every request?

Yes, you should worry about this foundational piece of security. Even if you can't currently envision an attack vector today, as your software evolves, you are leaving landmines in your wake that you will quickly forget about. It will become impossible to confidently build on this foundation.
We are constantly shocked by new and novel attacks, and they almost always involve chaining together multiple seemingly minor exploits in a novel and disastrous way. Don't knowingly give attacker an XSS exploit for free, you have no idea how that will combine in unexpected ways with other exploits you don't know about.
While the following is somewhat subjective, I'm an application developer of some 20 years and have been deeply interested in security for most of that time. I would say that the almost inevitable outcome is of this type of thinking is:

We ignored security when writing "feature X" because it was not exploitable when we built it, but changing product requirements exposed vulnerabilities in a way we didn't foresee... And now we're in trouble.

This mindset leads to some of the worst exploits; when you make a conscious decision to ignore security, and then something changes and suddenly it matters, the types of vulnerabilities you wind up exposing are catastrophic and so foundational that it can be easier to start over.
It's also much harder to find all vulnerabilities in a large sprawling application that was started in such an incorrect way, when you eventually do realize it's important. Especially if you have multiple developers, each one may make some haphazard attempt to secure the next thing they add, often in conflicting or overlapping ways that ultimately pile up as technical debt. Don't leave it to chance, and don't require each subsequent developer to "solve" security, set the tone of the project from day one.
I will also say that, if you do this professionally, you should have some pride in your craft. Learn to build software correctly always, not just went you think it's important. Building software correctly includes building software that is secure by default, not just when you remember to add security. Experience you gain building it correctly now makes you better prepared to build it correctly when you do decide it matters.
Finally, it should be no extra effort to just build it correctly from the outset. Use a sensible framework as intended and most types of vulnerabilities are already handled for you. You shouldn't have to write your own code for preventing XSS or SQL injection, I haven't had to do this in more than a decade. Every major framework has solved these problems better than you or I can. I've built the sandboxed note-taking app you're describing. I'm the only user, but I can tell you it has no vulnerabilities in it (famous last words) because I wrote it in Rails and Vue, mature technologies that handle most types of mitigation. I used these technologies not because I wanted security but because I wanted a rich feature set and mature ecosystem. Security came free.


Does Virus or Malware make harm to system if it is in Non Admin Mode for Windows

It is tricky to understand what you are asking so I am assuming you are asking about any damage the malware can cause if run under your user account.

Firstly, it can touch anything your user account can touch, so assume all your data can be wiped, altered or stolen.

Secondly, through the use of a privilege escalation exploit, the malware may be able to use your user account as a stepping stone to an admin account, and then it can do anything that account can do - generally regarded as total control over the machine.


How to find out if somebody is spying on my private browsing data in the same WiFi network?

Incognito mode does not provide any protection from Wi-Fi snooping; it merely stops your browser from saving your browsing history locally. If you're using unsecured Wi-Fi (or secured Wi-Fi where the attacker knows the password), there is no way to detect if your friend has been recording your web traffic. Any http sites you visited have potential to have been snooped. If your friend was snooping, he or she may be able to determine which https sites you've visited, but wouldn't be able to determine what you did on them beyond how long you spent on the site and how much data you exchanged.

If you're concerned, you need to talk to your friend. You should also look into enabling WPA2 on the shared router (even if everyone knows the password, it makes it harder for the attacker) and using something like HTTPS everywhere to avoid using http versions of sites when you can. If you're even more concerned about your privacy, @dwarf015 had a good idea: buy vpn service and connect to that.


You most definitely live in a sense of false security! Social engineering is very prevalent still today, and I doubt that is about to change in decades if ever.

Here are some brief explanations on why social engineering works. It's tough to cover everything because social engineering is a really broad field.

Some reasons why social engineering works (From the book quoted in the bottom):

Most people have the desire to be polite, especially to strangers
Professionals want to appear well-informed and intelligent
If you are praised, you will often talk more and divulge more
Most people would not lie for the sake of lying
Most people respond kindly to people who appear concerned about them

Being helpful

Usually humans want to be helpful to each other. We like doing nice things!

I run into the reception at a big corporate office with my papers soaked in coffee. I talk to the receptionist and explain that I have a job interview meeting in 5 minutes, but I just spilled coffee over all my papers. I then ask if the receptionist could be so sweet and print them out again for me with this USB memory stick that I have.

This might lead to an actual infection of the receptionist's PC and may gain me a foothold within the network.

Using fear

The fear of failing or not doing as ordered:

The company's director's (John Smith) facebook page (or whatever other source of information) reveals that he has just left on a cruise for 3 weeks. I call the secretary and with a commanding voice I say "Hi, it's Chris calling. I just got off the phone with John Smith, he's having a very good time on his cruise with his wife Carla and kids. However, we are in the midst of integrating a very important business system and he told me to give you a call so you can help us. He couldn't call himself because they are going on a safari, but this is really urgent. All you need to do is take the USB stick that is addressed to him in the mail and plug it in, start the computer and we are all done. The project survives!

Thank you very much! You have been a great help! I am sure John Smith will recognize you for this act of helpfulness. "

Playing on reciprocation

The tailgate. I hold the entry door for you, and I quickly walk behind you. When you open the next door, which is security enabled, I head in the same direction and most people will try and repay the helpful action by holding the door for you again, thus allowing you into a place where you should not be. Worried about getting caught? Nah.. You just say you're sorry and that you went the wrong way.

The target would almost feel obliged to hold the door for you!

Exploiting the curiosity

Try dropping 10 USB sticks in various locations in your organization. You don't have to place them in too obvious places. The USB should have an auto-run phone home program so you can see when someone connects the USB stick and should theoretically be exploited.

Another version of this is to drop USB sticks with a single PDF document that is called e.g. "John Smith - Norway.pdf". The PDf document contains a Adobe Acrobat Reader exploit (there is tons of them) and once the user clicks the document he will be owned. Of course, you have made sure that the exploit is tailored to the target organization's specific version of Adobe. It will feel natural for most people to open the document so that they can try return the USB stick to its owner.

Another example of curiosity (maybe another term explains this better) is all these SPAM mails or bad Internet ads that you have won something or a Nigerian prince is offering you a whole lot of money if you can help him. I am sure you are familiar with these already, but these are also social engineering attacks, and the reason they haven't stopped is that they still work!

That's just a few examples. Of course there are tons more!

We can also take a look at historic social engineering events:

HBGary

Full story can be read here (Page 3 contains the social engineering part)

Last year HBGary was hacked. This attack involved many different steps but also a social engineering aspect as well. Long story short, the hacker compromised the email account of a VIP in the company and sent an email to an administrator of the target system saying something like this: "Hi John, I am currently in Europe and I'm bouncing between airports. Can you open up SSH on a high numbered port for me coming from any IP? I need to get some work done". When the administrator gets this email he feels it is natural to comply with this, seeing as the email is coming from a trusted source.

But that is not it! The attacker had the password for the account, but the login was not working! So he emails back to the administrator "Hey again, it does not seem to be working. The password is still  right? What was the user-name again?". Now he has also provided the actual password for the system (the attacker had it from the earlier compromise of another system in the same hack), giving the attacker a whole lot more trust from the administrator. So of course the administrator complies and tells the attacker his user-name.

The list at the top comes from the book "Social Engineering: The Art of Human Hacking" and I can very highly recommend it!


How long do HTML password fields (sent to the server as postdata) remain in memory?

Whether traditional "protections" for sensitive data in desktop RAM (e.g. SecureString) are really needed or not, is debatable. When attackers can read the RAM contents, they already have a lot of control on the machine. We can still justify some proactive measures in the following sense:

RAM in a machine may leak to disk, through virtual memory.
The hibernation mechanism on laptops is also prone to copy RAM contents to disk.
Desktop machines may be infected by malware (through the user's gullibility) which might run with limited privileges but still be able to explore the RAM contents of other process running for the same user.
Physical security of desktop computers (and especially laptops) cannot be ensured at all times; the attacker may grab the machine and run away.

For these reasons, it is best if the passwords and other sensitive data are "protected", i.e. prevented in some way from leaking to disk, and forcibly removed from RAM immediately after usage, thereby reducing the vulnerability window.

None of these reasons apply to servers (even the bit about "virtual memory": if your server hits swap space, then it does not have enough RAM; RAM is cheap nowadays; good servers don't use swap space at all). Therefore, it can be argued that servers don't need to apply the traditional in-RAM protections for passwords.


What PCI standard(s) a payment app (for Smartphones) should comply with in order to be approved by PCI SSC?

Only a QSA can give you a qualified answer, but I can give you my understanding.

It seems like you need to define your scope further, do you need both PA-DSS and PCI-DSS? You'd likely only need that if you are offering a service as well as providing the software to third parties to control and use. Is that the case?

But to answer your questions, you'd likely need to comply with other security standards such as OWASP or an equivalent, and implementation standards such as TLS 1.2. The PCI standards will dictate what those standards need to be. My understanding is P2PE is for card present transactions.

Your title to this post mentions approval by the PCI SSC, but you don't require their approval, you require your clients approval only. Given your clients are payment service providers, they are probably well versed in PCI, so you can just ask them what they require from you. Remember PCI is contract based.

Otherwise, from your description you would be open to every aspect of PCI compliance which could be quite a painful process. It would be worth engaging a QSA to help you define your scope, if you have not done so already, so you're not pursuing standards you may not need.

Good luck!


... if the site is using HTTP to HTTPS login iframe.

If I understand you right then you mean that the login frame is loaded via HTTP, but the results are send via HTTPS. In this case a passive MITM attack (i.e. sniffing only) can not be used to sniff the credentials because they are sent with HTTPS. But an active attack like sslstrip can still be used because it can change the target of the login form and thus make it sent the data in plain.


Is it necessary to protect user data if they know and agree to it being insecure?

You expect user's to read the agreement? Really? That simply doesn't happen, it's a rare user that reads the EULA instead of simply clicking next or checking that checkbox that says they read it.

These days there's an implicit assumption that you'd going to take some care over what you're doing, in the same way that you expect a surgeon to know what organ to remove, and even if you sign a piece of paper before going into surgery agreeing not to sue if they remove a leg instead of a kidney the implicit duty of care expectation and subsequent publicity nightmare when you're hopping mad on television because they lopped off a leg (pun intended!) would sink that doctor's career for good.


Store a Cryptographic Hash with look-up capability

If you need a really safe system with salting and key-stretching, then there is no way to make the hashes searchable. It is the same problem as with storing passwords:

With salting you prevent rainbow table attacks, but one has to read the salt first before you can verify the data-hash.
With key-stretching (making the hash slow) you can thwart brute-force attacks, but one cannot quickly verify many/all data-hashes.

This makes using safe hashes and searchability mutually exclusive. It depends on the required level of security, whether you can go without the salt, or if you can switch to less safe encryption.

One way out of this problem could be, to encrypt the data, without storing the key. This requires the user to enter a password every time he uses the service. From this user password you would then generate a key with a key-derivation-function and keep the key in memory as long as necessary.


How do I protect the stored clients' public keys on a server?

It depends on a number of issues such as how they are used, what the architecture of the server is, etc. But a few ideas to think about are:

can you store them on a 'write only' medium? A 'finalised' CD-ROM for example?
can you check their fingerprints before use against a copy of the fingerprints stored on a different server, or downloaded from a (trusted) public key server?
can you download the keys from a (trusted) public key server before each use (check the security of the connection to the key server, including DNS records resolving to the server before use)?
can you enter the fingerprint for the keys ephemerally at boot time and then compare them against the computed fingerprint at the time of use?
have you got file integrity software running that you can trust? If not, I'd consider this option very strongly because you may be able to trust the keys, but if the rest of the system is compromised why is that any use?

PKI is a 'solved problem' to some extent so have you also looked at commercial solutions to this everyday problem?


Whats the difference between MAC vs hash

A cryptographic hash function is a completely public, deterministic hash function which everybody can compute over arbitrary inputs. It takes as input a sequence of bits (any sequence of bits; some hash functions are formally limited to inputs of, say, less 264 bits, aka "2 millions of terabytes") and outputs values in a rather small space, typically a sequence of bits with a fixed size (e.g. always 160 bits with the standard hash function SHA-1). Good cryptographic hash functions respect some conditions which boil down to, informally, that they mix input data so thoroughly that we cannot figure it out afterwards.

A message authentication code is an algorithm which takes as input a message and a secret key and produces a fixed-sized output which can be later on verified to match the message; the verification also requires the same secret key. Contrary to hash functions where everything is known and attackers are fighting against mathematics, MAC make sense in models where there are entities with knowledge of a secret. What we expect from a good MAC is unforgeability: it should be infeasible to compute a pair message+MAC value which successfully verifies with a given key K without knowing K exactly and in its entirety.

Hash functions and MAC are thus distinct kind of algorithms with distinct properties and used in really distinct situations.

Some MAC algorithms (but certainly not all of them) can be thought of as "hash functions with a key" but this is a restrictive view. HMAC is a well-known MAC construction, which itself builds on an underlying hash function in a smart way. Indeed, security properties and models for hash functions and MAC are sufficiently distinct from each other that slapping a hash function and a key together does not necessarily yield a secure MAC, even if the hash function is secure (see the length extension attack which illustrates that point).

To some extent, we can state that a MAC algorithm which can operate securely without an IV must exhibit some hash-like properties (that's the reason I like HMAC: without an IV, it is much harder to get it wrong when implementing it). However, the Devil is in the details.


Is there now an increased risk of ransomware in pirated software?

Ransomware is a critical threat to users and company data these days.
According to what I have encountered in corporate environments, usually antivirus software hasn't been able to detect the latest Ransomware versions (I have used specific tools).

As you have pointed out, it is important to understand that paying the ransom will continue supporting this activity (and it is not a guaranty of having your files decrypted).

I haven't found a correlation between pirated software and increase in ransomware risk. As far as I have seen, the primary distribution vector is email (with infected attachment) or a link pointing to a file (also infected). But, of course, it is not crazy to think that it might be used in the future, as several types of malware are distributed via pirated software.

As far as I understand, the most important countermeasure that you can implement is to have a solid backup schema (and regularly test the recover process).

In order to avoid propagation, I have:

Removed unnecessary mapped units over the network (and have replaced some with shortcuts).
Perform an audit over the file permissions in file server to ensure that everyone is allowed to access what they need and nothing else (Principle of least privilege)1
Block binaries running from %APPDATA% and %TEMP% paths. Most of the ransomware files are dropped and executed from these locations, so blocking execution would prevent the ransomware from running.

As a final recommendation, it is important to stay up to date with O.S., and browsers, and avoid using pirated and uncontrolled software.


You need to supply the correct syntax. Here is an example:

hydra [TARGETIP] http-form-post "/TARGETPATH/TARGETPAGE.php:user=^USER^&pass=^PASS^:Bad login" -L users.txt -P pass.txt -t 10 -w 30 -o hydra-http-post-attack.txt

1st field (before the 1st colon) = location of the target page
2nd field (before the 2nd colon) = user & password parameters
3rd field (after the 2nd colon) = page response on incorrect login attempt


Explaining a bad approach - not comparing hashes

Assuming the value stored in the agents.password field is the MD5 hash of the password, the code as shown is correct:

sends the database the (login, password) pair
asks it to find a matching entry where agents.ID == login and agents.password = MD5(password) and return the value of the agents.password field
if the returned value is empty: return an error (I'm not sure about the dialect, so it could be empty as in "no result", or empty as in "empty password field". Let's assume the former).

The good points:

the behavior is correct: it returns true if and only if both the username and password match, and an error otherwise. This is good security behavior in the sense that it does not leak information about the existence of the user (eg: you cannot tell the difference between "user A does not exist" and "wrong password").
timing is similar: the time spent in the function will not differ much depending on whether the user exists or not, which avoids leaking that information (though it depends on the behavior of the query itself).

The bad points:

a single round of MD5 is a terrible way to hash a password. You want a much more expensive password hashing function as well as a random salt and possibly even a secret pepper
this is sending the plaintext password to the database, using builtin DB functions to perform the MD5 hash. This introduces another location where the plaintext password can be logged (eg: data audit logs) and leaked.

Compared to your proposal:

If I understand your proposal correctly, you would prefer to do something along the lines of the following:

hashedPassword = query(select password where ID = login)
hash = md5(password)
if hash != hashedPassword {
    fail
} else {
    success
}

The end result (in terms of input/output) is exactly the same. But looking through the good and bad points, the differences are:

you are not sending the plaintext password to the DB. That's a plus in my book
you may or may not be much faster when the user does not exist (it depends if you exit early if the user does not exist)

Conclusion:

The two approaches are mostly similar, and the little details I pointed out are nothing compared to the fact that MD5 is used. That is the biggest issue that should be resolved as soon as possible.


- It's a bit old question, but I managed to found a solution that worked for me.

There's available on Github a module that provides PKCS#11 backend for TPM 2.0 chips.

Usage:

Create TPM Key

Create a primary key with hash algorithm sha256 and key algorithm rsa and store the object context in a file (po.ctx).

tpm2_createprimary -H o -g sha256 -G rsa -C po.ctx

Now create an object that can be loaded into the TPM with parent object from file (po.ctx) using hash algorithm SHA256 and key algorithm RSA output the public and private keys to key.pub|priv.

tpm2_create -c po.ctx -g sha256 -G rsa -u key.pub -r key.priv

Load the private and public keys into the TPM's transient memory.

tpm2_load -c po.ctx -u key.pub -r key.priv -C obj.ctx

Make the object persistent, specifying a valid handle.

tpm2_evictcontrol -A o -c obj.ctx -H 0x81010010

Now you can remove all temporarily files.

rm key.name *.ctx

Install TPM2-PK11 and copy config.sample to ~/.tpm2/config.
Create a certificate (eg. w/ Certtool (GnuTLS)).
Configure your application to use TPM2-PK11 and the created TPM key.

OpenSSH Client:

Create configuration file and change it for your setup:

cp config.sample ~/.tpm2/config

Extract public key:

ssh-keygen -D libtpm2-pk11.so

Use your TPM key:

ssh -I libtpm2-pk11.so ssh.example.com

or add the PKCS#11 module to your ssh config in ~/.ssh/config:

Host *
    PKCS11Provider libtpm2-pk11.so

Firefox:

Go to Preferences, Privacy & Security and click on the button Security Devices.
Press Load and select the libtpm2-pk11.so installed on your system.
After loading the TPM2 PKCS11 Slot should now be listed in the Device Manager and your certificates should be listed when selecting View Certificates under Your Certificates.


Why are email clients prevented from seeing the envelope?

Alternatively, if I am incorrect about this: then in what way?

You are comparing apples to oranges.

The email Header is most closely equivalent to the physical mail Envelope - even better, the email Header represents routing information that is not accessible to the recipient in physical mail.  So it's not correct to say that email client's access to "envelope information" is hampered.  In fact, by design, the important aspects of "envelope information" are injected into the Header, ensuring that email Headers contain routing information greatly in excess of what any physical mail recipient could obtain.

Some definitions (assuming US mail for simplicity):

email Envelope: The values transmitted using the SMTP HELO/EHLO, MAIL FROM, and RCPT TO commands.  Any of these may legitimately change from one hop to the next.

email Header: The text transmitted after the SMTP DATA command, up until the first blank line, after which the email Body begins.  This likely includes a From: (which may or may not agree with the Envelope MAIL FROM) and a To: (which may or may not agree with the Envelope RCPT TO) header.  This email Header grows as each intermediate mail server prepends Received information, as required by RFC 5321 §3.7.2.  In addition the recipient mail servers may record the Envelope RCPT TO by injecting a header such as Apparently-To, Delivered-To, X-Envelope-To, X-Original-To, etc. (but see footnote below).

physical Envelope: The From address (optional, upper left hand corner), the To address (center), originating postmark (upper right, over the stamp).  There may be additional encodings of the recipient information such as the IM Barcode and the orange barcode, but those are both effectively more-or-less lossy representations of the To address.

Note that RFC 5321 §3.6.3 suggests that SMTP relay servers should never modify anything in the header and body except to prepend the required Received line.  In practice, other headers get prepended, especially with intermediate anti-SPAM/malware relays.

Here's how the email Header incorporates necessary Envelope information

The SMTP Received header is prepended by each SMTP server and describes the Envelope information about itself and the previous server.  Consider this entry:

Received: from mail2.example.com (mail2.example.com [192.168.3.4])
    by lix-xx.members.linode.com (Postfix) with ESMTPS id 838CD4AE0
    for <gowenfawr@mymail.test>; Fri,  4 May 2012 12:45:26 -0400 (EDT)

This includes the EHLO/HELO hostname (the first mail2.example.com), the actual IP (192.168.3.4) of that system, and the DNS name that resolves via PTR (the second mail2.example.com).  This information is useful for detecting fraudulent email.

More envelope information may be logged, as seen in this example:

Received: from NAM01-SN1-obe.outbound.protection.outlook.com
    (mail-oln040092002074.outbound.protection.outlook.com [40.92.2.74])
    by smtp21.example.org (Postfix) with ESMTP id AF320401EE
    for <open@lists.example.org>;
    Wed,  5 Dec 2018 15:28:59 +0000 (UTC)

Here the envelope RCPT TO was encoded using the FOR clause of the Received line.  (Note that per RFC 5321 §4.4 only one entry is permitted, even when there are multiple RCPT TO commands.)

What's not preserved

The MAIL FROM and RCPT TO addresses are either not logged, or may be incompletely logged, into the header.  This may be part of your "tampering" detection concern.  It is a side effect of the fact that SMTP was designed to transport encapsulated messages that may have their own rich addressing and routing information before and after the SMTP phase of the connection.  It's also something with no physical analog.

This design consideration may also reflect that SMTP was not designed to be trusted, simply to work.  As soon as trust considerations arose, they were offloaded to other layers of the connection (PGP, SPF, DKIM, all of these occur "outside" the SMTP protocol).

Let's not forget

Any part of the header or body can be tampered with by a malicious relay.  The more effort you put into making relays log security information, the more you're potentially relying on bad information.  That's why each Received line reflects upon the previous relay, and not the one that's prepending it.

In other words, there's limited value to trying to load more trust into the relays.

As to logging Envelope RCPT TO in the Header, RFC 5321 §7.2 states:

  There is no inherent relationship between either "reverse" (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the header section. Receiving systems SHOULD NOT attempt to deduce such
   elationships and use them to alter the header section of the message for delivery. The popular "Apparently-to" header field is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used.

The market has largely ignored this recommendation.


How an AP blocks Admin Page through Wi-Fi connection?

Firewalls can look across layers. Assume you're on a Linux system where eth0 is your LAN and wlan0 is your WLAN, and they're both bridged into br0. The following iptables rule would then do it:

iptables -I INPUT -p tcp -m multiport --dports 80,443 -i br0 -m physdev --physdev-in wlan0 -j DROP


Does SFTP cost more to implement than FTP?

SFTP is a completely different setup than FTP.
SFTP is a FTP over a SSH tunnel, usually using the sftp-server thats part of openSSH.

You set this sftp-server up like any other SSH connection:

you create a (system) user
add a clients public key to the [user]/.ssh/authorized_keys file
have the client connect to your ssh server using a SFTP application (sftp, scp, winscp, etc.)

Now if you mean FTPS instead of SFTP, than you have a FTP connection with TLS security. This is  (i.m.h.o) a pain to setup and use. you have to get a certificate, setup a FTPS server (I know of no secure one I would run myself) Setup users, setup permissions, setup storage location. Just like with plain FTP.


Modifying headers can be done like this:

$headers = "From: <$email> \n";
$headers .= "X-Sender: <$from>\n";
$headers .= "X-Mailer: PHP\n";

But if you want very detailed information on headers, check this out...
http://kb.mediatemple.net/questions/892/Understanding+an+email+header

EDIT: Keep in mind that spoofing your headers will highly decrease the chances of your email arriving to the user inbox, if you are unlucky, it won't even show on the receiver's spam folder.


Is encrypted email doctor/patient communication required by HIPAA, HITECH or Meaningful Use

The Office of Civil Rights is responsible for enforcing HIPAA regulations.

They released a document that addresses your question directly.   Here is the link to that document - Safeguards.pdf.   Read the answer to Question 3.

Note, in particular,  this paragraph:

  Patients may initiate communications with a provider using e-mail. If
  this situation occurs, the health care provider can assume (unless the
  patient has explicitly stated otherwise) that e-mail communications
  are acceptable to the individual. If the provider feels the patient
  may not be aware of the possible risks of using unencrypted e-mail, or
  has concerns about potential liability, the provider can alert the
  patient of those risks, and let the patient decide whether to continue
  e-mail communications.

Additional HIPAA information is available at: http://www.hhs.gov/ocr/privacy/hipaa/understanding/special/healthit/.

Hope this helps.


Is there any way somebody could hack into my brain?

No one has the technology to do so, nor do we have even close to a sufficient understanding of computational neuroscience to do such a thing. We barely understand the basic way information is encoded in neural transmissions. There is absolutely no way anyone could "hack" your brain in the manner you describe with contemporary technology. While it would be possible in theory (after all, the brain is equivalent to a Turing-machine), there is no way it could actually be done today.
Note that social engineering is still possible, which might be considered brain hacking, but it is nothing more than being really convincing and tricking people into doing things they otherwise wouldn't. It won't alter your state of consciousness nor tamper with or directly read out your memories.
As for the philosophical implications of such a thought experiment, they are off-topic for this site, so I won't be going into them. Neurophenomenology is not part of information security.


Detect host lookups against a domain/subdomain name

Is there any way to configure the domain or dns server in such a way that lookups from a host encourage that host to connect to the dns server directly or otherwise give up its IP address?

That's not how DNS works.

Usually a client only connects to a local DNS server (given by DHCP, by the ISP...) and let this server resolve the full query. This server then might do a full recursive query or might forward the question to another DNS server etc. In typical setups this means that one cannot distinguish between different clients but only between different ISP. Additionally you get requests from other public DNS server like google or OpenDNS. Only few requests will originate from inside other networks or from the clients directly because they use their own recursive DNS resolver.

Apart from that results are cached on all levels of the DNS lookup chain, so you will only detect a part of the lookups because most will be answered by cached responses already.


Preventing buffer overruns when performance is no concern

Language interpreters such as those mentioned here should be able to detect out-of-bounds memory accesses with high reliability. In exchange for this higher reliability the interpreters will run your application slower (I have no stats but saw numbers saying 5x) and will likely introduce incompatibilities with the compiled code. These incompatibilities may be due to interpreter bugs or just looseness in the language spec. You should check the settings on the compiler you use as they may have options to enable extra memory checks at a performance cost.


How to filter ciphers based on ssl certificate?

Signature Algorithm: ecdsa-with-SHA256

This is irrelevant for the choice of cipher.

  Public Key Algorithm: id-ecPublicKey

Since this is an ECC key you can use all ciphers which use ECDSA for authentication or the TLS 1.3 ciphers which are not specific to the key algorithm. Similar with an RSA key you can use all ciphers which use RSA for authentication or TLS 1.3 ciphers:

$ openssl ciphers -V ALL | grep -E 'Au=(ECDSA|any)'
$ openssl ciphers -V ALL | grep -E 'Au=(RSA|any)'

Note that above command also includes insecure ciphers, i.e. you might want to replace ALL with HIGH to get only the more secure ones.


If you are sure it's brute force/dictionary based attack against Domain controller authentication, anti-virus may not help you here. Anti-virus works on signature based strategy where as unsuccessful authentication attempts (part of attack) are just normal connection attempt without carrying any malicious data in them. So anti-virus or malware scanner will not be able to get you any information about that.

You should try finding source workstation/domain member which is launching brute force attack against your DC. And further investigation should be launched who's using that workstation depending upon attack times, valid/invalid use of creds whether it is by an internal authorized user or someone on the network trying to launch attack from unauthenticated perspective.

You can prevent this by host based intrusion detection capability where such mass attempts should be blocked by IP address or any network monitoring software that should tell you spike in traffic towards domain controller from a particular source.


Is the TPM 1.2 Direct Anonymous Attestation Anonymity Revocation Still useful for random base names?

I should prefix this by warning you that this is not an area I have a lot of experience with, but from what I've read the DAA anonymity revocation was added by the working group as a feature for potential beneficial use, but no discussion was had around what scenario might make practical use of it.

The only possible case I can think of is some kind of cross-verification system in which two separate services require proof that the same device is being used for both of them, while also maintaining some privacy via a chosen random base name for that pair of systems.

I am wholly unaware of any system which uses this in reality, and it appears that nobody has thus far had any interest in implementing it for practical use.


Is an AJAX call less secure than the normal POST method?

They are both equally secure. There are mistakes you could make in any version, but none is inherently better than the other.

What is relevant for the security of your login is the server side. You can put no security restrictions on the client, since any such restrictions could be trivially bypassed. So the important thing here is the code on the server side doing the validation. And that's the same for both options here - it checks that it's a POST request, and check if the username and password are correct.


Is it less secure to require password and phone on sign in?

Yes, this is two factor authentication, and it adds significant security.

  To me this seems like just another point of failure for a social engineer to take advantage of.

This is not adding another weak point. It is adding another layer of protection.

  We have seen plenty of people who are willing to transfer accounts into their own names to commandeer two factor authentication before.

It is not 100% perfect. Nothing is. But it is a big improvement over just using a single factor.

There are almost daily report of huge data breaches with passwords in plaintext all over pastebin. Attackers write scripts to automatically test these credentials against different services to steal valuable information. Do you think they will go through the trouble of attacking your site, when they will have to make a phone call to transfer a phone number they might not even have for every single account they want to breach? No.

I also suspect that in many countries, phone companis who just transfer a number like that without any verification could be held legally responsible. Again, just because a system has been broken under some circumstances does not mean it is completely useless.

  Also, Is what I am describing two factor authentication still? Or is it something entirely different?

Unless I am missing something, this is plain old 2FA. The password is something you know, the phone is something you have.

  To clarify, every time you login these steps will be taken. [...]

Some points here:

Make sure it is not possible to get the system to tell what phone number a user account is connected to.
Why do you have to reenter the phone number? That should already be stored in the database, right? (I am asuming each account is connected to a phone number, otherwise this is sort of pointless.)
You say that if you can't verify the phone number, the system logs you out. I would say that you should not be allowed to log in until you have verified the phone number.


I would recommend using a more established system. If you would like, gpg could definitely be used as it allows for distributed identities, provides email correlation, and is far more secure than you trying to build your own home grown solution.


What are security implications of enabling access to performance counters on ARM Cortex A9?

Very precise timing information is very helpful when doing side-channel attacks. Some famous example (in lab conditions) include stealing an encryption key used by some other process, on data we do not see (neither cleartext nor ciphertext). This can work on detection of L1 cache misses, or of jump (mis)prediction in the CPU. Forbidding access to the cycle counter will make such attacks harder (not impossible, but harder).

If you do not have concurrent processes potentially hostile to each other, running on the same CPU (a scenario which includes the case of two distinct virtual machines which share the same hardware), then there is little reason to deactivate the cycle counter.