is it possible to detect zigbee traffice via wireshark? if yes , how?

Wireshark does have decoders for IEEE 802.15.4, upon which, ZigBee is based. Before you can analyze the traffic, however, you do need a mechanism to capture the data.

You will need to acquire hardware that can capture the correct frequencies. 802.15.4 devices may use one of three possible frequency bands for operation (868/915/2450 MHz) and ZigBee operates in the 2.4 GHz, 784 MHz, 868 MHz, and 915 MHz ranges.

The are some dedicated hardware devices that can capture ZigBee traffic. Wireshark describes the following products:

IEEE 802.15.4 Wireshark USB Stick at € 199.
Exegin Q51 IEEE/802.15.4 ZigBee Transceiver at $500.

The are some other products not mentioned on the wireshark page:

Sewio UWB Sniffer at $500.

You may also be able to use a Software Defined Radio (SDR) to capture and decode the traffic. The HackRF device can cost around $330 but I couldn't find any documentation describe the decoding of 802.15.4.

A Presentation from Joshua Wright describes a KillerBee, a ZigBee exploitation framework. The presentation recommends a AVR RZ Raven USB Stick (RZUSB,
$40) for sniffing 802.15.4.

The KillerBee Framework includes a program called zbdump which has the ability to output to libcap format files, so you can then use wireshark to analyze it.


Is URL visible by ISP before HTTP request is 301 redirected to HTTPS?

Yes.

This is the reason that SslStrip works. (Okay, one of the reasons.)

HTTP is in the clear. So the 301 is in the clear as well. Anyone who's listening with e.g. Wireshark will be able to see this. (Try for yourself on the same host. It's easy.)


"Flow" between computers (Logitech mouse)

For existing known vulnerabilities look here
From Logitech site:

  Logitech Flow requires computers that can connect to each other over a local network

So Logitech software is the app you need to trust.

Make sure to connect the mouse to the most secure workstation, because this pc will be the server for all the rest. If it gets compromised - an (very advanced) hacker has a potential access to the other clients.

This traffic is not exactly 'unusual', dropbox for example is much more unusual than that. If the traffic is encrypted - most of the antivirus will not inspect that at all. By definition Antivirus should care about app activity inside the pc, not about network traffic, that inspection should be done by firewalls. Only after you "copy" a file into a pc - an antivirus on active mode should check the files you copied.

P.S. I didn't check it by myself - but if you will try to use this app on OSX while the mac is used as client - I'm pretty sure you won't be able to approve privileged messages.


Does using HTTPS, TLS, S/MIME, SSL e.t.c. protect you from Deep Packet Inspection and 'Big Data' analytics?

Deep packet inspection (DPI) is a term that commonly refers to standard network middle-men, such as the routers at an ISP, examining content at a protocol layer higher than the layer they need to in order to process the packet (thus inspecting "deeper" into the packet than necessary). For example, an IP router may need to only look at the IP layer (layer 3 in the OSI model) of the packet, but if it also inspects the application layer data (layer 5/7) then it is performing deep packet inspection.

HTTPS (referring to the wide suite you mentioned) is an application layer protocol. It will defend against deep packet inspection that reads the content of the application layer, but not against DPI at lower levels of the protocol wrapping. For example, HTTPS will not prevent DPI from looking at the TCP packet and examining the destination port to guess what protocol it is for. But it will prevent the DPI from learning the actual application data payload of the protocol.

