The format of the card is established by the card brands and followed by the issuing banks. Banks will follow the established card production standards since most outsource their card production.

There are third party products, like this one, which do exactly like you mentioned. These products also allow you to store multiple cards on the same device. These products don't support EMV chips so their lifetime is limited as chip continues to replace mag stripe.

Finally, consider what security you are looking by hiding the card number. You are protecting yourself from someone capturing the number by seeing your card. Most credit card fraud happens via either skimmers or by capturing large numbers of cards numbers via electronic methods. Before modifying your card I would start with using chip whenever possible, being very selective of the ATMs you use, and limit the number of places where you have your credit card number stored.


PMK is what prevent to generate the PTK and decrypt the traffic?

To decipher the traffic of your victim, PMK is what prevents you to figure out the PTK of that client. To generate PTK 5 things are required:

PMK
AP MAC Address
Client's MAC Address
ANonce
SNonce

You can capture 4 of them from the handshake except PMK. PMK is never sent over the network. The 4th frame of the handshake carries only Message Authentication Code. As long as you don't know PMK you can't decrypt the traffic.


Is it possible to use an open collection of default SSL certificates for my browser?

The model you're talking about is Certificate and Public Key Pinning.  The primary flaw is maintainability; it's the traditional hosts-versus-dns issue with the added burden of making sure your manual updates are trustworthy (because if you don't pay attention there, you haven't gained anything).

It also may be harder to manage support for it in your commodity software.  I note that Firefox seems to have added something for it.  Chrome has had some pinning since Chromium 13, although it's not clear to me that it's a user-accessible interface.

In short, it's a good idea, not trivial to set up, harder to maintain over time.  It makes sense in certain limited scopes of highly sensitive trust relationships (your bank is a good one), but not as a general way of life.


PDF encryption anomaly; version 1.5 using AES

Your understanding about AES is correct, it came into PDF in version 1.6 (see section 3.5 of PDF Reference v1.6 for details). PDF 1.6 and 1.7 (and ISO 32000-1) support AES in 128-bit mode. Adobe's ExtensionLevel 3 for PDF 1.7/ISO 32000-1 introduced AES in 256-bit mode but should be avoided because of weaknesses in the password mechanism. Better support was introduced in ExtensionLevel 8, though that has never been formally published by Adobe.

Starting with PDF 1.4, however, a PDF may specify a file version with the /Version entry in the document catalog (PDF Reference 1.6 section 3.6.1, /Version key). Some writers do use different version #s for the comment and for the /Version entry - to specify that an incremental update to a PDF has added features not supported in PDF version that the PDF originally conformed to. I can't speak specifically to what PDF Studio 11 might be doing, but do be aware that one must check the document catalog for a PDF document version; the higher of the /Version entry (if present) or the version in the %%PDF-x.y comment line is the actual version of the PDF file.


Safe to commit OpenVPN client config to Git?

Avoiding "security through obscurity" doesn't mean giving away information about your system just because it's something a determined person can find out anyway.

Also, I assume you mean version control hosted remotely, not just version control on your development machine?

If the remote version control server is publicly accessible or accessible to more than those who need to know this information, putting the file in version control doesn't make it anymore secure, so I guess if you think it does, that's falling victim to "security through obscurity".


Is it possible to use TLS 1.3 without ESNI?

The default way to use TLS 1.3 is without ESNI. It just uses SNI, like TLS 1.2 before it.
You can even use it without SNI at all, and either the server will close the connection, or give you a certificate that doesn't cover the domain you want which will cause the client to close the connection (unless you override the cert verification logic) or it will give you a cert that covers the domain you want and everything will work great, all depending on the configuration of the web server or TLS terminator.


Don't allow SSH login into the root account. Login with a user account with a name which is harder to guess. When you need to do something as root, use su or sudo after you logged in.
Make sure your passwords are long enough to avoid getting brute-forced. The speed an attacker can use to brute-force over the network is severely limited, so an 8-character mixed-case password without any relation to a dictionary word is more than enough.
Even better, use keyfiles for SSH login. That way SSH logins are only possible with the correct keyfile on the client system. Brute-forcing an RSA key (when generated correctly) is very unlikely to be successful before the end of the universe, so nobody will even try.
Install fail2ban. This tool automatically adds firewall rules which block IP addresses which make an unusually large number of failed login attempts. When you followed the previous steps this shouldn't actually be necessary from a security standpoint and it might result in overblocking legitimate users which share an IP with an attacker (carrier-grade NAT, dynamic IP addresses), but it reduces the resource load on the server due to not having to respond to all the login attempts.


What is the proper way to understand Access Complexity in CVSS

Access Complexity is a very overloaded and subjective metric in CVSS v2. When it's applied, it's impossible to tell if it's being used for user interaction from social engineering, from a race condition, uncommon configuration, attacker starting privileges, or anything else. (https://www.first.org/cvss)

Are you aware of CVSS version 3 that came out last year?

In CVSS version 3, it is now renamed as "Attack Complexity" and only have two metric values- Low and High.
Now, it’s much easier to choose between two possible values. It should be noted that any 'user interaction' should not be considered while rating 'Attack Complexity' parameter. CVSS has a new parameter called 'User Interaction' to incorporate this.

Low  (AC) : If the attacker can exploit any time (Reflected XSS)

High (AC) : Some conditions beyond attacker's control exists. (say Poodle attack which requires MITM attack)


Given certain parameters, are there any risks with Android's USB Debugging?

If you have total control of the device and are very careful what connects to it then there's no risk in leaving debugging on at all times. Leaving USB debugging on is risky when you do not have control. So if you have a phone you use purely for development and testing then leaving USB debugging on makes sense. If you use your personal phone for development then it is recommended you turn off debugging when you don't need it.


Additional security measures for getting Chrome Saved Passwords via password management Hacked or Exposed?

As far as I remember, like Firefox chrome got a master password function which encrypt the saved passwords. Each time a password is required it will ask you to enter your master password to use a saved credential.

Alternative if you don't want to use native functionality for password protecting, you can use one of numerous software existing for that subject such as Bitdefender password waller which is IMO one of the best one.


Theory X vs Theory Y in social engineering

I'd say you're pushing Theory X and Theory Y too far away from their original position.  The original posit of the theories relates to a relationship between people and authority.  The people are in a system in which the manager has a significant degree of control over employment conditions and outcomes.

The social engineering concepts and strategies run counter to the idea that the social engineer has a position of direct authority over his victims.  Very much the opposite - the social engineer is getting something out of the victim that the social engineer has no right, authority or need to have.  Also, since the purpose is fraudulent, I'm not sure that you can make the same assumptions about self-motivation playing the same role in the relationship.  The comparison of Theory X vs. Y is typically selfishness vs. self-motivation.

In many cases, social engineering can probably work either way.  For example - I'd see Phishing working either way - in a Theory X situation, the victim might be motivated to respond to phishing queries because he wants to avoid punishment or reap monetary reward, in a Theory Y situation the victim might be working towards some shared goal that provides intrinsic motivation.  Either way, the social engineering side is that the victim doesn't know that the attacker's purposes run counter to the victim's best-interest so the nature of his motivation is not nearly so important.


Is the Web browser status bar always trustable?

Could this URL (in the left/bottom) be different from the one that my webbrowser will go?

Yes.

for a simple link click, the whole click could be captured by JavaScript and made to do something else, including navigating to a different page
the link could be substituted onmousedown (this is common behaviour for some link-click tracking scripts)
for browsers like Chrome where the address pop-up appears inside the page area, that pop-up could be faked with JavaScript and page elements. In general you can only trust browser UI that appears in the chrome border, outside of page control.

Consequently the address pop-up is a convenience feature but offers no security function.


Torrent "bad seed" attack by Sony, how does it work?

Correct.  As explained in that article the torrents use the BitTorrent protocol to share Sony's stolen data.  Each piece that is downloaded via a seed is linked with an index into the file, and the hash of that portion is checked and verified.  However, I don't believe its this hash that they are referring to in that article.  Below I'll describe the process of downloading a file via BitTorrent.

.torrent File
The BitTorrent protocol itself says that the .torrent file contains two fields of information:

announce: URL of the Tracker
info: Maps to a dictionary of keys

Each piece of data in the dictionary is used to piece together the original file.  This means that a file is split into predetermined pieces, and each piece is generally a power of two.  This dictionary contains all the information about each piece, the length, and the SHA1 hash of each piece to verify a complete download.

Tracker
When you attempt to download a file with BitTorrent it will attempt to do a Tracker GET Request.  In response, there is a lot of information about what peers are currently available for the download.  Typically a compressed version of the list of peers that can be used to download the file.  Connections are made to the peers in order to download each piece, and once all pieces have been received the Torrent client is notified.  Each piece is considered to be complete when the SHA1 hash of the data is verified.  As stated before, this hash value is provided in the info dictionary.

This SHA1 hash is not the hash that is being spoofed.  One other piece of information that is included in the Tracker response is a field called info_hash:

  info_hash
      The 20 byte sha1 hash of the bencoded form of the info value from the metainfo file. Note that this is a substring of the metainfo file.
  The info-hash must be the hash of the encoded form as found in the
  .torrent file, regardless of it being invalid. This value will almost
  certainly have to be escaped.

Keep this in the back of your mind, we'll come back to it.

Peers
The Peer protocol is what's being spoofed.  Each peer must establishes which piece of the file is downloaded by that peer using an index.  There is a handshake for establishing this connection, and it involves sending the value of info_hash.  The client downloading the file verifies that this matches the SHA1 hash of the bencoded info field of the .torrent file.

What Sony allegedly did is put out fake files with the correct hash values to establish connections to clients attempting to download them.  The files can be bogus because the client must download the entire piece in order to verify that portion.  When the check fails then a download for that piece must be restarted.