Big Data Analysis refers to analysis performed on very large databases of collected data, but how that data is collected has little to do with HTTPS.  HTTPS is only designed to protect data in network transit, when the destination server in the HTTPS protocol reads data, the data is decrypted and HTTPS protection no longer exists. What happens at that point is up to whatever the client and server are using on top of HTTPS. Likely, the server can do pretty much whatever it wants at that point. (In other words, Big Data generally refers to Data At Rest, whereas HTTPS protects Data In Motion. Since they address different stages of the data, it makes sense that protection in one stage won't apply to data when it is moved to a different stage.)


Are any major websites offering ECDSA authentication?

Facebook

They have deployed both ECDSA and RSA certs.

See SSL Labs report

Update 2015-11-10

About 7% ECDSA support.

Hubert Kario of Red Hat Security scans (used to scan?) the Alexa Top 1 Million sites using the cipherscan tool. This is the relevant table from his 2015-06 scan:

Certificate sig alg       Count     Percent
-------------------------+---------+--------
None                      18593     3.7038
ecdsa-with-SHA256         33851     6.7433
sha1WithRSAEncryption     147349    29.3529
sha256WithRSAEncryption   320910    63.9273
sha384WithRSAEncryption   4         0.0008
sha512WithRSAEncryption   9         0.0018

Alexa Top 10: 5/5 split

Here's a snapshot of the Alexa Top 10.

Google.com: Yes.
Facebook.com: Yes.
Youtube.com: Yes.
Baidu.com: No.
Yahoo.com: No.
Amazon.com: No.
Wikipedia.org: Yes.
Qq.com: No. No SSL/TLS at all
Twitter.com: No.
Google.co.in: Yes.


Manual malware / adware analysis after SEP scan

If you are looking to do a more hands on manual analysis of malicious software, it can involve a variety of tasks, some simpler than others. These efforts can be grouped into stages based on the nature of the associated malware analysis techniques. This cannot always be observed, but in many scenarios you have an opportunity to perform manual investigation

You can start with fully automated analysis which will be the easiest. This is what is normally done by using various tools to analyze the situation and then provide the best method of resolving the issue. It will resolve the issue, but leaves little room for more attention or use of anything more analytically ideal.

When taking a closer look at the suspicious file might proceed by examining its static properties. Such details can be obtained relatively quickly, because they don’t involve running the potentially-malicious program. Static properties include the strings embedded into the file, header details, hashes, embedded resources, packer signatures, meta data such as the creation date, etc.

Looking at static properties can sometimes be sufficient for defining basic indicators of compromise. This process also helps determine whether the analyst should take closer look at the specimen using more comprehensive techniques and where to focus the subsequent steps. Analyzing static properties is useful as part of the incident triage effort.

A behavior analysis can also help when observing, Behavioral analysis involves examining how sample runs in the lab to understand its registry, file system, process and network activities.


Is there any ways to track which certificate is used for https connection in browsers?

Yeah, that sounds like IT is man-in-the-middle'ing your HTTPS traffic. Although other things could cause that behaviour also.

I suspect IT has installed root certs into OSX for HTTPS inspection. The clue is that Safari will get its list of trusted root certs from the operating system, while Firefox (and Chrome?) have their own list embedded in the program.

To check, inspect the certificate offered by facebook, twitter, etc in the browser and see if they match.

Chrome

Source

Safari

source

Pay special attention to the Issuing and Root CAs to see if this looks like some sort of internal corporate CA. (I would show you the cert I see for comparison, but unfortunately, my company also uses an internal CA to do HTTPS inspection...)


Everything that I have read explains that when requesting an access token from your authorization server you include the resource server URL as the client_id. This is then put in an aud claim within your JWT. Is this correct?

No, that's not. The 'client' is an entity that perfoms the request, and it should be identifiable and audited independently from the resource server ( and there can be multiple clients for the same resource).
OAuth 2.0 specification provides the following definition for client_id

  a unique string representing the registration information provided by the client. The client identifier is unique to the authorization server.

For resource owner flow client credentials can be skipped only if the client is not confidential (http://tools.ietf.org/html/rfc6749#section-2.1), in other case pre-registration would be preferred (client should be issued unique client_id and client_secret).

By the way, according to the specification you don't need any client credentials to refresh access token. The only required parameters are grant type (should be set to "refresh_token") and refresh token itself.

Regarding JWT token and "aud" claim

  The "aud" (audience) claim identifies the recipients that the JWT is intended for.  Each principal intended to process the JWT MUST identify itself with a value in the audience claim.

In other words it's a JWT equivalent for client_id. And the same rules as for client_id are applicable. I recommend to go into OpenID Connect specification that is build on top of OAuth and has a lot of prescriptions how to work with JWT tokens and OAuth 2.0 protocol as well as detaild explanation of JWT claims usage.

I can suggest the following options to your problem

Do not use "aud" claim in resource owner flow, as it is optional for OAuth (but required for OpenID Connect)
Issue a real client_id and fill "aud" by this value (actually depends on client type - is it confidential or not)


Someone said they have my ip and my internal ip. They threaten to post it on the internet. What should I do?

They threatened me with a “I have your up and your internal up. I’m going to send it on the internet unless you do exactly as I say” what should I do? I’m doing what they say but I’m petrified.

Ignore them and stop doing what they say!

Your public IP is not secret. Your internal IP is not unique. Ensure your OS is fully patched, and that you don't have any unwanted software installed on your computers. Move on.

There isn't really anything much you can glean from knowing a public IP. Sure, you can do denial of service attacks, but that will lead to you not being able to access the internet for a while, which is probably not too dramatic.


Is it a good rule of thumb to keep a URL as short as possible?

Yes, they should be kept as short as possible (and within a reasonable limit for public readable URLs).

There are various vulnerabilities that only affect long URLs, for example: CVE-2017-1000100 - When doing a TFTP transfer and curl/libcurl is given a URL that contains a very long file name (longer than about 515 bytes), the file name is truncated to fit within the buffer boundaries, but the buffer size is still wrongly updated to use the un-truncated length. This too large value is then used in the sendto() call, making curl attempt to send more data than what is actually put into the buffer. The sendto() function will then read beyond the end of the heap based buffer. A malicious HTTP(S) server could redirect a vulnerable libcurl-using client to a crafted TFTP URL (if the client hasn't restricted which protocols it allows redirects to) and trick it to send private memory contents to a remote server over UDP. Limit curl's redirect protocols with --proto-redir and libcurl's with CURLOPT_REDIR_PROTOCOLS.

There are other non-security or partial related to security vulnerabilities too:

Search engines, google included, have various limitations and will not function correctly if the URL is too long.
The Windows Server IIS maximum URL length is defined by the httpRuntimeSection.MaxUrlLength property. Its value is 260 characters. If exceeded,  "The length of the URL for this request exceeds the configured maxUrlLength value" error will be generated.
HTTP/2 requests may fail with too-long URLs in some cases for PHP, Apache, Varnish.


Relative URLs can be vulnerable to Relative Path Overwrite.

The main idea is that the client and the server will both parse the URL differently, so they might define the current directory differently.

For example, imagine you have a page located at /forum/index.php. Let's craft a simple URL which will be parsed differently by the client and the server: /forum/index.php/.

The server will see /forum/index.php, and / will parsed as the path info by an Apache webserver. It will define the current directory as /forum/
The client has no way to know that index.php is not a directory, so it will define the current directory as /forum/index.php/

This allows you to redirect the intended location of a link, or a source of a stylesheet / script, allowing you to escalate to more advanced attacks like XSS.


Certificate authorities: history and registration

When you refer to CAs you are really talking about CAs that issue public SSL certificates.

There is no overarching organisation responsible for managing the issuance of SSL certificates. It is left to application developers to decide who they trust, and how high to set that bar. The list of trusted Root Certificates in IE and Firefox have considerable differences.

At the end of the 90's I worked for First Data Corporation, who spent considerable time and effort to get themselves added to the Internet Explorer trusted CAs, although to my knowledge they never issued certificates to third parties. It cost many hundreds of thousands of dollars to go through the formal certification process and required that they had a suite of formal PKI policy documents (covering the life cycle of certificates).

This policy was covered by RFC 2527 (later replaced by RFC 3647) although I don't recall whether Microsoft required compliance with that RFC at the time.

More generally there are many CAs that issue certificates for other purposes. I know Skype used to be one of the largest PKI providers - PKI was used to identify users, although I am not sure if this still the case. Quite a few national identity cards in Europe include PKI digital certificates which are used to enable access C2G and B2G via smartcard readers.


Need advice on linux server being hacked

First things first. Your machine was compromised, and several things were installed to keep it compromised. This cannot be salvaged; the machine should be cleansed with fire. You will not be able to avoid a complete format & reinstall. Your system is dead; shed a tear on it, then move on.

Now, we are only talking about post-mortem analysis. The crontab visibly downloads every minute a package (the "skdet.tgz" file) which is then uncompressed and launched, and does a few... interesting things. For instance, it automatically plunders and sends by email your /etc/shadow file. You may want to download the file on another machine, uncompress it, and inspect the contents (do not launch any file in it !); it is instructive.

The package contains a "message" in which the rootkit author claims that he did not break anything and that he could help in removing the rootkit if contacted, although he does not speak about any conditions. This could be a genuine scientific experience which got out of hand; this could also be a more mundane case of ransoming.


How does sync.com provide zero knowledge for secure links?

I've only looked at this briefly, but a sync link looks like this:

https://ln2.sync.com/dl/84d6f6440#4m2d2kjd-5gvmbx6i-zb4ersxn-d585kpiw
                                 ^

The characters after the hash (the fragment) are not sent to the server. I expect the server uses the ID in the path to fetch the encrypted file, and the fragment is used as a key for client-side decryption.


In the context of a computer system being attacked, both Protecting and Defending are considered the same.

If this were a physical attack, then there would be a difference, but in IT Security both Protection and Defense are the same.

There is a term called Protected Storage, but this is not the same context

Defense could mean retaliation, where Protection would not. However, retaliation is not a desirable solution in IT Security, and is not directly effective.

In my opinion, Defense is a less desirable term, because computer systems deal in absolutes; Protected could seem more absolute, where Defended implies a finite amount of resources.

Personally, I would not use either term. Instead I would say 'Securing a system' from attacks. This is because success or failure when attacking a vulnerability is an absolute. This is quite different from physical attacks in which relate to 'strength' on both sides. DoS is an exception to this distinction.


How do I montior exactly what a program does?

My Windows "application analysis procedure" consists of the following (all freeware):

Windows virtual machine using VirtualBox to run the application.
Microsoft Network Monitor to analyze some basic network activities per application.
Wireshark to dig deeper into the packets.
TinyWatcher to take snapshots of before and after installing/running the application and "subtract" them to find out what exactly happened in the files, registry, and everything.

Please note that whole rig isn't for actual deep analysis but rather for analysis on a higher level.


What's the difference between an application-level and circuit-level gateway?

Good question. Let's think about it this way:

You're going to take a basic maths exam and the sign on the door says

  "No Masters-level students. No calculators allowed."

A normal inspector (firewall) would ask you for a student ID to make sure you're not an Masters student, then they'd let you in. A Masters student who looks just like you comes to the door, the firewall would remember that he checked him a couple of minutes ago and he'd let him in, therefor breaking the exam's security.

After checking your identity, a circuit-level gateway would've given you a watermarked paper that says you've been checked, so when your doppelgänger has to show the watermarked paper or else he'd have to go through an ID check, and his true identity as a Masters student will be revealed.

An application-level gateway, however, would've frisked you (DPI) looking for a calculator. As a calculator (application-specific command) isn't part of your identity, so it's something that sits on a higher level that the circuit-level gateway doesn't understand.

An application-level gateway understands all the protocols it supports, it doesn't care if your IP is whitelisted on the circuit-level, it can read your FTP traffic and figure out when you use the delete command and drop that exact packet. It can dissect your HTTP traffic and stop you from sending POST requests.


You are sharing IV: cells from a given row will use the same IV. This is bad. Don't do that.
You use CBC; this is a mode which is known to have a few security issues (in particular, it is sensitive to "how much random" the IV is), and it will involve padding (since CBC encrypts only full blocks, you have to extend the data elements to the next size which is a multiple of the block size).
If you modify one of the encrypted cells, then you must reencrypt it. If you use the same key and same IV, then you have lost (security wise). Therefore, you must alter the IV for that cell. If you use the same IV for the whole row (which is bad), then you must reencrypt the other cells of the row as well.
A MAC is needed if potential attackers could modify the data in place; it is not if attackers are assumed to be passive only. Note that an attacker could modify the encrypted data in order to observe how your system reacts, and try to deduce things about the encrypted data. As a general rule, you are better off with a MAC than without.

I would therefore suggest altering your scheme into the following:

Use an authenticated encryption mode with associated data which combines encryption and integrity, like EAX or GCM.
User a per-cell IV, stored in the cell itself. EAX and GCM do not need a random IV, only an IV which is never repeated (for a given key), so you could use a simple counter: maintain a system-wide global counter, incremented every time you need to encrypt a new cell value (when you allocate a cell, and also when you replace the contents of the cell); store the counter in the cell itself (that way, a 64-bit counter will be enough, no need to go to a full 128-bit value).
AEAD modes include an integrity check which is computed over the data which is encrypted and some additional data which you can choose (the "additional data" is used for computation but is not stored in the encrypted result; you must provide it again upon decryption, so that the integrated MAC can be checked). Encode in that "additional data" the row and column numbers for the cell. That way, an evil active attacker will not be able to silently swap cell contents (the MAC will be OK only if the cell contents are still where they should be).

Also, don't indulge in the "rotating master key" fantasy. The only reason why you would have to change the master key is in case it was stolen; and, in that case, you must change it right away for the whole database. No need for a smooth, gradual transition: this is an emergency situation. Therefore, no need to keep a version number for the master key. An identifier for the cryptographic algorithm, on the other hand, is a good idea; it can fit on a single byte (or even less than that).

Encrypt the binary data, not a Base64 encoding of it. Encryption output will be binary anyway. Applying Base64 on the input will just make the data 33% larger, for no good reason.


Way for two parties to establish that they are not previously known to each other

If you're assuming that either Alice or Bob could be malicious and would actively try to subvert the process (e.g. by lying about their identity or their list of "known identities") then it would seem likely that you would need a trusted third party involved.

I'd suggest that the way to go is to have the TTP involved from the start.  So if we assume that at the start of using the service Alice and Bob have no-one in their lists then the TTP can intermediate each transaction and be the custodian of the lists of who knows who (either using direct identities or using some form of pseudoname)

A challenge is what's to stop Alice or Bob from submitting another identity and then starting from scratch so to speak.  That would be harder to overcome without the TTP taking up some kind of relatively immutable identity check, to make it harder to have multiple accounts.


How to hide webresource.axd and scriptresource.axd file?

This question seems more  to fit in stack overflow.

However you can remove those files by adding following to all my web.config files

<httpHandlers>
        <remove path="WebResource.axd" verb="GET"/>
        <remove path="WebResource.axd" verb="POST"/>
        <remove path="ScriptResource.axd" verb="GET"/>
        <remove path="ScriptResource.axd" verb="POST"/>
 </httpHandlers>

Now when you try to get these pages you might be prompted to login or given 404 error.

Also remove them from  in

<system.webServer>
     <handlers>
         <remove name="ScriptResourceIntegrated-4.0"/>
     </handlers>
</system.webServer>

<location path="WebResource.axd">
 <system.web>
<authorization>
 <deny users="*"/>
 </authorization>
</system.web>
</location>


How to analyze why Chrome downloaded a particular file?

Unless you had the foresight to enable performance measurements on your system, its not possible. as for the tabs open. its possible to have chrome download a file directly from command-line (so any program on your system could have done this, not just your open tabs). also a webpage might have had an "injection" either in-between you and its server. or on the server, or on your machine. you should check your extensions, and inspect what software is actually running on your machine (is there any mal-/crap-/spy- ware present. very your result with more than 1 scanner. and USE COMMON SENSE.


What attack vector is prevented by using the 'coupling code'?

A lot of QR Two Factor Authentication codes contain data that an attacker could use to compromise you. There is a good write up about it here if you are interested. I have never used this app, and don't speak Dutch, but what I gather from the Digid website is this:

When you type the koppelcode (coupling code) into the website, it is used to encrypt the QR Code, before creating and rendering it to you. As the app knows the koppelcode, it can decrypt the QR Code, while someone who has the QR Code but not the koppelcode, can not use the QR Code.

This means that if an attacker can read the QR code sent by Digid (by means of computer compromise, Van Eck phreaking, shoulder surfing, etc.), they will still not be able to use it, as it is encrypted with the koppelcode.

Of particular note, the Dutch Government seems to be paranoid about Van Eck Phreaking; as it banned electronic voting in the 2006 National Elections due to fears of votes not remaining secret, you can read about this here.


How can I find the source of traffic allegedly originating from my IP address?

First and foremost FTP is very insecure and must never be used for authenticated file access.  It is in your best interest to never use ftp and always use SFTP or FTPS.  If a service provider only offers FTP,  use a service provider that actually cares about their customers.

Malware will attack FTP by sniffing the network looking for authentication requests and use this spread by infecting .html or or web application files.  Its is likely that your machine or another machine on your network is infected and carrying out attacks using your connection.


Can data be restored from a hard drive after using magnets to wipe the data?

The only accepted way to erase data from a hard drive using magnetism is through a process called degaussing, which involves using an extremely powerful electromagnet which alternates its polarity thousands of times a second. It is the changing magnetic field which erases data, not the presence of magnetism itself. A human being cannot rotate a magnet fast enough to effectively degauss a hard drive. Most likely, if you put a strong magnet to a hard drive, you will just damage the delicate head inside it, but not irrecoverably destroy all the contents of the drive.

So yes, data most likely can be recovered from a hard drive that was exposed to a magnet held to it by a human.


What is the problem with developing secure protocol on top of communication protocol without binding

Implementing a security layer (TLS) on top of an untrusted communication layer (TCP or UDP) without any binding could only cause problems related to protocol ossification at middleboxes (those being, indeed, MITM devices), leading to potential communication disruptions and possible denial of service for certain groups of users or networks.

This is what the QUIC protocol (the modern TLS/TCP replacement) is being designed against.

But (save for occasional denial of service problems) no other security issues could arise because the underlying communication protocol is meant to be untrusted anyway.

However, the paper you're referring to ("Authentication Binding between SSL/TLS and HTTP") tells quite the opposite: implementing a communication protocol on top of a security layer without proper enforced binding could cause implementation issues. This is called the law of leaky abstractions.

A (somewhat) simpler example of how this could happen in practice is domain fronting:

TLS — the security layer — features a concept of Server Name Indication (SNI) — a token that could be used by a client to tell the TLS server which service exactly they want to reach.

This concept and a corresponding SSL/TLS extension were developed long time ago and served the purpose of having multiple TLS services, with multiple certificates, available via a single IP-address-and-port tuple. One example where it was strongly needed had been initially shared hosting, but there were also other applications that started to make use of SNI over the years.
There's a matching concept in the HTTP protocol: the server name, transmitted as a value of the "Host" header.

The TLS server name and HTTP server name are values which come from the same namespace — known as the "Internet domain names" namespace — and in case an HTTP session is established on top of a TLS session, RFC 6066 states that both server names should generally match each other (if there’s no clear purpose and intent by the authors of an implementation to do it the other way).

However, it's up to the HTTPS server's authors to implement this constraint, as the server name from TLS layer isn't automatically inherited in HTTP session.
A common application layer protocol implementation mistake is to use TLS just for session establishment, forgetting entirely to check that the TLS hostname negotiated before matches what client now provides on the application layer.

  NB: in a large corporate or cloud network it gets even worse, because
  sometimes the TLS session is terminated on a specific piece of
  equipment — say, a balancer or a firewall — yet the HTTP session is
  being terminated far away from that.

  This way, the HTTP server gets no
  instrument at all to verify that both server names match, and the firewall
  may omit this check either.

As a side effect, also not usually meant to be present by the software developers, user can take an arbitrary TLS layer name to reach a Web site they want to access without disclosing their intent in cleartext during TLS session establishment. However, as a matter of fact, there are more side effects of this, and under certain circumstances this mistake in the code — or the infrastructure — may even result in a serious vulnerability.
For instance, when client TLS certificates are used for authentication, an attacker can circumvent the authentication by providing a server name of an adjacent TLS service which doesn't require certificate authentication, and then supplying the host name of a desired application layer service after all the TLS layer checks succeeded.

Protocol specifications and implementations usually implicitly rely on the TLS server name and the application layer name being the same, and without a proper binding here other security problems could later appear.


Can I detect when a file is copied on Windows?

Copying is just reading a file's contents and writing them somewhere else. If a user can read a file, they can copy its contents to somewhere where they have write access.

On Windows, there are copy hooks that you could use to log or block the operation, but those only apply to the shell (i.e. Explorer). Using the command prompt would bypass such hooks.

If you want to log file access, you should set up auditing. Basically, you'll need to change the SACL on the file(s) in question to log reads (use the Auditing tab of the advanced security dialog) and also change the system audit policy to record object access. To log the creation of the new file, you'll need to audit Create files / write data in the directory that will receive the copy.

It will still be very difficult to correlate a read operation with the writing of a copy if the user is even a little clever. They could read the contents into memory and wait for a while before writing it out; they could compress or encipher the data to make the copy not be the same on-disk; they could send the file over the Internet to avoid writing any new files at all. You can't really distinguish a pure read from the first part of a copy.


If you phone is seized, can you erase sim or stop them from cloning?

No you can not. On the other hand, with iOS 11.4 it will be possible to limit what a third party can do to your phone as the Lightning USB connection will go into restricted mode if you don’t use the phone for a day.

Regarding your SIM: the data on it and the access it provides is trivial to get from the phone company. If they were interested in getting SMS messages or cloning your subscription, it would be much easier to just call the provider.


What is the purpose of a fuzzer?

A fuzzer tries to elicit an unexpected reaction from the target software by providing input that wasn't properly planned for. It does this by throwing "creatively constructed" data as input to software. Expecting a phone number? Ha! I'm going to give you 1,024 characters of 0x00! Random hex! Unicode! A zero-width field! Just the punctuation: "()-"

The goal is to get an error response that isn't clean... extra access, a buffer overflow, etc. Improperly handled input is essentially the crux of just about every security problem, whether by extending into unwanted memory ranges or any number of other reactions. An SQL error came back from the phone number field? SQL Injection time!

So, for all that, fuzzers are useful in finding flaws, and particularly during a pentest for using those flaws as a point to try and launch exploits from.


How secure is using Saving Session Feature on WinSCP?

WinSCP stored site contains only a path to your private key file and no more.

So it is unlikely it can cause any vulnerabilities at all, except maybe by making the file easier to be found on your machine. However, that’s irrelevant if you do not consider threats which require physical access to your machine.


Telling the difference between firewall block or external problem with Page Cannot be Displayed (IE)

There are sites that can help you check if it is a problem with the user connection or the server:
https://isup.me
https://downforeveryoneorjustme.com

Other options would involve connecting to a VPN or proxy and checking site availability through it.

Another possibility might be a corrupted hosts file that can block certain sites or redirect user to a website hosted by an adversary.


Unless you have been directly assigned a range of IP address from the regional internet registry (faka RIR), then you are using someone else's IP address.

The vast majority of the users on the internet are in this same situation.  Typically, you are using an IP address (or range of addresses) that has been assigned to their ISP and they are in turn allowing the customer to use.

Whether your IP address is shared with other users, whether it changes, or if you have a dedicated static IP are all details that are based on your ISP and the type of service for which you are paying them.

The most basic of IP geolocation services use the information of the registered entity to which the IP range has been assigned.  If you run a whois search at a RIR for a certain IP address or network, it should either return information on the entity or which other RIR you may need to check with to find the information.  As an example, if you did a whois for 8.8.8.8 (a widely known Google administered DNS server), you will find details about Google (address, contact info, etc).  In this basic type of geolocation service, this IP would be shown to be located in Mountain View, CA.

However geolocation often gets much more involved and the exact nature of the service will be dependent on the provider.  There a numerous entities that maintain databases of geolocation information based on many other pieces of information.  This may involve information from routing tables, information gathered from devices/apps with access to GPS information, etc.  It can also tie into more than just IP address such as wireless network names, wireless BSSIDs, cellular information, etc.

Just like with search engines, the way this data is gathered and used can vary the results depending on the service.  Some may be more accurate, or some may contain old or invalid data.

So, getting back to your questions:

  When I search the geographic location of my IP address why does it show multiple cities and states that are not my own? Does this indicate someone else is sharing my IP address?

The reason you may be getting multiple cities/states may be as you indicate that this IP address may be used by more than one customer at different points in time (or possibly the same time if the ISP is using NAT).  Or it could be that the website you are referencing is pulling data from multiple geolocation databases that may be providing different results with varying degrees of accuracy.

Ultimately, you need to understand that unlike TV/movies seem to often indicate, IP address are not fixed to geographic locations.  They are fixed to entities that decide how/where to use them and may change that usage over time as they need.  Unless you can tie into an ISP's systems to know to which customer is using a given IP at the moment, you won't have a high degree of certainty of the exact location in use.


Can my employer see my browsing history with work account on my personal device

If its a personal laptop, they cant get your browsing history. Also, even if your are signed in to your work account, your search history on bing cannot be shared as confirmed by Microsoft.

"Your specific work search history isn't shared with your company or other companies, including Microsoft."

Reference:
https://support.microsoft.com/en-us/office/how-microsoft-search-in-bing-helps-keep-your-info-secure-cbce46ae-bb1f-4d0e-86f1-5984f4589113?ui=en-US&rs=en-US&ad=US


Must one have SSL certificates for each domain, to use HTTPS?

I feel like a primer on how TLS works might answer some of your questions. We have a canonical question here for that:

How does SSL/TLS work?

The part that's relevant for your question is that in order to do TLS, the server must have an encryption private key.

This key is private, meaning that no copies of the key should exist anywhere else, so we can use it (and the corresponding public key) to uniquely identify the server.

Consider a browser visiting your site for the first time - how does it know that it's talking to the real yourdomain.com and not an attacker trying to spoof your site?

That's where certificates come in: a Certificate Authority issues a certificate to say "we have verified that this public key does in fact belong to the legitimate owners of mydomain.com. Browsers take this as proof that they are talking to the authentic server for that URL / domain.

Browsers require every server to present a valid certificate matching the domain requested for each TLS connection, and (in theory at least) each server should be using a unique keypair and certificate.

TLS is a bit tricky to wrap your head around, and getting a cert from a CA and installing it properly can be a bit fiddly, but if you follow your guide you should have it up and running in a day or two.


Why can 'Others' read files by default in Ubuntu?

The permissions model of Linux means that, even if you are the only user of your computer, you're not the only user on the system. Many services will create their own user account to run under - for example, Apache will usually run under its own dedicated account.

What you will also notice is that your home folder is usually only accessible to your own account - i.e. permissions 700 or drwx------. That means that only you can get at your home folder, even if subfolders within that folder have full access.

This combination provides a useful balance. The default permissions allow service accounts to read any files on the system that they might need to, but they can't change anything. Any files which are personal to you should be in your home folder, so a rogue service won't be able to access them.

You might find the Filesystem Hierarchy Standard a useful read. This outlines the generally expected permissions and functions for Unix/Linux systems, and most distributions will abide by this.


How to create email that will fool DKIM verifier?

First, nice question. I've checked how Thunderbird behaves by modifying an existing mail and it actually takes the first headers for display of From, To and Subject while the DKIM signature mechanism starts from the end :( . Thus the DKIM signature is considered valid even though From, To and Subject are spoofed. Interestingly the first From line is only used in the mail view while in the list view of all mails it shows the last From line.
As for other attacks or how the attacks you've described can be used in in a way you might not have realized:

There are some mail headers which have interesting side effects and often these headers are not fully protected (i.e. protected against change or against adding a new header). Notably Content-Type and Content-Transfer-Encoding have special meaning on how the content gets interpreted. Manipulating these headers can have interesting effects. For example having a Content-Type multipart with a non-existing boundary causes Thunderbird to no longer show the original text of the mail but instead a blank content. When combined with spoofing the Subject ("download update from hxxp://...") and/or the Reply-To this unexpected blank content can be used for a social attack. Example:

 Subject: Blank mail? Download hotfix for your mail client at http://....
 Content-type: multipart/mixed; boundary=boundary_does_not_exist
 Subject: original subject
 Content-type: original/type

Similar changing Content-Transfer-Encoding to base64 for non-multipart content can cause it to display only gibberish which can be similar used in a social attack. Example:

 Subject: Mail corrupt? Download hotfix for your mail client at http://....
 Content-Transfer-Encoding: base64
 Subject: original subject
 Content-type: text/plain

If the DKIM signature uses l= to limit how many lines are used in the body hash one can also "replace" the content of mail by changing (or adding) the Content-type to some multipart type with a special boundary. The boundary is then designed to skip over the existing content included in the hash which will be treated as the preamble for the new MIME parts (and thus will not be shown). Example:

 Content-type: multipart/mixed; boundary=my_own_boundary
 DKIM-Signature: ... bh=...; l=...
 Content-type: original/type

 here is the original content, no matter if single part or multipart
 this is the last line included in the body hash

 --my_own_boundary
 Content-type: text/plain

 Only this text is shown at the recipient
 --my_own_boundary--

  ... uses a l= tag (most ordinary emails usually don't)

Actually I was surprised how many DKIM signatures with l= I've found in my mailbox. Notably mails from cisco.com use(d?) this feature and I've used one to successfully replace the content in the way I described while keeping the signature valid.

Apart from modifying an existing mail from Sammy the attacker might also be able to create a new mail to Rita which looks like it came from Sammy. This can be done by creating a mail with a valid DKIM signature and then add a faked From header on top. If Rita just checks if the DKIM signature is valid she will not see any problems. If she additionally checks if the signature domain matches the senders domain the result depends on which From header is used for this validation. But if Sammy uses one of the public mail providers the attacker could simply get also a mail account there and then it would not matter which From is considered when checking the domain because both are from the same domain.

EDIT:
The question here resulted in some larger research in 2017 where I've showed how mails can be modified without breaking the DKIM signature in real-life. See Breaking DKIM - on Purpose and by Chance.


Obtaining an SSL certificate for a local web application

Is there a way to obtain a certificate for this application so that there's no error?

From a public CA you can only get certificates which are for public sites, i.e. neither internal domains nor internal IP addresses. And usually you don't get certificates for public IP addresses too.

  I will also have to distribute this application to clients, so the certificate must be either portable or easily renewable.

What you are trying to do is a very bad idea since this means that all installations share the same certificate and private key. An attacker having access to one installation can thus impersonate and silently man in the middle other installations.

I have no idea of your exact use case. But some use cases of shipping a https enabled system to customers is to use self-signed certificates (each system gets a different one) where the user has to add an exception to the browser and/or the ability for the customer to upload its own certificates.


File Shredder
The File Shredder is actually useless. It only gives an impression of security. It can be useful only in a very rare case when file was write to the disk once and has never been copied. In the reality there can be multiple copies of the whole file or copies of its fragments. Just a few examples:

A file was written to the disk then was edited. An editor can create multiple snapshot of particular file versions or snapshots of file parts. What you see is the most recent version. The data from previous versions can remain on the disk for a long time. If you have much free space on the disk, then the probability is high that these copies or their fragments remain for a long time. The File Shredder does not know anything about previous versions and will not delete/overwrite their data on the disk.
If you opened the file in some application, it was loaded into memory, the whole file or some parts of it. If the operating system swapped memory later on, then the loaded part of the file was written to the disk. Thus the data from the file can remain on the disk for a long time. The File Shredder does not know anything if memory with file content was written to the disk.

Overwriting
The files that were just deleted in the Windows File Explorer can be restored in many cases by many advanced users. There are free and commercial tools for this. But if the data were overwritten at least once, restoring such data can be very expensive, because this needs special expensive equipment. Only some companies and government agencies can afford such equipment. Besides the necessity to have the expensive equipment the attacker need to disassemble your disk. That's why if you want to protect deleted data from "normal" attackers that don't have such expensive equipment and don't have possibility to disassemble your disk, then a single overwriting will be sufficient.
Just think what value your secrets have and who can be interested in paying a lot of money for buying or renting special equipment, who can be interested in stealing and disassembling your disk. If you believe that nobody is going to pay a lot of money for your secrets, then a single overwriting will be sufficient.


A OTP can be done by created, copied, and used to encrypt and decrypt by hand.  There is however no revocation so if 4 parties shared the same OTP there is no way to kick one party out short of destroying the pad and making a new one.

There are also some significant security limitations:

The pad must be random.  This would be the hardest thing to do without high speed electronics but a small pad could be done using dice for example or using PRNGs prior to the SHTF event.
Each party will need a copy of the OTP which if not made prior to SHTF may require a lot of manual copying.
Each symbol in the pad can only be used once (1 letter in pad = 1 letter in plain text).
If one copy of the pad is compromised then all are compromised.
Some coordination is necessary to ensure two parties don't both encode a message using the same page from the OTP.  In a two party system a simple way is for one party to encode starting from the first page and the other to encode starting from the last page.

The word comes from the fact that original OTPs were small notepads with multiple sheets containing a couple hundred letters per sheet.  When a message was encoded (1 letter from OTP per letter of message) the current sheet was torn off and destroyed to ensure it wouldn't be used again or used by an adversary if the agent was caught.

Due to the limitations you aren't going to want to use an OTP by hand to encrypt novels but for brief urgent messages it would be completely unbreakable by cryptanalysis even if the adversary still had high speed computers.   Actually it would even be unbreakable even against quantum computing.


Can a rogue DNS server see my passwords?

Not directly, but they can collude with other agents to see passwords sent in clear-text.

All that a DNS server is used for is mapping a domain name to an IP address. So DNS servers will never see data you communicated between you and a website. They just aren't involved in that part of the communication.

That said, a DNS server can incorrectly return an IP for a website that is running a phishing or similar scam. You might then enter your credentials into that fake site. This is easy to do as your URL bar will state that you're visiting your intended destination site even though you are visiting a scammer's site.

So, a rogue DNS server cannot steal your passwords, but a rogue DNS server in cahoots with a phishing site can certainly steal your credentials.

If you are using HTTPS and don't blindly click through security logins, HTTPS will ensure that you are talking to the real site and not a phisher.


Is it a bad idea to use base-64 encoded strings for passwords?

All questions of the type "Will this clever trick make my password any safer?" depends on the same thing: What passwords does the attacker try first when brute forcing the hash? The person attacking you is not stupid, and she will try the things that are most likely to succeed first, and the less likely ones later.

Unless the attacker is specifically targeting you, and knows about your encoding scheme, she is more likely to try the unencoded password before the encoded password. So in that sense, this is a win for you (at least until everybody starts doing it and it gets so common attackers starts trying this kind of thing early).

But is it very practical? Are you going to memorize the encoded string? Then why not just memorize something random (and thereby safer) instead? Are you going to use some online service to encode the password every time you use it? Then you might have it sent over HTTP and recorded in logs all over the internet, and thats not very good. So are you going to install some software thad does the encoding locally? Then why not just install a real password manager instead?

So yes, in a narrow sense UGFzc3dvcmQ= is a better password than password. But no, this does not alleviate the need for completely random passwords and password managers.


Are there any alternatives to EFS for transparently encrypting the contents of a folder in Windows?

I don't know if this is possible in your context, but I'd say that you want to use Container-based encryption.
That way you create a container file (using VeraCrypt/TrueCrypt/BestCrypt/...) which you mount as a new drive afterwards. The mounted drive can be used transparently for data accesses.
If you can't move the folder you want to encrypt, than you can still use container-based encryption, but add a junction point pointing to your encrypted (virtual) drive.


One remark on that:

  now clients can't deduce what they can do or if their token still active

The safest way to store the JWT is probably in a httponly (to prevent XSS) secure cookie (+ take measures against XSRF). If you do that, client-side code can't directly check the JWT anyway.

As for your initial question, I guess it can help give more control over revocation / session expiration. If you hand out the JWT to the end user, you are powerless until "exp" is reached (and this parameter has been decided by the issuer, which might not align with your own policies). With the opaque identifier, you keep control and can revocate access anytime. In a way, you keep old fashion session management while still leveraging JWT for delegated authentication.

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

  Unlike sessions - which can be invalidated by the server whenever it feels like it - individual
  stateless JWT tokens cannot be invalidated. By design, they will be
  valid until they expire, no matter what happens.

http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

  For a stateful service, you hand out a new short-lived, single-use
  token for each service - which is then exchanged on the service
  itself, for a session on that specific service. You never use the
  token itself as the session.


Reminder: Reset your password - phishing or genuine Facebook email?

A simple way to check is just to get them to send another password reset and see what the links used for password recovery are, it would also be useful if you checked your emails and see if you did request one a few days ago, or check the trash folder if you deleted it. Here's the reset email they sent me:

> Hi ****,
>
> You recently asked to reset your Facebook password. To complete your
> request, please follow this link:
>
> https://www.facebook.com/recover.php?n=******&id=********&s=***
>
> Alternately, you may go to https://www.facebook.com/recover.php and
> enter the following password reset code:
>
> *******
>
> Please note: for your protection, this email has been sent to all the
> email addresses associated with your Facebook account.
>
> *Didn't Request This Change?* If you did not request a new password, let us know at:
>
> https://www.facebook.com/login/recover/disavow_reset_email.php?n=******&id=*********
>
> Thanks, The Facebook Team

The links actually point to what they say as well so it does seem Facebook use www.facebook.com/recover.php for their resets.

You can also look at the email headers, in particular the authentication results which check if the senders email actually comes from their domain, my email in Hotmail showed:

> Authentication-Results: hotmail.com; sender-id=pass (sender IP is
> 66.220.155.140)

And you can check that IP resolves to Facebook as well: https://ipdb.at/ip/66.220.155.140


Is there a PCI Requirement for shuffling digits while accepting PIN?

There is no fixed requirement to do this, in any standards I am aware of.

I understand the thinking behind it - you'd think it could make it harder to shoulder surf, however in my experience it makes it easier to shoulder surf, as the person keying in the code will now need to check visually for each digit, rather than being able to type them in from memory.


Are invalid card numbers under PCI compliance

If a non-valid card was exposed, who is at risk and whose date has been exposed? Since its not a valid card, there is no "card holder".

In the intro the the PCI DSS 3.0:

  The Payment Card Industry Data Security Standard (PCI DSS) was
  developed to encourage and enhance cardholder data security and
  facilitate  the broad adoption of consistent data security measures
  globally. PCI DSS provides a baseline of technical and operational
  requirements  designed to protect cardholder data.

If it's an invalid code because the LUHN does not pass, it does not start with a valid bank identifier, it cannot be issued to a client. It's likely not on any piece of plastic with a card brand logo. PCI only applies to cards with a brand logo.

However, if the same source (merchant) can send both invalid and invalid cards, it would have to assume the card numbers are valid until checked, which means the normal encryption protections, etc would need to be followed. If for some reason you had a separate channel for invalid numbers, non-issuable test numbers, those should not fall under PCI, however, with everything in PCI, always check your friendly QSA.


Why do people hide their license plates in the EU?

It's a matter of privacy.

The thing you definitely determine from the license plate in some countries is the county of the registered car. In small countries some counties have a small number of registered vehicles and that eases tracking one.

Other things you may be able to determine in quite a lot of EU countries:

year of birth of the owner (since some use 2 number character in the plate number)
name of the owner (since many use the 2 or specially 3-letter abbreviation of their name)

Example: a car in Romania with the number CT-90-GEO will give you quite good information: the location of the registration is in the Constanta county (abbreviated CT for vehicles) and the owner is named George and was born in 1990.

So many people prefer not to release something like this in the wild.


Given SSH access, what should I do to protect a server and monitor (dangerous) user actions?

If users must have SSH to your server, a useful tool to protect your server root is chroot - this will let you give them the apparent functionality of server root, without actually giving them the crown jewels.

Alternatively, as you use virtual machines anyway, why not provide them with virtual server instances?

Both of these will allow you to run monitoring tools (such as tripwire) in order to check for changes to files. Logging should be done outside the users' environment.

With entries in /etc/sudoers you can limit what activities users are allowed to carry out under su.


Household attack vectors and mitigations

What threats should I be wary of concerning physical security of a home?

Let's start by your use of a branded (or even worse a non-brand) "smart" camera. As you noted regarding NEST and other vendors (Ring), all of them work using their own cloud service. For you to get a push notification that something has moved in your garden, the camera reports to the cloud and the cloud pushed the message to you (among other things like save your recording etc.). By itself, if you are really wary for your privacy I would suggest you refrain from using those solutions. Regardless of whether they were breached or not, anyone with access to your cloud account (let it be an hacker, "the man" or the cloud provider) will be able to see the recordings (e.g. for Alexa, google assistant and Siri, all respected vendors disclosed that there are people listening to what you say in order to enhance their voice detection techniques).

If you decide to trust those vendors (which to be honest i would, for externally facing cameras), than the implementation is simple and straightforward.

If you decide to do that on your own (connecting a dumb camera into a raspberry Pi) than you will need to code your way to detection, notification and alerting (there are several open source projects that can help you). In my view that would be the most secure option as those cameras would not be connecting anywhere outside of your network and will not receive any communications from external locations so they would be easy to segment them and whitelist traffic based on your preference).

  What threats are there to my home network?

That's a 10 page academic research paper grade question. But in short:

Wireless Network: If you expose your SSID (or even if you are not with the right tooling) people can identify your network and attempt to hack it. to reduce that likelihood, first hide your SSID (only people who know your SSID or use advanced sniffers will be able to detect it. Secondly, use a strong access password or a certificate to access the network.
Router Security: make sure you change the default username and password, and periodically check if there are firmware upgrades for your router. if you are still after better security, use the router provided by the ISP as a pure modem and buy a branded router with extra features (from cheap netgear routers to SMB grade checkpoint firewalls)
Firewall and other security features: make sure you enable all those features, prevent any inbound traffic in your router.
Create a guest wi-fi network for your visitors -> they shouldn't have access to your home network and they can be completely secluded.

Hope that would get you started in the right direction.


Would the Cloudbleed have been prevented if Rust was used?

From the detailed description of the bug it is visible, that they've used already a high level tool to create code but that the did not use the tool properly. To cite:

  The equality check is generated automatically by Ragel and was not part of the code that we wrote. This indicated that we were not using Ragel correctly.

Thus, would Rust have prevented to use a high level tool improperly? Probably not. But if the tool would generate Rust code instead of C code, would then the buffer overrun have been detected? This is likely since protecting against buffer overruns is one of the goals of Rust. But since the tool does not generate Rust code one cannot say for sure how this code would look like and if it really would have been prevented the problem.


Is the OWASP recommendation regarding localstorage still valid?

Personally I see no issue with using local storage as long as you are happy with the user not having to re-authenticate between sessions. The linked answer provides the following argument against this. I would argue it is very weak -

  Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

This applies with any kind of authentication token. Someone local with admin privileges (assuming its not encrypted with a key tied to the users credentials) can read it out of any kind of storage, RAM or maybe even straight off of the network.

He also suggests -

  (or XSS flaw in the website)

Again - this applies to any kind of token that the JavaScript can access.


windows security alert windows firewall has blocked some features of this program message coming for every new build of my application

This is by design in the windows firewall security model - if it thinks the application has changed it doesn't know whether that is a malicious change so reverts to the default 'block' until a connection is approved by the user.


Can a country block your website for using SSL

Countries like China, Iran or North Korea are known for their strict control of the internet. The ISP are controlled by the state and techniques like deep packet inspection are used to control what gets transferred. With TLS only the meta information like domain and target IP address are visible and traffic control can only be done based on this. While thus the actual payload is protected it also means that the chance of overblocking is higher since thed ISP cannot be sure that they content of the site if harmless from the perspective of the government and because of this might block when in doubt.

  Last but not least, is there any solution to use SSL and not being blocked?

It is unknown why your specific site is blocked. It might be because the domain name suggests illegal content. It might be because the IP address is shared with other sites which are blocked because of their content. It might be because you use a CDN which supports domain fronting to bypass censorship. It might be because your site is too small to be considered for explicit white-listing and since the actual content is unknown it is blocked to be on the safe site. As long as you don't know why the site is blocked you likely cannot adapt your hosting so that it does not get blocked anymore.


What is the main risk of allowing services to logon as NT AUTHORITY\SYSTEM?

Worst case scenario

When an attacker exploits an application to run arbitrary code then this code will run under the context (and thus the privileges) of the exploited application. So if the service running as SYSTEM has a listening port and is exploitable from the internet or network then the attacker can do pretty much anything on the computer, including adding new administrator accounts or dumping passwords and certificates using mimikatz

Privilege escalation

If the application isn't listening on a port, or isn't exploitable using that port, then the service might still allow the attacker to elevate privileges. this requires the attacker to have some lower privileged access first, like through exploiting a lower privileged application or user.

To attack the service this way the attacker usually needs to look for misconfigurations in the service itself, rather than the application. He can try to edit the binary (exe file) of the application and then restart the service, try and edit the path of the service (thus editing what exe is executed when the service boots up). Or he can try DLL hijacking just to name a few.

If one of these attacks succeed, he can run code in context of the application and thus as SYSTEM. To minimize this risk, run applications on the least amount of required privileges possible, if the service doesn't need to run a SYSTEM then doing so poses an unnecessary security risk.


How can I store downloaded video securely to device's sd card?

You have the right instincts.  Everything on the SD card is readable by every application, so the best solution is to encrypt the file before storing it on the SD card.

I am assuming you are asking from the perspective of an application developer, and you want to know how to implement this protection in your app.  If so, one simple approach is to encrypt using AES-CBC mode (with a random IV), and then take the resulting ciphertext and append to it a message authentication code using AES-CMAC.  You will need two separate (and cryptographically random) AES keys.  You can generate the keys with java.util.SecureRandom.  You could then store the keys in app-private storage (not on the SD card).  Hopefully this should be pretty straightforward to code up.

If you are asking from the perspective of a user, then you'll need to provide more information about what you are trying to achieve.  If you just want to store the video on your cellphone, but not view it on your cellphone, then one possibility is to encrypt it using GPG (or PGP) on your desktop, then download the encrypted file onto your cellphone; when you later want to access it, copy it off your cellphone and decrypt with GPG (or PGP).  On the other hand, if you want to be able to view it on your cellphone, you'll probably need to explain what you mean by "no other application or user can use it, outside the application or on any other devices" (e.g., what application?).


Http request can't capture from wireshark

Wireshark doesn't show you all the network traffic in a network. It shows you the network traffic that arrives on or leaves one of your computer's network interfaces.

So if you send an HTTP request to one of your team's computers, or if one of your team members sends an HTTP request to your computer, wireshark on your machine will pick it up. But wireshark can't pick up requests that don't pass your network interface.

You can put your wifi network card into promiscious/monitor mode to capture all packets in the air, even if they're not meant for your machine, but wireshark alone can't do that. So if you can't see packets not targeted at you, the reason is that your wifi adapter is not in monitor mode and by default filters all packets not targeted at you.


Do not roll your own cryptography

There have been multiple attacks on SSL/TLS which have been developed by the wider industry and been through scrutiny and testing. Don't build your own, stand on the shoulders of giants.

If this is an intranet project check to see if you have an internal CA and get an issued certificate from this. Don't use self signed certificates as well your weakening your own security by doing so. Anyone can issue them and then man-in-the-middle your traffic.

Also why is the IV unchanged? An IV should be regenerated each time its used.


Why using oAuth2 refresh token is more secure then regenerate an access_token?

It is for user convenience. Having to enter their login credentials too often is annoying to users. Of course, if that is not a concern, you can just not use refres_token, which would improve security somewhat. However, users generally dislike logging in often and forcing them to may cause them to do something insecure, such as storing password in browser or disabling 2FA, hence the use of refres_token.


Based on this question and its answer, you have to do the following:

remove iptables entries.
arpspoof -i wlan0 -t 192.168.2.117 -r 192.168.2.254
arpspoof -i wlan0 -t 192.168.2.254 192.168.2.117

notice the -r flag.


What possible attacks might occur on a SQL Server TCP/IP port?

"and created another user with a very complicated username pattern,
  say HlsvslEWlajxcqpe and also a complicated password."

This will mitigate brute force efforts, but won't help you if someone manages to inject code in your application that exposes where these credentials are stored. They will be able to log right in, presumably from anywhere.

For starters, you need to block all access to this port from all hosts except those related to your application.


Storing only BIN part of PAN, does this qualify as a full PAN?

Storing only the BIN part of the PAN does not qualify as a full PAN. When you are thinking about PAN storage, you have to consider Requirement 3: Protect Stored carholder data. Your question is answered by requirement 3.4 (this is an extract of the navigating PCI-DSS document):

  3.4 Render PAN unreadable anywhere it is stored (including on
  portable digital media, backup media, and in logs) by using any of
  the following approaches: One-way hashes based on strong cryptography (hash must
  be of the entire PAN), Truncation (hashing cannot be used to replace the truncated
  segment of PAN), Index tokens and pads (pads must be securely stored), Strong cryptography with associated key-management processes and procedures

What you are trying to do is referred as "Truncation", limited to the first six digits:

  The intent of truncation is that only a portion (not to exceed the first six and last
  four digits) of the PAN is stored.


Are GPG Tools Keys Just Plains GnuPG Keys?

GPG Tools is a distribution of GnuPG with some front end and integration addons. All key management and cryptographic operations is handled by GnuPG. You can also verify this by running gpg --list-keys on the command line, which will show the same keys the frontend tools know of.

Furthermore, GnuPG does implement the OpenPGP specification, so I'd rather call those keys "OpenPGP keys": they're also interoperable with other implementations of OpenPGP (PGP, OpenKeychain, the Monkeysphere development library, ...).


Assuming stored XSS were possible, the stored XSS could use the echo endpoint to present a phishing version of the site (since further XSS resource loading through the echo would be permitted and trusted due to the same origin it was coming from).


I'm assuming you are using some proprietary authentication solution, which is using JWT and refresh tokens but has nothing to do with OpenID Connect.

JWT tokens are stateless, refresh tokens are usually statefull.

You should look at advantages and disadvantages of statefull vs stateless tokens:

Stateless tokens can be validated without extra DB/Service call (so they are faster/easier to validate) but it is impossible to revoke them (no reliable logout).
Statefull tokens may be revoked (reliable logout) but they must be validated via DB/Service call each time (so they are slower).

Long-lived JWT tokens would constitute an increased security risk - attack window would be long if token is stolen.

In combination with refresh tokens, you get the solution somewhere in the middle: Validation is fast and logout is more reliable.

Depending on where which token is used (client vs server), you could implement automatic refresh. However, for such proprietary solution, you could indeed use a single token with a validation cache if necessary due to performance reasons.


This is relatively simple if the two ends of the network path are either:

On two different phases of the building's 3-phase supply
From different power supply cabinets

It is possible to filter out the high frequency components that the signal uses, leaving only the 50 (or 60) Hz mains supply - in fact many power smoothing components do this by default. It is cheap and simple.
In this instance, because you have a dedicated phase, it becomes very easy. In reality very little signal crosses between phases. There could be some, but it will be miniscule. Filter high frequencies from either phase, and the likelihood of getting any signal on one of the other two is effectively zero. See my other answer at https://security.stackexchange.com/a/9728/485
The wider solution, however, is to define in policy or contract that this is not allowed, and then track down breaches of policy and do whatever is necessary - this may be disciplinary action. Detection of signal is relatively easy, as the frequency hopping signal is obvious to spot on a spectrum analysis - although as most Powerline uses encryption you may not be able to identify what the traffic is.


Validating API keys in a back-end web-service with very few users

Clarifying Assumptions
I've asked some clarifying questions in comments. I'll answer assuming the following:

Traffic within your backend is plaintext (ie no TLS).
The API key is sent in plaintext in the basic auth field, and hashing is performed by the server only in order to compare against the stored value.

Hashing and Salt
I fully agree with this statement:

I considered doing a more typical password-hashing method (e.g. Argon2) but since the password is not intended to be human readable, it doesn't seem like much would be gained. Even salting the value doesn't seem like it would be very valuable since the space of possible API keys is so large.

Yup. Salts are an answer to humans choosing passwords with very low entropy. API keys with 128-bits of entropy don't need salts, and a single iteration of SHA-256 is good enough to obscure the key.

Sniff protection
The way I'm understanding your question, it probably is not getting sniff protection. ie it sounds like someone who can sniff backend network traffic could lift the API key out of the HTTP req.
Suggestion 1: client-auth TLS
My first suggestion would be to set your front-end server up with TLS client certificates (and locally-stored private keys). Write a filter at the back-end server to check that the client presented the client cert that you expect (there are some gatcha's in implementing validation of client certs, but that's beyond the scope of this question).
That said, from your description, it sounds like TLS might be too CPU-consuming for you.
Suggestion 2: challenge-response / zero-knowledge-proofs
If you phrase your problem a different way, it could become "The front-end server needs to prove that it knows the API key without sending the API key over the network".
That sounds very similar to the definition of Zero-knowledge proof [wikipedia]:

The essence of zero-knowledge proofs is that it is trivial to prove that one possesses knowledge of certain information by simply revealing it; the challenge is to prove such possession without revealing the information itself or any additional information.

I believe (but am ready for comments proving me wrong) that you could do an interactive ZKP by having the back-end send down a salt (probably of the same length as your API key), and the front-end send back the salted hash of the API key.
For more reading on ZKP's, see wikipedia: https://en.wikipedia.org/wiki/Zero-knowledge_proof


MVC 5 and Multiple AntiForgeryTokens: What is happening?

I thought the AFT in the cookie and the one in the form were supposed to match.

You were wrong! they doesn't need to be equal - However, they have some cryptographic relations with each other...

Here you can find detailed info about this feature and how it works...


Find information about host/user by his public key?

Yes, you can, if the user sends a public key. You can use a tweaked SSH server to grab the public key, and check it against whatever database or API you like. Problem is, you probably be able to use this as a real SSH server, so you'll probably want to move your real service to a different port.

Even if the key isn't available through some API to identify the user, the comment after the key may contain clues (e.g. skiddie@l337machin3). Edit: actually, I doubt that this field is sent to the server at all, but I'd have to check. In that case, this can be ignored.

Also, unless the attacker is unskilled, I doubt they would be using their personal keys for attacking random hosts.


Can encryption twice with two keys in different sequences lead to the same result?

You may use any symmetric encryption which works by generating a key-dependent stream of bytes which is then XORed with the data to encrypt. This is the case of most stream ciphers; this also applies to a block cipher in CTR mode (which practically turns a block cipher into a stream cipher).

Such ciphers are a bit delicate to use, because you shall never reuse a given key-dependent stream (that would be the infamous "two-times pad"). This means that either a given key will be used to encrypt only one message, or that you use a stream cipher with an initialization vector which will need its own management. Crucially, in your case, this means that potential attackers should not be allowed to observe E(k1,t), E(k2,t) and E(k1,E(k2,t)), because this would enable them to recover t (namely by XORing all three streams together).

If your specific scenario make the stream cipher solution inapplicable, then you would have to use more esoteric solutions which are non-standard, thus cannot be recommended in practice (but are fine for research). For instance, given Diffie-Hellman group parameters (a modulus p, and a generator g which is such that gq = 1 mod p for a prime q which divides p-1), a subgroup element (a gx for some integer x) can be "encrypted" with key a by raising it to the power a (E(a,h) = ha mod p). "Decryption" implies raising to power 1/a mod q (inverse modulo q is computed with the extended euclidean algorithm). With this "encryption" algorithm, you get the commutativity you look for (E(a,E(b,h)) = E(b,E(a,h))) AND you can publish E(a,h), E(b,h) and E(a,E(b,h)) without revealing h.

... but that's just a variant of Diffie-Hellman. The good question is then: why do you want your commutative encryption thing ? What are you trying to do, that Diffie-Hellman cannot do ?


How to conceal a computer in operation with a separate logon password?

This can be easily done with RDP and Windows 10 Pro. Just set it up normally, and then you connect via RDP. There will then be 2 sessions on the computer, one console, that is visible to the local user, and one remote RDP session, that is only visible to the administrator.

The administrator session can be taken over from the local console, but only if you know the administrator password.


TLS version of cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA

OpenSSL has only three categories of 'cipher' for SSL/TLS (really ciphersuite, and not to be confused with EVP named ciphers used among other things in openssl enc which are quite different):

SSLv2 uses the SSL2 encoding (3 bytes) and is usable only in SSLv2 (which of course you shouldn't use at all, and by default is #if'ed out at compile time in recent versions)
SSLv3 which uses the SSL3 encoding (2 bytes, which is the same for TLS1.0 through 1.2) and the record formats defined in SSL3 (GenericStream and GenericBlock which is actually CBC) which are essentially unchanged in TLS1.0 through 1.2 (except 1.1 and up fixes the exposed-IV problem reported by Vaudenay and exploited by BEAST)
TLSv1.2 which uses the same encoding as SSL3 but the record format for AEAD (update) or HMAC-SHA2 which both exist only in TLS1.2

As a result of this categorization, OpenSSL supports using the export cipher suites in TLS1.1 and 1.2 even though 4346 officially deleted them (along with the special export KDF), and the single-DES and IDEA suites in TLS1.2 even though 5246 officially 'deprecated' them -- but only if they are supported at all (which in recent versions most aren't by default) and only if the peer agrees (which most won't).


From what you described, it's not secure at all, for a bunch of reasons. The top two being:

You're downloading data over HTTP. Even if AES provides confidentiality, it doesn't provide message authenticity or integrity.
You're using hard-coded keys. Pulling those out would be trivial, even with obfuscation. This would mean I could MitM your traffic and send arbitrary binaries to take over the system.
You're relying upon obfuscation of the process for security, which is in violation of Kerckhoffs's principle.

The good news is that there is a proper way to do this, with asymmetric cryptography:

Generate an RSA key pair.
Store the public key components within your application.
Hash the assemblies on the server-side and sign that hash with the RSA private key.
Deliver the signed hash and assemblies over HTTPS to your application.
Hash the downloaded binary, then use the public key to verify the hash against the signature.
If the signature matches, you're safe to use the binaries.

You can do all of this with RSACryptoServiceProvider. I recommend using SHA256 for your hashes. I also recommend checking the strong name of the binaries even after you've verified their authenticity, just for peace of mind - you could extend this further by using Strong Name Signing.

A really simple verification routine might look like this:

bool VerifySignature(byte[] file, byte[] signature)
{
    using (var rsa = new RSACryptoServiceProvider())
    {
        rsa.ImportCspBlob(PublicKey);
        return rsa.VerifyData(file, CryptoConfig.MapNameToOID("SHA256"), signature);
    }
}

Where PublicKey is a byte array containing the data exported by rsa.ExportCspBlob(false) on the RSA instance that generated your key pair.


Does using VPN or encryption on an Android phone do anything since Google knows who is logged into the phone?

Specifically regarding VPNs, they are often marketed as a panacea to solve all security and privacy problems. While they can solve some problems, unfortunately much of it is just false hype and exaggerated for advertisement purposes.

VPNs protect network transit point-to-point from your device to the VPN server. They do not protect against anything outside of that. Google runs apps and services on the device that can collect data such as location (using GPS and nearby WiFi networks) and other usage data (browser history, app data backups, etc.). None of these things are affected by your network setup (e.g. VPN); as long as there is a working connection, things will be reported back to Google.

The only way to avoid Google tracking is to not use Google products. There are custom Android distributions (custom ROMs) that completely eschew Google's proprietary services, but many apps that rely on these services will break. Or, you could try to use an adblocker to block all Google related domains, but this would be very difficult.

Of course, you can't completely escape Google since they do all sorts of active and passive tracking across the internet.


Concept using ssh to create dynamic firewall. Good or Bad idea?

Create a secure process to open a firewall port on a server (on
  demand) start a listening server, and ultimately close the firewall
  port.

Your goal seems flawed for many reasons. This would not be scalable in an enterprise environment due to the lack of available ports that could blossom on a heavy day of visits/work. You would always have to have multiple firewalls in round-robin behind load balancing. Further, your firewall would need all types of ASICs to make it work making it a pretty expensive firewall. On the DoS side of the equation, you're wrong. Sending 10gbps to any socket opened or not will kill a 1gb connection regardless of how many drops/rejects (which are not a good idea), that you envision making. The BETTER logic would be to configure your router to only accept connections from trusted sources, and block all of the remainder.

I won't even get into the statistics of client side exploits, phishing, and other attacks your firewall won't stop. But at the onset, your goal doesn't do much but add a lot of overhead and complexities that will likely hinder you in the future.

Your implementation is also flawed and based on security through obscurity (changing the firewall port). You would be better off using standard port with rules in place on that port with two factor authentication. You're assuming an attacker won't find the port. While you may minimize the low hanging fruit, eventually someone will find the port, and although they may not be able to do anything, the can certainly perform a resource exhaustion (DoS) against your firewall. That in turn depending on its placement could outright block all traffic. "Root" access is a horrible idea especially at the egress point, and you're assuming a firewall of this nature would be run perhaps Linux? While it may be, most ASIC based firewalls that need to do heavy hauling tend to consist of JeOS (Just Enough Operating System. But should you insist to go the Linux route, this is what sudo is for.

I didn't bother with assumptions, there is no need to.


Is using PBKDF2 good protection against brute-force attacks on web application login pages?

You are right that using PBKDF2 does not protect against brute-force attacks on web application login pages. Credentials submitted by users and attackers travel unchanged until the server, where PBKDF2 is then computed. PBKDF2 is therefore only meaningful for offline attacks which have direct access to the correct hashes.
The only scenario where PBKDF2 and brute-force attacks on web application pages would be related is if login pages responded faster than the server computes PBKDF2 hashes. In that case a parallelized brute-force attack would be slightly slowed down. However it would also require a lot of unnecessary computing power and it would prevent other users from logging in.
The same protection could be achieved more effectively and efficiently by implementing in the front-end application logic one or more among CAPTCHA, account lockout and/or password throttling. These controls should ideally be weighed based on client IP address history and reputation (e.g. a Tor exit node having already failed multiple logons should be heavily penalized).


In Tor, the user (you) chooses a random path through several nodes for its data. The first node in the path knows your IP address, but not what you send or where. The last node ("exit node") knows the target server address and sees the data (unless SSL is used, of course), but not your IP address. Every node in the path knows only the addresses of the previous and the next nodes in the path.

If a government is intent on unraveling the privacy of Tor, then its best chance is to setup and operate a lot of nodes (which, of course, will not say "provided by your friendly government"). If your computer randomly chooses a path which begins by a government-controlled node and ends with another government-controlled node, then both nodes can correlate their data pretty easily and reveal both your IP and the target server (and sent data, if no SSL). Correlation is simple because while encryption hides the contents of data, it does not hide the length. If node A sees a 4138-byte request entering the Tor network from your IP, and node B sees a 4138-byte request within the next second exiting the Tor network and destined to server www.example.com, then node A and node B, by collating their data, will infer that your IP was involved with a communication to www.example.com.

It can easily be proven that if the hostile party does not eavesdrop on or hijack both the entry and exit nodes, then your privacy is maintained. But if they do, then privacy evaporates like a morning mist under the midday Sun.


Embedding a service subscription form (via iframe) in a landing page hosted by 3rd party - PCI DSS Complaince

In order to be complaint with PCI DSS, does the 3rd party landing page
  hosting service also have to be PCI DSS complaint?

Yes.

If you're talking about sending your customers off to subscribe via an iframe, you're probably hoping to manage your PCI Compliance under SAQ A.  Part 2f asks:

  Does your company share cardholder data with any third-party service
  providers (for example, gateways, payment processors, payment service
  providers (PSP), web-hosting companies, airline booking agents,
  loyalty program agents, etc.)?

and after you list them out, it reminds you:

  Note: Requirement 12.8 applies to all entities in this list.

which, among other requirements, asks:

  12.8.4 - Is a program maintained to monitor service providers’
  PCI DSS compliance status at least annually?

Someone like Salesforce is, in fact, a PCI-compliant Service Provider which as reflected in the Visa Global Registry of Service Providers.  Salesforce themselves has an answer in their knowledge base making it easier for their customers to get the attestations they need.


Root CA don't trust each other and don't actually talk to each other. Each root CA lives in its own world, alone. Root CA don't trust anybody; it goes the other way round. That's also where the bank analogy breaks down: banks have to talk to each other, while root CA totally ignore each other.

You (or your OS or browser) trusts one or several root CA for asserting things about identities and public keys. The various roots don't have to assume or even be aware that you are trusting several of them simultaneously. It is your problem, not theirs. In practice, your OS or browser vendor has chosen for you that you will trust about one hundred root CA, which you can see by inspecting your browser configuration menus.

Cross-trust between CA is a rare event, which typically happens in the wild as an aftermath of mergers: two businesses, each with its own internal CA, decide to fuse into a single entity. But deployed desktop systems in what formerly was business A only trust rootA, while deployed systems from business B only trust rootB. The ideal solution would be to modify all systems so that they all trust both rootA and rootB, but that's hard work (depending on how computers are managed in the organization, they may have to send sysadmins in front of each of the thousands of PC, to do the few needed operations) and it may take time. So, in the meantime, something can be done at the CA level: make rootA emit a certificate (an intermediate CA certificate) for rootB (and vice-versa). This means that rootA asserts that whoever trust rootA may also trust that which comes from rootB (and vice-versa).

Some people have invested a lot of thought into coming up with terminology for the various cases of cross-trust; see RFC 5217 for (a lot of) details. However, I insist, this does not happen often in the "real world".


Taking into consideration the fact that you are doing these scans in the context of PCI-DSS compliance, your value-add in relation to compliance can be summed up by my personal favorite saying:

  AviD's Law of Regulatory Compliance:

  "PCI compliance reduces the risk of the penalties of non-compliance".

In other words - the value-add of having an external scanning vendor over your internal tools (even if its the same tools), is that that is what the regulation requires.
That's why there's such a popping ASV business - their income is pretty much ensured by PCI. Take a look at McAffee's HackerSafe program (or did they change the name?): completely worthless from a security point of view, but equally valuable from a compliance point of view - since an ASV scan = ASV scan.

Now, if you want to get additional security value out of your whole compliance program, aside from simply "compliance", well that's another issue. (For elaboration on this, see my answer on "Does PCI compliance really reduce risk and improve security?"
The other answers here point you in the right direction, but one simple truism: Any vendor that simply runs tools, is not worth the price of coffee to have a sales meeting with.
Cheaper to get your own tools and run them yourself - since you can usually ignore most of the results, anyway :).


How to prevent "JailBreak detection bypass" by Cydia tools such as "Flex 3" etc?

I am pretty sure there are no reliable methods to detect jail-break/root. And I would not recommend locking out users. My bank for example had me accept responsibility in case my account gets hacked as a result of having rooted device and that is IMO the reasonable thing to do. Trying to stop users from doing what they want to do is neither nice, nor will it ever work, as they will find ways around it.

Also consider this, having jail-broken iPhone is similar to having Unknown-Sources enabled on an android and while it is less secure, you would not block such users on Android.


How to raise a key to ultimate trust on another machine?

You can set every key to ultimate trust through opening the key edit command line

gpg --edit-key [key-id]

and running the trust command. You will now be prompted to select the trust level:

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision?

Obviously, 5 will be the proper decision to achieve ultimate trust. Finally, save to commit the changes and exit GnuPG. The same commands apply to both GnuPG 1.4 and GnuPG 2 (and newer).

Ultimate enables a key to introduce trust in the OpenPGP web of trust, with other words all ultimately trusted keys act as a starting point for trust paths. You should set your own keys to ultimate trust, but usually will not do so for other's.


Place your public files in a folder called public and point your domain name to this folder using apache virtual host, other non-public files should be in folders above the public folder and you can refer to them by include_path for example. This is how most frameworks are structured.


Period and direction of risk when connecting to malicious webserver

You're correct.  The risk is what information you provide to the server, or on the server.  The attacker could modify it's SSH client to inject some kind of malicious data in it's responses.  However, it would have to conform to the SSH spec in order to be processed correctly by your SSH client, and then also do something malicious.  Which in my opinion would be be non-trivial.
Public and private keys are generated as a pair.  As long as the key was generated with a cryptographically secure PRNG it will only have one private key paired with it.


How secure is MD5 for TLS message authentiaction?

In TLS, MD5 is used as the compression function for HMAC. The best current security proof for HMAC does not require its compression function to be collision-resistant, so HMAC-MD5 is still considered secure (if distasteful).

TLS 1.0 and RC4 are more disconcerting than MD5 in this case.


It's hard to judge the source or the purpose of these requests based on information you provide, but one thing is rather clear: somebody was translating request URLs with the wrong function, using HTML encoding in place of what it should have been URL encoding of the query part of the requested URLs.

For example, the sample you provide should read as:

&sa=U&ei=w0QtUoiKC4jukQWZjYGQDg&ved=0CMcBEBYwOTiQAw&usg=AFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg/

If this was meant to be passed to another URL as a single variable, it would have to be translated using URL encoding, and it would look like this:

%26sa%3DU%26ei%3Dw0QtUoiKC4jukQWZjYGQDg%26ved%3D0CMcBEBYwOTiQAw%26usg%3DAFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg%2F

As it was translated with HTML encoding instead, the & ampersand character (for example, there are other problems with it) denoting new URL parameter value will repeat in the HTML encoded string at wrong places, your web server has no way of knowing which parts are the URL query name and value parts in the format: &field=value once it URL decodes the requested resource location.

This, I imagine, translates in all kinds of illegal requests listed in your web server's access logs. I would advice simply blocking all such requests in your web server configuration, as there is no way they can be served proper response anyway. How you'll do that though, is entirely up to you and your needs. I personally deny access to any User Agent (UA) strings that I deem having no business accessing my server, including default UAs of many web framework libraries, among which the one you mention: Libwww-perl.

I'm on Apache, and using PerishablePress' 2010 User-Agent Blacklist for these tasks (among other custom blocks in web server config and other means of controlling access, of course). It's in my opinion a convenient enough collection of blacklisted UAs, and while there are newer ones published even on this same blog, I find the one from 2010 to work the best for my needs. Anyway, I thought you might find it useful, too. ;)


The whole heartbleed story has gone way beyond sanity, for sure.

The bug is real and can be a serious threat to any server. However, the bug is no more serious than all other "buffer overrun" attacks, and arguably less serious than write overflows, which can more easily lead to hostile server hijack. You can have a list of reported security issues for OpenSSL on this page. None of them triggered such a panic as the one we are currently witnessing; yet some were of the "remote code execution" kind, technically much scarier than this heartbleed canard (but without the nifty logo).

The IT industry, as a whole, has come up with a strategy with handling that kind of bugs. It is called "apply the damn security patches from the OS vendor". This strategy is not ultimately elegant, but it works. There is no reason to single out this bug and award it a special treatment, as if it was a new kind of thing (it is not) or exposed to especially dire circumstances (it does not -- its consequences are within the normal range of security holes).

The only benefit of this pandemonium is that it shows who does his job properly. When a panicked sysadmin asks whether he should apply the fix right away and/or reset all his passwords and/or kill his dog (just to be sure), he implicitly admits that he does not usually apply security patches, or at least not promptly -- and that is the problem.