As you can see (and it's mentioned in that article) this can be a problem for web servers.  The constant downloading of portions of the file with literally no end can end up causing major bandwidth usage.  This can results in a DDoS of the web server.


Validating iss and aud for internally signed JWT

The purpose of both security controls are different. JWT signature validation ensures that the token payload have not been modified on transport and was issued by a known sender.

The "iss" and "aud" validation ensures that token have been issued by expected Identity Provider and for expected Client. This also (with validation of "azp", "at_hash" or "c_hash") mitigates against some of the Token Substitution threads, where attacker can use token issued from another session (possessed by attacker) by simply "copy and paste".

Token Substituion threat


What attacks is my website subceptable to and how can I prevent them?

Without seeing an actual version of the site our answers are going to be pretty low quality.

However, a suggestion would be for you to run a vulnerability scanner on the site and provide some feedback we could work with/talk you through?

Suggested scanners to try would be OWASP ZAPP or Nessus.

Good luck!


Security assessment of a legacy SSL/TLS implementation on an IoT device

This is a good start, but a thorough assessment would need to go much deeper than this.  For example:

How does the client generate random numbers?  Does it use a CSPRNG?  Or, does it use a weak random number generator, like the one used in early versions of Netscape Navigator, where a passive attacker was able to guess the random numbers generated for the session keys, and thus decrypt the ciphertext going over the network.

Does the client leak information when it encounters a padding error?   If so, then it might be susceptible to a padding oracle attack, as was the case with the Steam Gaming Client.

How does the client implement ECDSA?  Does the client generate a new random k for each signature that it creates?  If not, it may be possible for a passive attacker to calculate the private signing key after observing a few signatures, as was the case with the Sony Playstation 3.

These are just a few examples.  But, as you can see, subtle mistakes in the implementation of cryptography can have disastrous consequences.  This is why cryptography is so hard to get right.


Importing a GPG key with a KeyID seems to rely on key servers -- but, in reality, it does not. A key server is an untrusted storage area. When you import a key, you shall not use it before having duly verified that the key is genuine, i.e. is really the public key of whom you believe owns it. That the key came from some key server proves nothing; neither the transmission protocol, nor the key server storage itself, offers any protection against attacks. And, in any case, you don't know who owns the key server and thus you will certainly not trust them.

In order to verify a GPG key, you can:

Check its fingerprint, which is really a hash value. This is for the cases where you met the key owner and he gave you a copy of his key fingerprint. Fingerprints are short enough to be printed on business cards or spelled out over a phone call (I have done both). Hash functions are second-preimage resistant, and that's good enough.
If the fingerprint is not available, build chains: keys signed by other people, whose public key you can verify (possibly recursively). This exercises the Web of trust, which is what passes as a PKI in the PGP world.


Is it possible to stop webcam surveillance by having an always running camera application?

I take it as a dilemma whether a physical protection of a camera is significantly better than a software protection (given an example of the latter). With that in mind, this is ultimately a risk assessment question. For an ordinary user, there might really be no difference, but they could probably as well get away without any camera covers.

Physical security is so much different from a software security. If a recording device is disabled physically, there's virtually no way to get around it, if a camera cover isn't supplied by the NSA. Contrary, for a software solution, there would always be a plenty of theoretically possible ways to get over a simple script.

E.g. your Python script allocates some memory, thus might be forced externally to be killed by the OOM killer, and after that a malicious process might immediately take over the recording device. Or, the mutual locking within your OS around the camera might not be as strong as you think. Or, your script could be broken by a software dependency update. Or, anything else.

Those are issues that are there even if there's no possibility that a rogue process might have a system-level access to your computer (whereafter you have no chances to win against a skilled attacker, whilst a camera cover would cover you — taking in account though that your microphone device would still be exposed).

Physical solutions are tough and always hard to maintain, but they are reliable as well.


Are disabling TLS 1.0, enabling RC4 or using TLS1.0 with AES only, the only ways to mitigate BEAST server-side?

Yes. Several years ago, Qualys covered mitigation techniques, and notably several methods that you might think would work (like "enabling the empty fragment technique server-side") are ineffective because the attack is client-side.

However, TLS 1.1+ is much more common these days. Additionally, most clients added mitigation years ago (even Apple, who was slow on the take).  Between these two factors, BEAST really isn't much of a worry any more.


Won't all hashes collide after enough iterations with a static salt?

When iterating a hash function, space reduction occurs, but not down to a single point. For a randomly chosen function (that your "amazing_hash" is supposed to approach), with a n-bit output, you may expect to ultimately reach a cycle of size 2n/2 or so, i.e. still big enough if you use a decent output size (say, n = 256).

See this answer for more detailed explanations. I reproduce here the scheme from that answer, because it is a good eye-catcher:

Of course, a "static salt" is not a salt; it just means that you are using a custom hash function. The salt is meant to deter parallel attacks: when the attacker tries to crack 10 passwords, it costs him 10 times the cost of cracking one. With a "static salt", cracking 10 passwords costs no more than cracking 1, i.e. a total failure of the salting.

Salts are not about avoiding collisions, notably because collisions are not a problem for password hashing. It is preimage resistance that you should worry about.


No.  Blocking a channel simply means that communication cannot take place along that channel.  In order to read the content of a TLS channel, the attacker (in this case, the ISP) would need copies of the secret keys involved.


Advice needed regarding "Information Security Policy" - EI3PA requirements

There are many templates that can help you design your own policies. The international standard is ISO 27002. There are numerous templates you can find via Google but it might be helpful to get a professional to help you out.

But as for what the minimum will be for Experian, you might have to ask them, or hire a QSA. It is not clear from your question if the requirement is a general corporate Information Security Policy, or one focussed on PCI/EI3PA requirements.

The short answer is: you might have to hire a consultant for a short time or work closely with Experian.


Can an isp see what you search on google images

I was under the impression all images were https.

This is not true. While the images shown in the Google Images Search are served by Google using https they can refer to images which are plain http, i.e. once you click the link you get the image as plain http.

  I was also under the impression that isps can see all images and searches despite having https.

This is not true either. Unless SSL interception is done (which needs changes to your computer in order to be not cause warnings or errors) the ISP can see what sites you visit but not the exact content of the request or response, like which search terms and which results.

  I get nervous searching health info as I know google and isps can sell your info

Google can definitely see your search terms given since otherwise they could not provide you with the results of your search.

ISPs can as I said not see the exact searches but they can detect the sites you visit and at which time and order. This is often enough to create interesting personal profiles which they could sell if there is no law or legal terms to forbid this. And even if laws prevent selling such information, the ISP might have its own advertisement business (like Google does) or even their own insurance business and might use these information there without selling it to third parties.


Based on your comments, I am going to assume for the sake of simplicity that the input you want to search on is a password.
So you don't want to store the raw password in your database, so you'll store a cryptographic hash of it. Now you want to be able to search on this column. This presents a number of problems:

You are limited to exact-match searches. Obviously there's no way to do a partial-match search after you have run the value through a cryptographic hash.
Hash functions designed for passwords all require a salt and a work-factor that make them very slow, use a lot of memory, or both. Neither of these seem ideal for a database lookup.

The solution is going to depend on a deeper analysis of exactly what security properties you need, and don't need.

If the input is sensitive but high-entropy (for example a private key) then you don't need a password hashing function because the input is not brute-forcable anyway, and could use instead a single pass of SHA-256. Fast and no salt.
I assume you've already considered searching by an Id or key instead, and for whatever reason this doesn't work. (you'd probably need a way to look up the key for a given entry, in which case you're back to the same problem)
If your input is low-entropy (like a password), and you really do need a salted&iterated hash, then I don't see any good options because you'll need some way to know which salt to use before you can hash&lookup. This chicken-and-eggs with the need for some sort of Id/key (or with the salt serving as that Id/key)

Taking a step back and squinting, this looks a bit like password authentication: user logs in with their password, and the server looks them up and returns a bunch of data for them. The key point here is that no systems use the password as the lookup key; that's what the username is for! Providing the secret is simply to prove that they are who they say they are.

I agree with @Steffen that this seems like an XY problem. You're hitting dead-ends, likely, because the larger problem you're trying to solve doesn't fit into the shape of problems that we know how to solve efficiently. It may be back-to-the-drawing-board time to see if you can re-cast your problem so that it fits some established pattern.


Possible countermeasure/fix for this php exploit code?

This is definitely not an exploit for CVE-2011-3775, which is a rather low-severity information leak vulnerability.

What this is is an exploit for a CSRF vulnerability, so that is what you should defend against. See for example OWASP on defending against CSRF


Is it safe to include the IV at the end of a hash?

The IV is not secret so it doesn't matter how you store it. It's perfectly find to append it to a hash.


I have come across a couple of solutions that mostly fit this bill.  Your list above is a good set of requirements for bookmark management.

Implicitly, your points throw out Google's Chrome and Microsoft's browsers because those companies have shown intense hunger for personal data.  Safari's benevolent tyranny is not very extensible, so that leaves you to use Firefox, and/or a Firefox derivative like Palemoon or the Tor Browser Bundle (TBB).

1. Outertech's Linkman

From their website:

  Linkman is a bookmark manager that efficiently organizes large numbers
  of bookmarks. Linkman directly integrates with Google Chrome, Firefox,
  Internet Explorer, Opera browsers, and supports many other browsers.
  Synchronizing bookmarks between browsers and among computers is also
  possible. You get the choice to manage your bookmarks by keywords
  only, folders only, or folders and keywords. Linkman will extract
  keywords from web sites and update moved web addresses. The bookmark
  collection can be protected by a password. With a screenshot tutorial,
  an introduction video, and a comprehensive PDF manual, getting started
  has never been easier!

This software creates a local webserver and then there's a plugin for each browser.  I've made it work with FireFox and Palemoon, but the Tor Browser Bundle seems to block part of the way this works.  I didn't look into it, so it may be possible to get it to work.

On laptops/desktops, you could probably use Dropbox, SpiderOak, or Syncthing to sync the database file across multiple machines.

I have not looked in to doing this on mobile.  I doubt iOS would be able to work with this, and Android would probably take a bit of work to get it going.

2. Firefox Sync

From their website:

  With Firefox on all your devices, you can access bookmarks, tabs and
  passwords with one easy sign-in.

I've done some preliminary research into how secure this is from 2nd, 3rd, and 4th parties, and they seem to had security and privacy in mind when they built it.  This article goes in depth about they why and how without being too technical.

This is supposed to work on mobile too.

Their software does use their own servers/services though.  If they did succeed in true Trust No One security, then that should be fine.  That's a big if though.

You do have the option to implement your own sync servers. Although a complete DIY solution also requires setting up authentication servers, which have little-to-no documentation, guides, or support.  See below, emphasis mine:

  Alternatively, you can also Run your own Firefox Accounts Server to
  control all aspects of the system. The process for doing so is
  currently very experimental and not well documented.


How can I create a hidden Administrator account in a public computer?

I don't think you can hide a user from the net user command. I may be wrong on that point, but if I remember correctly net user use the SAM file that manage all users accounts.

But you can hide a user from the user folder and the logon screen with the cmd command :

reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\Userlist" /v <ACCOUNTNAME> /t REG_DWORD /d 1 /f

(Replace the <ACCOUNTNAME> with your account name)


how to prevent multicast packets from being snooped

I want to prevent the multicast packets from being snooped by unauthorized user,

Since there is no authorization in multicast you cannot prevent snooping by an unauthorized user. What you can do instead is to encrypt the multicast traffic and distribute the decryption keys only to the users which should be able to access the content.


SAML and privacy: does the Identity Provider have to know about the Service Provider?

This image helped me understand, immensely.

The short of it is that, yes the SP needs to know the IdP. It's totally up to the IdP what information they send the SP, during the auth exchange, but there need to be an initial exchange of public key/signature information between the two.
Source: We're starting to onboard enterprise and need the SSO.
Image from Okta


Is hacking Wi-Fi THAT easy? (just spoof, and it's hacked?)

No, it is not that easy. But it depends on the network.

First, most Wi-Fi devices will remember all Wi-Fi networks they connect to, and also whether that network is encrypted or not and using which method. When your device comes near a network it "knows" (by its name, i.e. its SSID), it will try to reconnect, if that network's security method matches the saved one. What happens next will depend on the kind of Wi-Fi network.

Open, unencrypted Wi-Fi networks

When a Wi-Fi network is unencrypted (like most "Free Wi-Fi" networks in cafés, bars or hotels) and you have already been connected to that network once before, your device will automatically reconnect to a network with the same name. Anyone can spoof a well-known "Some Coffeemaker Free WiFi" and your device will happily connect to it when encountered. The rogue access point (AP) will then see all traffic your device sends or receives over this network (but cannot look into HTTPS or VPN encrypted traffic, of course).

WPA2 networks with pre-shared keys (WPA-PSK)

When using WPA2 authentication with pre-shared keys (PSK), both the station and the AP have to prove that they know the PSK in the four-way handshake. Thus, a rogue WPA2-AP cannot give access to a client by just having the right SSID and accepting any password from the client. Your device will not associate with that AP unless it uses the same PSK.

AFAIR, this is also valid for authentication with WPA version 1 and even WEP, but those protocols have other weaknesses which make them non-recommendable or even useless.

On the other hand, everyone who knows the PSK could fake a WPA2-AP. A weak PSK could also be guessed in a brute-force attack, e.g. by repeated authentication attempts. Hence, a long, not-guessable PSK is necessary.

(There is also an attack called Hole 196 that can be used by already authenticated attackers to break the session key of other authenticated hosts with the AP, but this is not relevant here.)

WPA2 Enterprise networks

WPA2 Enterprise works similar to WPA2-PSK, but uses a dedicated authentication server. In addition to passphrases, it can use certificates on client and AP. Client certificates are like long, authority-signed passphrases which are different for every client device. This way, when a host is compromised (e.g. stolen), that particular client certificate can be blocked on the authentication server, instead of changing the PSK on all devices.

For your device it makes no difference if WPA2-PSK or WPA2 Enterprise is used, in both cases it will not connect to an AP that cannot prove to have the necessary secret.


An example of dumb card is those used in hotels to replace physical keys. Or entry badges. These can be usually be cloned with equipment like a Proxmark, Proxmark pro or even an NFC-enabled smartphone. You can argue that they are less secure than physical keys, because someone who has portable equipment (that is readily available on the market and may already exist in your pocket) and comes close enough to the card could make a copy.

When it comes to contactless there are quite a few standards. Not all cards are the same in terms of design, cryptographic abilities and they do not all operate on the same frequency ranges.

Let me address this sentence:

  Smart cards (for instance, public transit cards) are widely used in
  some countries for authentication purposes at universities and
  workplaces, so that an authorized person can use a printer or access a
  room by just putting the card on a reader.

What you describe is not authentication but identification. Because you are not proving you are who you say you are (an authorized user), for example by providing a password in addition to the physical token. Anybody can 'borrow' your card to use the printer.

The difference can be explained in simple terms:

  Identification occurs when a user (or any subject) claims or professes an identity. This can be accomplished with a username, a
  process ID, a smart card, or anything else that can uniquely identify
  a subject...

  Authentication is the process of proving an identity and it occurs when subjects provide appropriate credentials to prove their identity.
  For example, when a user provides the correct password with a
  username, the password proves that the user is the owner of the
  username. In short, the authentication provides proof of a claimed
  identity.

Source: Identification, Authentication, and Authorization

For a more detailed discussion: Difference between authentication and identification [Crypto and Security perspective]

As to the question "Can a bank card be used in this case instead", the answer is yes probably but there are legal considerations that will probably not permit it. If my employer required the use of a bank card or chip identity card to access the printer or restroom, the data protection authority in my country would step in, because such a scheme is illegal.

In addition to the legal considerations, the liability aspect raised by
Schroeder above has to be considered too.


Could TOR nodes collect IPs and filter them to unmask .onion url IP addresses?

You're talking about attacks by an adversary with a partial view of the network; which is possible, but you actually have to suspect your client and server ahead of time, and in practical terms you have to have control and visibility over a huge amount of network space.

The Tor FAQ may be a good place to have a look, but essentially the attack is possible given:

  A bad first of three servers can see encrypted Tor traffic coming from your computer. It still doesn't know who you are and what you are doing over Tor.

and

  A bad third of three servers can see the traffic you sent into Tor. It won't know who sent this traffic.

Someone would have to control at least three servers to make the match, and in practice would have to control many, many more as there's no way of determining which three servers any given connection is going to use in a network circuit.

Now scale this up; you want to just identify popular .onion sites, but you're seeing traffic coming in from IPs and out to IPs. You have no idea, none, which traffic is 'response' traffic, and which is 'request' traffic, you have no idea if those IPs are simply relays that happen to be chosen a few times - it's very possible in this scenario that you never see the IP of any popular .onion sites. Additionally, Tor circuits are built to resist this sort of attack.

Specifically if you're watching all traffic in and out, and you identify 1.2.3.4 as being popular - you don't know if that's an endpoint, or a router, a server/client uploading or downloading something. All you know is that it's Tor traffic. Tor is set up so that that's not really interesting information - the fact that you're running Tor isn't a secret (and as you noted, they publish the list of exit nodes for blacklisting purposes, but all non-bridge nodes are listed in the regularly published relay descriptors).

It's a bit different if you already have some suspects, timing attacks can work in this case - but at the end of the day, you can likely only show that two machines are communicating, not what they're communicating about, and you don't definitively know they're not just a router in the transaction.

Finally, if the service you're trying to identify is a Hidden Service all bets are likely off - they're designed to distribute the sort of traffic you're looking for on one link by deliberately adding a number of pre-trusted routers into the equation, which would negate any knowledge you had of the network.


What should I do when I am using a public computer without secure access to my password manager?

There are a number of approaches you could consider. None of them involve using the browsers password store.

Firstly, you should consider using a dedicated web-based password management tool such as LastPass. Most importantly in this case, this has a one-time password feature that allows use of LastPass on untrusted devices.

You can also add multi-factor authentication options to this for added security.

This doesn't make you completely secure though and you should always assume that an unknown computer is compromised so restrict what you do carefully.

In general using a mobile phone will be more secure than an unknown computer.

UPDATE: LastPass protects you on an untrusted computer because you use a single-use passcode (that you have to have generated in advance). That gets you access to a web page, your "vault". On that page, you can directly launch a password protected site without having to manually type your id and password. For most sites, this will prevent any key-logging or traffic interception of your password.

It goes without saying that you get no protection from this on any site not using HTTPS.

It is also important to note that this only protects against capturing of your passcode. It does not prevent capturing of other information, nor would it help protect against certain malware designed specifically to attack financial sites such as personal banking. An untrusted computer is always untrusted. However, it may be enough for you to grab an image or low-value document from your iCloud or other cloud service or to log into your webmail to check non-sensitive information.

It might also be helpful for me to note that I don't trust LastPass for everything. I also use a stand-alone system called KeePass for really high-value passcodes. This is still cross-platform (e.g. both desktop and mobile) and with an easily copyable file database but can be kept offline or hidden away somewhere. So you could use that as a "phone vault".

I still wouldn't access finance and other high-value sites from an untrusted computer though.


DNS queries with hex string that is a SHA1 of a domain name! Is it a malware?

Pure speculation, but I had to give it a try (always fun playing Sherlock Holmes  every once in a while - the pre-Hollywood version obviously).

First of all, it's possible, or even likely that .domainname.com is being automatically added by your Operating System. It's quite common to append a domain suffix for DNS queries for a hostname without extesion. My hypothesis is therefore based on the fact that some program simply tried to resolve 56cea5c2b408989ab067adcb787d0f99209bbe07 without any extension. This part of the theory is easy to check on your computer though.

Why would a program try to resolve {something_random} or {hash_of_something}? I am guessing just to test whether name resolution works, and also trying to avoid caching or static /etc/hosts records.

Why hash('ebay.com')? That's the strangest part, but perhaps the developer couldn't figure out a better way to generate a random-like value? so they were just feeding some strings into the hash function? This is the odd part for sure, but there could be a simple explanation (i.e. developer just being stupid/silly/quirky).


Usually those are a spammer's bots who fake the referrer and try to make you click on it.
Those pages don't really contain a link to your page. (They might also use the e-mail address field, in fact any input to spam you with their domains, URLs and keywords...

Especially small sites and individuals are excited about visitors and where they come from, so they tend to click on those referrer URLs which only contain ads and/or malware. Steer clear and ignore them.


Choose a sentence, a number, and the name as password

The only way you can make people choose strong password is to not let them choose a password.

Instead, encourage the user to use password manager, let the password manager generates their passwords, and never reuse passwords. The passwords generated by these generators are usually random strings that looks like censored curse words and aren't memorable, but it doesn't really matter because you never have to remember or type them.

Then tell them to use a human-friendly password generator for their password manager's master password, which is the only password that they'll ever have to memorize.

This reduces the problem to securing that master password generator in way that are also human friendly and secure. IMO, the best way to do this is the Diceware passphrase scheme using EFF's wordlist. It's provably secure (2**77 strength with 6-words passphrase using standard-size diceware wordlist) and quantifably secure because the password are randomly generated rather than chosen by the user, and it is easy to type and memorize (they are just common english words).


Need help in creating a .PFX file for SSL Certificate Installation

Let me explain what all of these files are and what they mean. Then the solution will become more obvious:

What is a public and private key?

Public and private keys are two parts of a key, used for asymmetric encryption. They are mathematically related, and are generated together. The public key, as the name suggests, can be made public without any loss of security. In fact, it's necessary so others can send messages.

When sending a message, the sender uses the recipients public key to encrypt a message. The recipient then uses their corresponding private key to decrypt the message.

While there are no standardized extensions for public and private key files, commonly chosen names are myname.pub.pem and myname.priv.pem. Some people use myname.pub.key and myname.key (or myname.priv.key), but on Linux systems, extensions are not important.

What is a certificate?

A certificate is a public key, which was signed by another certificate. The way this works is that someone creates a certificate signing request, which contains their public key and is signed by their private key. The request also contains other identification information, such as domain name, e-mail address, etc., depending on the intended purpose of the certificate. The request is then sent to a certificate authority, which validates this information somehow and then signs the request (or not).

The result of this signature is a certificate, which is basically this:

  Hello, my name is Alice and my public key is

11:22:33:44:55:66:77:88
99:00:AA:BB:CC:DD:EE:FF

  Bob has signed that I am Alice. Bob's certificate is below:

  Hello, my name is Bob and my public key is

AB:CD:EF:01:02:03:04:05
06:07:08:09:10:12:13:14

  Claus has signed that I am Bob. Claus' certificate is below:

  ...

This would keep going until someone eventually signs their own certificate. This means they claim to be who they are, and you should just trust them. These certificates are called "root certificates" and are shipped together with your operating system.

Since a certificate is, in it's most basic sense, a public key with "stuff added to it", you still need the corresponding private key to use it. You can download certificates from other websites too, but without the corresponding private key, you cannot use them in any way.

What is a PKCS #12 file?

In the broadest terms, a PKCS #12 file is a bundle of cryptographic things. As stated above, in order to use a certificate, you need the corresponding private key. To make things "simple" for deployment, the certificate and the private key are often bundled together in one PKCS #12 file (e.g. myname.pfx).

Of course, PKCS #12 offers much more, and Wikipedia gives a good overview over its features.

So, what is the problem?

The problem is in the following line:

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt

What this does is take a certificate (certificate.crt) and a private key (privateKey.key) and bundles them into one PKCS #12 file (certificate.pfx).

The error "unable to load private key" and "Expecting: ANY PRIVATE KEY" indicate that what you provided is no private key. What exactly the reason for this is can't be deducted from the information you provided, but here are some wild guesses:

You didn't see that privateKey.key was a placeholder and your file is named differently.
You didn't change into the correct working directory where the certificate and private key were.
You used your public key instead of your private key.
You don't have correct permissions for your private key.
Your private key is not in a recognized format (e.g. newline shenanigans)

I hope this explains the situation well enough and gives you enough pointers to go by to find a solution.


How to choose a password that I have to remember for a long time but do not use a lot

Likely the best option in this kind of scenario is to record the password/passphrase in a physically secure location (e.g. bank vault, safe deposit box).

Relying on human memory to record this kind of information for 10+ years is an extremely bad idea.  For example the person who knows the passphrase leaves the comapny/gets hit by a bus/forgets it.

Writing it down and storing it in (preferably 2+) secure location avoids this kind of issue.


Citation Needed for FIPS Anecdote Regarding MD5 and RC4

TLS is actually one of the rare instances where MD5 is, in fact, specifically stated as being allowed to be used for key agreement.  Citation is in the FIPS 140-2 IG, D.8 (pg. 157, point (e)(1).

SSLv3 use of MD5 is disallowed due to a difference in how MD5 is used.  See footnote 2 at the bottom of page 160 of the same IG:

The problem with SSL 3.0 is the key derivation process that applies to all SSL 3.0 cipher suites: half of the master key that is set up during the SSL key exchange depends entirely on the MD5 hash function. MD5 is not an approved algorithm, and its collision resistance property has been broken by Antoine Joux.
TLS also uses MD5 in the key derivation process, but in a different manner, so that all of the master key depends on both MD5 and SHA-1; nothing in TLS actually depends on MD5 for its security.
Therefore, TLS implementations can be validated under FIPS 140-2, while SSL 3.0 implementations cannot. TLS is version 3.1 of SSL, and most current servers and clients are capable of doing both SSL 3.0 and TLS.

Finally, I am fairly certain that RC4 is completely disallowed. On page 33 of the IG, RC4 is explicitly listed as a non-approved algorithm.  No other caveats are made in the IG with respects to RC4 and I've not experienced any claims in my line of work that would indicate that it could be acceptable in any other circumstances.


Why are WPA2 passwords longer than 16 bytes more secure than 16 byte passwords?

You state your CMAC is 128 bits, so in general you don't need a passphrase with more than 128-bits of entropy.  However, if you choose a 16 character password (without picking the bytes completely randomly), the entropy isn't 128-bits, it's typically much less.  E.g., if you chose randomly from 95 printable ASCII characters, you'd have about 105 bits of entropy (log2(95^16) ~ 105) which is about 8 million times weaker than a 128-bit entropy passphrase.  If you didn't choose randomly, but say concatenated English words, the entropy would be much smaller; e.g., meaningful English has an entropy of about 2.6 bits per character (16*2.6 ~ 42 bits), which would be quite feasible to be broken in offline attacks.

If you want to remember a meaningful English phrase as your passphrase, it should probably be about 50 characters long (128 bits/2.6(bit/char) ~ 49.2).  Or if you chose a diceware passphrase randomly from a dictionary with 6^5 = 7776 words in it (12.9 bits/word), then you need about 10 words to get to 128 bits.

So, to summarize there is an upper limit to security when using a passphrase.  E.g., there's no use having a 20 word diceware passphrase with a 128-bit CMAC (the entropy of the MAC maxes out at 128 bits); the 20-word passphrase won't be more secure than a 10-word one, but a 10 word diceware passphrase will be significantly more secure than a 3 word one (that say has 16 characters in it) with an entropy of about 39 bits.

EDIT: The primary key used in WPA2-PSK is the PMK (pairwise-master-key).  This is derived from the pre-shared password and the name of the access point.  The PMK is 256-bit (32 byte) and calculated via PMK = PBKDF2(HMAC-SHA1, preshared_password, salt=access_point_name, rounds=4096) (where PBKDF2 is password based key-derivation function 2, which in this case involves 4096 rounds of HMAC-SHA1).

If you somehow found a different password that generates the same PMK for an access point, you can connect to the access point, eavesdrop, and tamper with messages.

That said in WPA2 you also derive a transient key (PTK) from the PMK and random nonces sent over during the four-way handshake.  The PTK is 512-bits, parts of which are used for different purposes, but your traffic within a session is encrypted with a 128-bit transient key.  (If you find a encryption key part of the transient key you could decrypt traffic within one session, but that's it -- you wouldn't be able to sign traffic to tamper with it or create new sessions).


Attack WPA password with hashcat - Settings and resources for "german" passwords?

(This thread is cross-posted on the hashcat forums here. My answer there was too simplistic, so I'll try to do a better job here.)

The basics

For wordlists and rules, it sounds like you've already got the basics down. As long as the wordlists are in UTF-8, and the input method used to set the password is also UTF-8, then they should work well. I would definitely pursue wordlists and rules first, because raw bruteforce will take more time than the basic attacks, and WPA/WPA2 is such a "slow" (hard to crack) hash.

The basics of password cracking are already well covered elswhere. Here are some useful howtos (but note that if your target password contains at least one German character, only the wordlist and rule-based techniques will apply to your situation):

adeptus-mechanicus' Cracking Passwords 101
How I Cracked Over 122 Million SHA1 and MD5 Hashed Passwords by m3g9tr0n
Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
Advanced password guessing - Hashcat techniques for the last 20% (PDF, by hashcat's primary developer, atom)

These overviews should help to fill in any gaps in your basic techniques.

Bruteforce of UTF-8 (mixed single-byte and multibyte), part 1 - simple proof of concept

If you do want to pursue bruteforce, you will need to do a little more work, because of how hashcat works under the hood. For cracking purposes, hashcat treats everything as a series of bytes. The German-specific UTF-8 characters are multibyte - represented in UTF-8 with more than one byte.

To bruteforce multibyte, you can specify character sets using the --hex-charset parameter, and use the technique described in this related post from the hashcat forums, which uses masks to simulate bruteforce for multibyte characters.

However, the technique in that post assumes that the charsets are entirely multibyte. German is different, in that only some of the characters are multibyte. Any German word that uses German-specific characters is actually a mix of one-byte-wide and two-byte-wide characters, and hashcat does not distinguish between the two.

So that technique has to be adapted somewhat. I'll briefly cover how here. I use MD5 for simplicity; WPA/WPA2 should work exactly the same (just much slower).

First, we must determine the hex values that will be used in the password mask. An easy way to do this is to create a file that lists the UTF-8 form of all non-ASCII characters that are likely to appear in your passwords, and then show their hex equivalents:

$ for item in `cat german.list`; do echo -e "$item: "; echo -n "$item" | xxd -p; done
Ä: c384
ä: c3a4
É: c389
é: c3a9
Ö: c396
ö: c3b6
Ü: c39c
ü: c3bc
ß: c39f

I'm not familiar with German, but these characters clearly have 'c3' as their first byte. (This is because they are all in the same Unicode block - specifically, the Latin-1 Supplement block). So since all expected multibyte characters will have this byte as a "prefix", we will start with that, and then append all of the "second bytes" using hashcat's custom mask parameters.

Here's a simple walkthrough.

First, we capture our plaintext (using '-n' to ensure that no line breaks are at the end of the string):

$ echo -n 'schön5' >german.plain

Next, we show that the string actually contains the expected two-byte sequence 'c3b6' where we expect it:

$ cat german.plain | xxd -p
736368c3b66e35

Next, we get the MD5 hash of that plain:

$ cat german.plain | md5sum | awk '{print $1}' | tee german.hash
bbf9ee923fe21c044838865c7acf530d

Finally, we run hashcat:

$ ./hashcat -m 0 -a 3 --hex-charset -1 c3 -2 8489969c9fa4a9b6bc german.hash ?a?a?a?1?2?a?a

... with flags explained as follows:

-m 0 (hash mode 0 - MD5)
-a 3 (attack mode 3 - bruteforce)
--hex-charset, to allow specifying hex charsets
-1, the first custom character set (the 'c3' prefix)
-2, the second custom character set (all of the second bytes from our German characters, "8489969c9fa4a9b6bc")
german.hash (our target hash)
a?a?a?1?2?a?a (a simple mask containing all printable 7-bit ASCII (?a) in most positions, and '?1?2' in the "fourth" position)

The command produces this output, showing that we have successfully cracked our target hash:

hashcat (v3.40-73-g99fbaa8) starting...

[informational hashcat output snipped]

INFO: approaching final keyspace, workload adjusted

bbf9ee923fe21c044838865c7acf530d:schön5

Session..........: hashtest
Status...........: Cracked
Hash.Type........: MD5
Hash.Target......: bbf9ee923fe21c044838865c7acf530d
Time.Started.....: Sun Mar 26 08:46:08 2017 (0 secs)
Time.Estimated...: Sun Mar 26 08:46:08 2017 (0 secs)
Guess.Mask.......: ?a?a?a?1?2?a?a [7]
Guess.Charset....: -1 c3, -2 8489969c9fa4a9b6bc, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:  9411.3 MH/s (0.18ms)
Speed.Dev.#2.....:  9896.7 MH/s (0.18ms)
Speed.Dev.#3.....:  4829.7 MH/s (0.27ms)
Speed.Dev.#4.....:  5154.5 MH/s (0.27ms)
Speed.Dev.#5.....:  4555.7 MH/s (0.27ms)
Speed.Dev.#6.....:  4747.7 MH/s (0.27ms)
Speed.Dev.#*.....: 38595.5 MH/s
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 902162052/69640284375 (1.30%)
Rejected.........: 0/902162052 (0.00%)
Restore.Point....: 0/81225 (0.00%)
Candidates.#1....: "yaÄ 1 -> }baü]a
Candidates.#2....: w!cÜ'p -> JWAÖe&
Candidates.#3....: {kaÄ^) -> psaÖ'p
Candidates.#4....: FUSÜe& -> Q!cä.+
Candidates.#5....: @loé.+ -> &11üV<
Candidates.#6....: /11ÄW~ -> :enü~}
HWMon.Dev.#1.....: Temp: 51c Fan: 34% Util: 63% Core:1898MHz Mem:4513MHz Bus:8
HWMon.Dev.#2.....: Temp: 49c Fan: 32% Util: 50% Core:1860MHz Mem:4513MHz Bus:4
HWMon.Dev.#3.....: Temp: 63c Fan:  3% Util: 96% Core:1354MHz Mem:3004MHz Bus:16
HWMon.Dev.#4.....: Temp: 62c Fan:  1% Util:100% Core:1366MHz Mem:3004MHz Bus:4
HWMon.Dev.#5.....: Temp: 65c Fan:  2% Util:100% Core:1379MHz Mem:3004MHz Bus:1
HWMon.Dev.#6.....: Temp: 66c Fan:  3% Util: 97% Core:1366MHz Mem:3004MHz Bus:1

Started: Sun Mar 26 08:45:52 2017
Stopped: Sun Mar 26 08:46:10 2017

Bruteforce of UTF-8, part 2 - with mask coverage

The simple demonstration above shows that the '?1?2' technique works ... but it also presumes that you know exactly which characters are German. In the real world, we usually do not know this.

Instead, rather than using a single mask, you'll need to supply a file that contains a list of all of the masks that cover the length of password that you want to try. Here's an example of a mask file that covers all six-character words that contain at least one 7-bit ASCII equivalent character (?a) and other characters from German using our multibyte mask pairs (?1?2), in all positions:

$ cat utf8.hcmask.6char
?a?a?a?a?a?1?2
?a?a?a?a?1?2?a
?a?a?a?a?1?2?1?2
?a?a?a?1?2?a?a
?a?a?a?1?2?a?1?2
?a?a?a?1?2?1?2?a
?a?a?a?1?2?1?2?1?2
?a?a?1?2?a?a?a
?a?a?1?2?a?a?1?2
?a?a?1?2?a?1?2?a
?a?a?1?2?a?1?2?1?2
?a?a?1?2?1?2?a?a
?a?a?1?2?1?2?a?1?2
?a?a?1?2?1?2?1?2?a
?a?a?1?2?1?2?1?2?1?2
?a?1?2?a?a?a?a
?a?1?2?a?a?a?1?2
?a?1?2?a?a?1?2?a
?a?1?2?a?a?1?2?1?2
?a?1?2?a?1?2?a?a
?a?1?2?a?1?2?a?1?2
?a?1?2?a?1?2?1?2?a
?a?1?2?a?1?2?1?2?1?2
?a?1?2?1?2?a?a?a
?a?1?2?1?2?a?a?1?2
?a?1?2?1?2?a?1?2?a
?a?1?2?1?2?a?1?2?1?2
?a?1?2?1?2?1?2?a?a
?a?1?2?1?2?1?2?a?1?2
?a?1?2?1?2?1?2?1?2?a
?a?1?2?1?2?1?2?1?2?1?2
?1?2?a?a?a?a?a
?1?2?a?a?a?a?1?2
?1?2?a?a?a?1?2?a
?1?2?a?a?a?1?2?1?2
?1?2?a?a?1?2?a?a
?1?2?a?a?1?2?a?1?2
?1?2?a?a?1?2?1?2?a
?1?2?a?a?1?2?1?2?1?2
?1?2?a?1?2?a?a?a
?1?2?a?1?2?a?a?1?2
?1?2?a?1?2?a?1?2?a
?1?2?a?1?2?a?1?2?1?2
?1?2?a?1?2?1?2?a?a
?1?2?a?1?2?1?2?a?1?2
?1?2?a?1?2?1?2?1?2?a
?1?2?a?1?2?1?2?1?2?1?2
?1?2?1?2?a?a?a?a
?1?2?1?2?a?a?a?1?2
?1?2?1?2?a?a?1?2?a
?1?2?1?2?a?a?1?2?1?2
?1?2?1?2?a?1?2?a?a
?1?2?1?2?a?1?2?a?1?2
?1?2?1?2?a?1?2?1?2?a
?1?2?1?2?a?1?2?1?2?1?2
?1?2?1?2?1?2?a?a?a
?1?2?1?2?1?2?a?a?1?2
?1?2?1?2?1?2?a?1?2?a
?1?2?1?2?1?2?a?1?2?1?2
?1?2?1?2?1?2?1?2?a?a
?1?2?1?2?1?2?1?2?a?1?2
?1?2?1?2?1?2?1?2?1?2?a
?1?2?1?2?1?2?1?2?1?2?1?2

To generate the rest of the masks that you need, policygen from the PACK toolkit (Python) can help. It doesn't recognize how to make all permutations of '?1?2', but you can create masks that use a different character set (like ?u), and then replace all '?u' with '?1?2'.

As I said above, it's not for the faint of heart! But once you get the hang of it, it's not hard.

Non-UTF-8 character sets (rare for WPA/WPA2?)

If the characters are not UTF-8, the charsets that hashcat ships with can be used directly. They are in the ./charsets/ directory of the hashcat distribution, and their use is straightforward and common for non-Latin character sets.

That being said, I would expect non-UTF-8 character sets to be rare for WPA/WPA2 passphrases.


Managing a team of IDS experts; how would you organize your team?

It depends on what you want to do with that team.  Sourcefire has a few people working on the core engine, a few on the plugins, and a vulnerability research team writing rules--some of whom had no prior experience with intrusion detection; just exploit writing and reversing.

The setup I'm most familiar with, in contrast, uses a simple tiered system like many service providers.  Junior analysts monitor in realtime and review logs; and the senior analysts take care of ambiguous cases and write rules which are useful locally.


kadmin problem: "Client not found in Kerberos database while initializing kadmin interface"

"Client not found in database" means the principal you used, me/admin, does not exist.

"Required KADM5 principal missing" means that your Kerberos database is missing principals for kadmin/fqdn.of.the.kdc@CORP.ORG as well as the legacy fallback kadmin/admin@CORP.ORG. Add them through kadmin.local.

"Missing keytab entry" usually refers to the service principal on the server's keytab (e.g. host/fqdn.of.my.server).


jwt symmetric signature security risks (from client side)

First of all I am extremely sorry if I did not understood the question correctly.

IMHO, if a token got hijacked (implementing MiTM), then the malicious user (especially if signature is not verified and the TTL of token is infinite) can use it to impersonate as server, pushing and update (depends on how you actually built your service) and doing anything he can by impersonating server responses. Or he can impersonate the client, and try to update account details in application.

Regarding the difficulty of such attack, it requires to be targeted (because hacker have to listen to traffic first), and depends much on a server side\client side settings (storing token in server side cookies not accessible by javascript to defend against physical access, setting TTL to a very short time, and so on).


May I install more than one anti ransomware on the same pc?

The reason some vendors recommend that you don't install multiple antivirus/antimalware solutions is because some of these solutions contain signatures used to detect the malware.  In this case other solutions may incorrectly identify the antimalware solution as malware itself, and attack it.  Now you have the system attacking itself, which may lead to stability issues or a false sense of security where you believe you're protected, but you really aren't.  Nobody but the vendors themselves can say which program combinations will cause issues.  Unless you're willing to install all of them and test it yourself.

The best solution against randomware tools is to have recent, full backups of your system.


Does it matter in which programming language you write the shellcode?

The term "shellcode" comes from the fact that it is typically used to gain shell access on the machine. In most cases, shellcode is used when there is a memory corruption-based vulnerability (e.g. buffer overflow) where the attacker is able to write to parts of memory that will be executed or caused to execute. This needs to be machine code, since it is being executed directly by the CPU.

Since there is often limited space to work with in the buffer, shellcode is often designed to be as short as possible, thus it is often written by hand in assembly and dumped to an escaped bytes sequence (e.g. "\x23\xa4\x00"). It is possible to write a C program, compile it, then dump the bytes like above, but the C compiler may introduce unnecessary complexities and add additional length. Usually, the shellcode will be short, and could pull down a second stage off the network if a longer payload is desired.

In short, you need machine code, and it doesn't really matter whether this code came from C or assembly, excepting what was said above. However, the definition of shellcode is somewhat loose and could be applied to interpreted languages as well (e.g. getting a shell by exploiting an unsanitized call to eval() in a Python application), although it is typically not the chosen word in these cases.


Separate networks on one modem for security reasons

I can think of two ways offhand:

Put client 2 on a guest network. That will separate the two clients while still allowing port forwarding to client 1.
Use 3 routers. modem -> router1, then router1 -> router2 and router1 -> router3
Anything plugged into either router 2 or 3 is effectively VLANed from the other.  This will also allow you to assign a static IP to each router, and then port-forward from router1 to whichever router you have for client 1, and then set up that router's port forwarding as well. This is a bit convoluted but should do what you need. Additionally, anything else plugged into router 1 would be able to communicate with anything using either router 2 and 3.


Website online assistant asked for my password

You have two big issues here.  Let's get the easy one out of the way:
No, they should not ask for your username and password
Since you said you contacted them through their on-website live support, one of two things was happening:

Their website got hacked and you narrowly avoided giving your login credentials (and therefore money) to a hacker
They have poorly developed support infrastructure and poorly trained support employees.  If you gave away your credentials something bad may have happened, although you might have been perfectly fine.

Personally I'd probably go with #2 - if a hacker had taken over their website they would have had much more effective ways of collecting your credentials than waiting for you to open the chat and ask for your username/password.
Unfortunately many businesses don't understand the dangers of asking their users for their credentials.  There are two main risks in doing this:

Employees are a major source of trouble themselves, and so there is no guarantee that an employee won't steal from a customer if they are given username/password while doing their job, and see an account full of money on the other end.
Regardless, it trains their customers that giving away username/password is okay, making them more vulnerable to future phishing attempts.

So: This is not safe.  This is not reasonable.  It is however somewhat normal (although shouldn't be).  I would at least complain to their support and try to explain why this is such a bad idea, although don't expect them to take you seriously.  I would probably try to find a new place to take my money.  Onto issue #2
Using an easy-to-guess rule for password generation is not a great idea
You said:

I use a variation of the same password for every website that would be
pretty easy to figure out if one tried, because i thought no human
would ever see them and everything is supposed to be store encrypted.

This is a very bad assumption.  Unfortunately passwords get leaked from websites all the time, and oftentimes in forms that allow hackers to figure out what the password is (presuming it isn't just in plain text, which still happens).  As a result you should assume that your password will be seen by people, and therefore pick a password that is completely unique to each account.  The best way to do that is with password managers.  Obviously many people don't want to put forth the effort to use one, but at the very least if you have an important account (which this would be if it is protecting >$1,000 of your money), it should really have its own strong, unique password.


What policies maximize employee buy-in to security?

Social norms. If employees see the managers taking security seriously, it sets a cultural expectation that to get ahead in this company, I must need to take security seriously.


Will data be seen if an insecure packet is sent to an offline server?

If the website is not listening on port 80 and the address http://website.com (or whatever URL, assuming website.com here means the domain that is listening on port 443 and not listening on port 80) is entered in the browser then you will only see a couple TCP SYN packets, not the HTTP request. This is because the TCP connection is attempted but not completed and so no HTTP protocol request gets sent.

On the other hand if the website redirects HTTP to HTTPS (and so is listening on port 80 and 443) then the initial HTTP request will be seen and will receive a 302 (redirect) response.


Should I be concerned at the lack for transparency by Microsoft which quietly added 17 root certs?

No, new root certificates are added on a regular basis. Microsoft have a Trusted Root Certificate programme enabling CAs to enroll.

This happens with most products that handle certificate verification. For example, this is Mozilla's list where you can see that there are several added per year.

For Microsoft's list you can simply check your Windows OS's certificate store for root certs.


What does it mean when airodump-ng shows 0 beacons?

It means the access point is a hidden station which means it does not send any beacons. Airodump knows of the network existence and it's SSID because the clients did revealed it. This is why a hidden station isn't a secure one. As soon as a client is connected at least the BISSD is visible to everyone with a card in monitor mode.


Is there a way to program to discover sites transmitting user/pass in plaintext (Not using SSL) for penetration testing?

Yes. You can use a packet sniffer like Wireshark to observe the contents of the data packets as they travel between the website of interest and your computer.

Login using a unique string as the password, and search in Wireshark to find that string. It doesn't matter if it's the actual password or not, just as long as it is sent to the server.

If you are able to see that unique string in Wireshark, that must mean the password is being transmitted in the clear - i.e. over HTTP.


Security measures for "Forgot password" link

They usually restrict the length of time that the code is valid. This is possibly the key security feature.

It is actually relatively safe. An attacker is not going to be able to brute force, as it will time out or overdo attempts, so they would need to compromise the email account.


Is possible to attack a Wordpress website if someone know username and password of admin account?

As every lawyers first sentence: It depends. So without exactly knowing what you did, let's do a little "risk-assessment".

There are multiple ways of compromising wordpress based websites:

knowing the admin-credentials
finding a vulnerability in wordpress
discovering a vulnerability in one of the used plugins
finding a vulnerability in the webserver or it's configuration

Where vulnerability as in: Software-vulnerability, misconfiguration and so on.
Also we have to further split all those possibilities into two options:

going from zero to admin
escalating from user to admin

So let's see what you have accomplished: If the admin-access really is blocked and properly blocked, knowing the admin-credentials is not a direct threat to the page anymore (it can still be if you reuse credentials from somewhere else or if your .htaccess or function does not block all the resources properly).

There is still multiple options to go for when targeting your site. I suggest you have a look at this page. The statistics are a little too agressive in my opinion but you will get a feeling for the problems you might face when protecting your site.

  “73.2% of the most popular WordPress installations are vulnerable to vulnerabilities which can be detected using free automated tools.” – WpWhiteSecurity.com

This seems quite a lot to me but it's not unimaginable. That is not exactly what you are asking but it's some information to consider when thinking about how to lock down your site.
There also is a quote about credentials but its really out of context so read the links carefully before really making your opinion.

So without knowing your exact target or your exact approach: Locking down your admin account is a nice approach (if it works properly) but credentials are not the only way to transform wordpress installations into something else. And probably (careful; assumption) they are not really needed in most of the cases. If someone manages to find some SQLi or RCE in your WP installation (not unlikely as shown before) or one of the plugins (even more likely) your security measure might not really catch.


Are there virus scanners for Windows that can be run without installation?

ClamAV a popular open-source AV scanner has a portable app version available on portableapps.com.  This should allow you to manually scan drives and files from the USB drive, but the always-on background scanner will not work as that requires installation.


Creating botnet C&C server. What architecture should I use? IRC? HTTP?

For a C&C server, you want to achieve the following characteristics:

The infected system must be able to talk to the C&C. This entails getting some data out of the machine, through whatever network access it has. The easy case is when the machine has full Internet access (possibly through some NAT); however, there are networks (especially in business environments) where machines have only local addresses, there is no NAT, and outbound communications must go through a HTTP proxy. Possibly, the proxy will need some authentication, that may be automatically provided by the OS (Windows...) provided that the OS libraries are used to do so.

Thus, HTTP increases the probability of succeeding at connecting to an external server, whereas IRC cannot really handle the "proxy only" case.

On the minus side, HTTP is a client-driven protocol, so the infected machine must "poll" the server (issue requests regularly); it cannot simply wait for an incoming command. This regular activity may allow for easier detection of the infection, and will also increase bandwidth requirements for the C&C, especially for large botnets. IRC would be lighter in that situation.
You want the data transfers to be undetected by the network administrator. Such sysadmins tend to strongly react to any network activity that uses the traditional ports for IRC (e.g. freenode uses 6665, 6666, 6667 and a few others). There again, HTTP will be more likely to "fly under the radar".

Plain HTTP requests may be inspected by nosy firewalls. HTTPS may help you here; decrypting HTTPS requests requires installing and maintaining a custom certification authority that produces on-the-fly fake certificates for contacted Web sites. There are appliances that offer that kind of service, but this is not yet fully widespread.
You want to hide the true C&C server whereabouts. If you have a large botnet, then it is a certainty that some sysadmin, somewhere, will notice something fishy and try to guess where the C&C is. HTTP requests require the client to know the target server IP address. On the other hand, with IRC, the infected host would connect to a nearby "honest" IRC server, and, by the magic of data flow between IRC servers, the data may reach the C&C wherever it currently hides.

For a more complete solution, you would like the C&C to be hidden as a Tor hidden service. Note that the true IP address of a hidden service remains hidden only as long as the assumptions behind the onion network theory hold, in particular that the "uncorrupted" onion routers remain a large majority. Whether this is true in practice is anybody's guess.

A really efficient botnet would be structured as an old-fashioned spy network, with decentralized cells; botnet machines would not know the C&C address, but merely how to talk to the other machines in the cell, as well as one or two machines from other cells. Messages would then be broadcast by hopping from cell to cell. That kind of structure requires a lot more thinking at the design phase, but would be a lot more resilient to dismantlement by law enforcement forces.

(Fortunately, ill-intentioned people who want to run botnets are no less lazy and incompetent than the rest of the World, so well-designed botnet structures remain a rarity.)


If mod_sec is showing that an unknown domain was attacked then its possible that you still have a default vhost configuration in place on the server.
The default vhost on most distros has no ServerName associated to it, so it will respond to all requests that do not match a ServerName directive in another virtual host. Its probably a good idea to disable the default vhost if you don't need it.

As packs mentioned in his comment, posting some log files would help with diagnosing it further.


You are likely injecting into something like this:

<input type="text" value="[payload]">

What you are currently doing is closing the value attribute with " and the input tag with >, and then adding your script payload:

<input type="text" value=""><script>alert(3)</script>">

If you don't want the DOM to look broken, you need to fix the remaining characters (">). These are not from your attack string, but the remaining ones from the legitimate tag the application is using.

One way to fix this would be to use the following payload:

"><script>alert(3)</script><x y="

This will now result in:

<input type="text" value=""><script>alert(3)</script><x y="">


Storing certificate bundles (.pfx files)

The good practice is to separate certificates as well as private keys from the application resources. Developers should have no control over what certificates the application can trust to and what private keys the application uses.


Is showing CAPTCHA after n failed attempts less secure?

If brute forcing is your main worry you can just have it show up after 5 attempts or maybe even 10. If someone tried 5 variations of their password it sounds pretty reasonable to have a captcha pull up, even with elderly users.

When you are talking about brute forcing we could be talking about hundreds of attempts within a few seconds, so that would still help with mitigating that.


Possible? Yes. Probable? Hardly. It's way more a reliability (or availability) issue than a security one.

A faulty RAM can lead to data corruption, and that corruption almost always will lead to a Segmentation Fault and crash the process. If the process is the kernel, or a critical process (like init on Linux systems), the entire computer crashes.

A less common effect is basically a hardware-induced RowHammer Attack. In this attack, a cell have its value changed intentionally. If you RAM banks are defective, there's an infinitesimal (but bigger than zero) chance that the byte changed will not crash the application and give it super powers. A bash shell with UID 0 or a cmd.exe instance with admin privileges are possible, but so improbable that you cannot count on it.

But leveraging a fault memory chip to actually attack the computer is almost out of question. An attacker that can execute code on the computer could employ countless privilege escalation attacks to gain more access, and an attacker with physical access can just take the disk, image it, and leave.


Is it safe to let a user type a regex as a search input?

I would compare accepting user supplied regular expressions to parsing most sorts of structured user input, such as date strings or markdown, in terms of risk of code execution. Regular expressions are much more complex than date strings or markdown (although safely producing html from untrusted markdown has its own risks) and so represents more room for exploitation, but the basic principle is the same: exploitation involves finding unexpected side effects of the parsing/compilation/matching process.

Most regex libraries are mature and part of the standard library in many languages, which is a pretty good (but not certain) indicator that it's free of major issues leading to code execution.That is to say, it does increase your attack surface, but it's not unreasonable to make the measured decision to accept that relatively minor risk.

Denial of service attacks are a little trickier. I think most regular expression libraries are designed with performance in mind but do not count mitigation of intentionally slow input among their core design goals. The appropriateness of accepting user supplied regular expressions from the DoS perspective is more library dependent.For example, the .NET regex library accepts a timeout which could be used to mitigate DoS attacks.RE2 guarantees execution in time linear to input size which may be acceptable if you know your search corpus falls within some reasonable size limit.

In situations where availability is absolutely critical or you're trying to minimize your attack surface as much as possible it makes sense to avoid accepting user regex, but I think it's a defensible practice.


Android boot sequence - verified boot security

I can't speak to Qualcomm or Android in particular, but any time that you're doing code signing, the client needs to begin its chain of trust somewhere. And an immutable, non-upgradable, non-revocable public key pinned in firmware is as good a way to do that as any.

A non-upgradable root public key makes sense (proof by induction)

You asked:

  The public key in PBL cannot be changed. Correct?

Proof sketch:

Any software component that needs to be field-upgradable needs to be able to verify the integrity and authenticity of its software prior to running it.
Verifying software integrity and authenticity is typically done via digital signatures.
The device must have or be able to obtain the public key that performed the digital signature.
If this public key is itself contained in a field-upgradable block of code or data, then the integrity and authenticity of that must be verified via digital signature.
The device must have or be able to obtain the public key that performed the digital signature.
If this public key is itself contained in a field-upgradable block of code or data, ...

This becomes an infinite stack of turtles (or in this case, public keys), and the only way it can terminate is if there is some root public key which is not field upgradable, ie we have absolute trust in that key and do not need to verify its integrity and authenticity.

QED.

Answering your other two questions (in backwards order)

  If Qualcomm's private key was somehow compromised, verified boot could no longer be trusted on all affected devices permanently?

Pick any PKI  structure (the public HTTPS PKI, the DNSSEC PKI, the Windows Code-Signing PKI) and there will always be an analogous doomsday scenario about the topmost root key being compromised. That's just how PKI works.

To protect against this, Certificate Authorities invest ludicrous amounts of time and money into HSMs, network security equipment, and human policies to protect the root keys. But at the end of the day, we sortof rely on good old fashioned word of mouth (ArsTechnica, Twitter, Reddit, etc) to tell us if one of these root keys becomes compromised.

  Is it safe to assume that millions of Qualcomm devices all have the exact same public key programmed in PBL?

Some companies will keep separate code-signing PKIs for separate product lines so that one product line can be revoked without affecting the others. Realistically though, if they have a massive breach on that scale, then nobody's gonna trust anything anyway, so why bother?


Bypass char filtering - security shephard

My answer got longer than expected, so just to give you the answer:  probably works, and if it doesn't,  will.

How to try to bypass a custom filter

You say you try to learn how to do is yourself, so here are some first steps I would take:

check case: not all filters are case sensitive. Is I also substituted, or just i?
check alternative encodings: : isn't allowed, but &#58; may be (and it works the same in most contexts).
check what the filter is actually doing. Are replacements always done, or only in certain contexts (eg is i always filtered, or only in script, or only surrounded by characters, or ...)? Are filters only applied once (eg <scri (doesn't contain


How to delete a C# variable value permanently from memory?

Just setting a string to null or calling the GC will not help here. It might delete the reference to the value, but not the value itself. After GC, it may be overwritten, but there is no guarantee that it will happend anytime soon.
What you need instead is something aking to a SecureString, that implements a Dispose method and some obfuscation. However, the security it provides is limited:

We don't recommend that you use the SecureString class for new development. For more information, see SecureString shouldn't be used on GitHub.
SecureString is a string type that provides a measure of security. It tries to avoid storing potentially sensitive strings in process memory as plain text. (For limitations, however, see the How secure is SecureString? section.)

The problem here is that if there is sufficently advanced malware with sufficiently high priviliges on your system, no secrets are safe no matter what fancy C# types you wrap them in. So I am not sure this is a problem with a solution.
If you do use a secure string, think about how you get the value into and out of it. If it passes through an ordinary string, you have gained absolutely nothing.


What are advantages of SSL VPN over IPSec VPN, if any?

Security wise there's no really big difference, as both IPsec VPN and SSL VPN can use similar encryption algorithms. Some sources like Paul Bischoff's VPN encryption explained: IPSec vs SSL may state that IPsec VPN requires a PSK that could be a security concern, but many implementations actually allows certificate based authentication for IPsec tunnels.
Advantages depends on use case
The key difference is that, as a higher layer protocol, TLS used in SSL VPN can easily go through NAT, whereas IPsec VPN requires NAT traversal techniques, and they aren't always working on all networks. Also, as TLS used for VPN isn't easy to distinguish from other TLS protocols like HTTPS, it's harder to block on firewalls. This makes SSL VPN ideal for client-to-site VPNs.
On the other hand, IPsec VPN (especially IKEv2) can negotiate connections faster, so there might be performance advantages. This performance and reliability perspective makes IPsec VPN ideal for site-to-site VPNs, as they typically don't have to deal with NAT traversal.


The 72-character limit is caused by Blowfish cipher, which is used internally for Bcrypt. You can limit the length of the password in your application, truncate it, or (may not be the brightest idea) hash it and pass the output of the hash function to Bcrypt. Either way, it is not possible to beat the Bcrypt cipher's internal limit.


public WiFi hotspot-What is leaking at that tiny moment before connecting to a VPN?

Between connecting to the hotspot and establishing the VPN nothing is protected(encrypted) by the VPN.
Anything already encrypted (HTTPS/SSL/etc.) can not be read by the hotspot owner without installing a certificate on your device, but that requires your active permission. Specifically the Gmail app uses encryption.
The opposite is also true, anything not encrypted can be read as plain text from the hotspot owner.

Some VPN apps like FREEDOME from F-Secure have an automatic killswitch (screenshot below) that blocks all in- and outgoing connections until the VPN is established.


What type of CA is "Management CA" in EJBCA?

EJBCA requires client certificates to allow administrators to log in to its user interface. The Management CA issues these certificates as well as the default TLS certificate for the interface.


If a password is encrypted and then the encryption is stolen is it best practise to change plaintext passwords?

However; if a company uses "robust" password security and password hashes; is there a security need to then change these hashes ... as every time the hash is generated it will be different.

Aside: The hash isn't different every time, it's different per-user. If a hash was different every time it was computed we'd have no way to compare a user's submitted password and their stored password.

Yes, there is a security need to change passwords when they are compromised - there is no way of knowing how strong user passwords were, and there is no way of knowing your attacker's password hashing capabilities. If you leak an individual salt, high difficulty bcrypt hash of the password 'password', it's still going to be cracked in minutes. Forcing users to reset their password ensures that even weak passwords won't be exposed.

  Is it a good idea based on the idea some point in the future BCRYPTs may become easy to bruteforce?

No, the reason is as above - you are insulating users from their own weak password choices. Additionally, a stolen bcrypt database may become more feasible to brute force as processing power increases, but A: We're not seeing dramatic increases in processing power nearly as frequently as a few years ago and B: Ideally, the administrator is increasing the difficulty factor of the bcrypt hash as time goes on - the algorithm is designed to be easily tune-able for difficulty.


Is using a CA more secure if I'm self-signing anyway?

The distinction depends on some details about the self-signed certificate and how the browser and the OS will react to it.

A normal certificate includes a Basic Constraints extension which contains a flag telling whether the certificate is for a CA or not; when the flag is TRUE then the certificate is considered acceptable as an issuer for other certificates. If the extension is altogether missing, then the certificate is to be considered as non-CA.

Root CA certificates are "special"; they are not true certificates. They are trust anchors; a TA is, nominally, a public key coupled with a name. It is traditional to encode trust anchors as certificates, and since a certificate includes a field for a signature, some bytes must be stored there; there again, Tradition says that we shall make the certificate self-signed. Nobody really checks that signature, though; junk bytes of approximately the right size would serve just as well.

The tricky point is then that the interpretation of the certificate extensions, if any, found in such a "root CA certificate", is non-standard. In particular, some historical root CA date from before the invention of the Basic Constraints extension; as true certificates, they would be interpreted as "not CA", but since they are trust anchors disguised as certificates, the normal interpretation rules do not apply.

So on some browsers or OS, a non-CA certificate (lacking a Basic Constraints extension, or even featuring one with the cA flag set to FALSE), once installed in the "root CA" store, may very well begin to be accepted as a CA. Thus, confidentiality of the private key for any certificate installed in the user's trust store is rather critical.

What's the difference in your case ? After all, in your situation, there are two choices:

You create a self-signed certificate for your server, and the user installs that certificate as "trusted".
You create a self-signed CA certificate, that the user installs as "trusted". You issue a normal certificate for your server with this CA.

In both cases, the user surrenders his security to some certificate from you, that the user installs as "trusted". So what would it change ?

The difference is that if you use a custom CA, you can store the corresponding private key with good protection. For instance, you do the CA business on a laptop which is kept offline at all times. There is no possibility of a remote exploit when there is no network at all. Root CA should always be offline, and used only as part of manual procedures and USB keys for data transfer. On the other hand, your server is, well, a server, so it is online and intrinsically exposed. An attacker who hacks into your server may get a copy of the server's private key. If the corresponding public key has been installed as "trusted root" in the users' machines, then the attacker gains a lot of leverage on these machines as well.

Briefly said, making a custom CA distinct from the server's certificate (as used all day long) allows for better protection of the private key, and thus a lower risk of catastrophic attacker's power escalation.

There are browsers which are not as vulnerable. What you really want, with a self-signed server certificate, is that the users trust that certificate only for SSL connections (not as a CA), and only for that specific server. Firefox knows how to do that; it is called a "security exception" in Firefox terminology (see the Preferences -> Advanced -> Certificates -> View Certificates, then the "Servers" tab).


What is the impact of RSA key's size on CPU load?

In SSH, RSA keys are used only during the initial connection setup. Once you are connected, size of RSA key has no consequence whatsoever on CPU and bandwidth usage for transferring files. The initial handshake uses asymmetric algorithms (RSA, Diffie-Hellman) to handle authentication and setup of a shared secret, which is then used with symmetric cryptographic algorithms to encrypt and protect the remaining of the data exchange.

During the initial connection setup, the server will send its public key to the client and compute a signature, that the client will verify. If the client wants to be authenticated with its own RSA key pair, it will also compute a signature (verified by the server) and send the public key over the wire. A 4096-bit RSA key is twice larger than a 2048-bit RSA key, and signatures have the same size as the key, so if you have a 2048-bit RSA key and changes it into a 4096-bit RSA key, then the relevant messages in the initial handshake will be enlarged by a total of 512 bytes (+256 bytes for the key itself, and +256 bytes for the signature). I repeat, this is only for the initial handshake; it changes nothing for the gigabytes of files that you thereafter sent in the connection.

As for CPU consumption: doubling the key size more-or-less multiplies by 8 the cost of generating a signature. However, there again, this cost is only for the initial connection, and a small PC can already compute hundreds of 2048-bit RSA signatures per second.

Compression is done on the data before encryption and is in no way impacted by any cryptographic element.


HTTPOnly Cookies: Security Depends on Client Cooperation?

Yup, that's the exact definition of a HTTPOnly cookie. Of course the client can do whatever it wants to itself - so this isn't surprising. The goal is to protect the client from malicious websites (as opposed to protecting the client from itself).

This segues nicely into one of the Golden Rules of programming, with extra emphasis on game development: Don't trust the client.


Does the symmetric key exchange through asymmetric encryption have to be done asymmetrically?

In your very specific scenario this is true. Asymmetric encryption is used in a lot of cases primarily to secure a key transfer because it is really slow in comparision to symmetric encryption.

The problem with symmetric encryption on the other hand is that the key exchange cannot be protected in an automated way when only using symmetric encryption. In your case the only person with a assymetric keypair is bob so if one wanted to send a key in a secure way, the only recipient can be bob.


Looking for credit card data and other PII in files

ccsrch is a tool for exactly this purpose.  I have seen QSAs use this as part of their audits.

Personally, I'm not fond of it.  I've run it against a file with 100k cards and it found all 50k of them.  I got better hit rates with a python script I threw together in an afternoon.  And the output requires lots of manual review to weed out false positives.

But, again, QSAs use it, and it's better than nothing.


Don't have Chrome on this computer, but doesn't it have a new tab behavior that includes clickable thumbnails for sites you have recently visited?  If it does I would think those may be the images for that feature.


How many connections can TCP_WRAPPERS handle?

It depends on the hardware available and how you've configured the underlying OS - tcpd runs in user-space.

(NB if you have long lists of hosts, then do make sure you've got NIS maps set up for them).


Securing fingerprint templates stored on web authentication server

The plugin gets the fingerprint from the scanner and encrypts it using a randomly generated 256 AES key and then encrypts this AES using the authentication server public key.

Yeah... the big question is....

Where are you storing the server private key ?

If its on a HSM then great.  If not, then there's a nice weak link....


How should I securely type a password in front of a lot of people?

Use the blanket of security, as seen in the Snowden documentary Citizenfour.
It involves placing a blanket over your head, the keyboard and monitor and typing in the password.
It will look weird but for security's sake it may be worth it.

Related post with demo pic - In CitizenFour, what was Edward Snowden mitigating with a head blanket?


Are there any public examples of an encrypted attribute in a Verisign-issued certificate?

This comment seems to talk about an old VeriSign extension called CZAG. It appeared to have been relatively common a dozen years ago, but I am not sure it is still used. Indeed, it seems that the encryption system was extremely sloppy; this article (published at Usenix in 2002) describes the extension, what it contains, and what it leaks through really poor use of cryptography.

Searching the extension OID (2.16.840.1.113733.1.6.3) on Google uncovers some examples of certificates containing that extension, e.g. this one (this is a GitHub URL, I am not sure how long it will be valid).

It seems that the use case for this extension was of the kind "VeriSign wants to make money". The commercial promise was that users, with CZAG-enabled certificates, could register on some Web sites, the site automatically extracting the user's demographics ("Country, Zip, Age and Gender") without requiring the user to enter the information themselves. For some reason, back in these days, people thought that it was cool to have random Web sites automatically access their private information without control. Anyway, it was an opt-out system, so it can be assumed that most users were simply unaware of these shenanigans.

Most of the references to CZAG I find are from before the 2002 article, so my guess is that this extension was discreetly removed from VeriSign's procedures once it was demonstrated how weak the obfuscation was.


Why is my Mac trying to connect to an http://akamai.com server

If you are looking to find out the current TCP connections and their programs/PIDs, you can start by running netstat -antp, where the -p option shows the PID for each connection. If you have a very busy box, with lots of connection, pipe the output to a more command, like this: netstat -antp | more.

For completeness' sake, correlate the information with either the top command or ps aux.

I am not 100% sure on Macs, though; sorry. Feel free to play about with the netstat on Mac OS. Also, you can refer to their online man page here.

If you feel the need to do a deeper inspection, once you have performed the aforementioned steps, try a packet sniffer, such as Wireshark.

Even if you do not manage to find out what it is - you should be able, but assuming you couldn't, you could still block the outgoing connection at the local machine, and/or blocking the IP from entering your network at the perimeter level by blocking incoming connections on your router.

Update

For Macs you might try lsof -i 4tcp, which would give you the output in the following order:

  COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME