Phishing emails - What do I look for? I want to be able to spot a phishing email. What are the things to check when investigating and doing forensics on one?

There are some things I know to look for already but I want to get moer technical with it.
Here are some things I already look for:

verify the sender (actually looking at the senders email rather than just the displayed name)
hover over the link in the email and look at the URL address listed at the bottom. If the URL looks suspicious, dont click it. I almost never click links in my email anyways.
only attached .txt files are safe, otherwise I do not download anything attached to the email unless I was expecting it and I verified it is from the person I knew it was supposed to come from. Found a good write up here on how to check attachments https://security.stackexchange.com/a/32931/22691
I believe there is a way to check the header of the email. Checking the domain name and IP address in the “Received” field which will validate if it was spoofed by a email spoofing site or someone with a suspicious email address. If it is just the IP address you can check it using a site like whois.com.
Also checking the validation results in the Received-SPF field in the header. Mail sent from permitted servers will show up as “Pass” in the Received-SPF field, which is a very strong indicator that the email is legitimate. If the results show “Fail” or “Softfail”, that’s a sign the email may be spoofed, though it’s not 100% certain since some domains don’t keep their SPF records up to date, resulting in validation failures.
Look out for how the email was written. If it is misspelled a lot, similar spellings to what you would expect making it look suspicious, sounds urgent or threatning, asking for any personal data like passwords/social security numbers/etc

Is there anything that I am missing?

You've got a few important ones on your list already, such as spelling mistakes and display names vs. sender address. Also the redirection links are good to investigate before clicking.

But then there are also some serious erroneous assumptions that can get you in trouble:

.txt files are not necessarily safe. Editors have vulnerabilities and sometimes extensions are hidden by your OS which only make it look like a text file.
Good spoofing attacks will generally come from a server that has been compromised and still has a good reputation. IP address look-ups don't necessarily tell you anything about trustworthiness.
Besides the IP address itself, there are many companies that use third party email services to send out legitimate emails. It is hard to tell if an IP address belongs to a legitimate service simply because there are so many.
Trusting the SPF check result in an email header as an indicator of spoofing is a bad practice. Legitimate emails that get forwarded generally have failing SPF checks, while good spoofers of malicious emails generally have passing SPF checks. This is because the SPF check is being executed on the domain that corresponds with the Return-Path address, where bounces / Non-Delivery Reports (NDRs) are sent. While most email clients show the From: field of an email, which is not technically linked to the Return-Path domain.

What to look for then?

DMARC is a newer standard that works on top of SPF and DKIM (DomainKeys Identified Mail). It actually demands alignment between the domains used in both authentication checks, with the domain used in FROM field address. The DMARC result is usually added to the Authentication-Results header. It passes if either one of both SPF or DKIM produces a Pass result in alignment with the From: field domain.

If a DMARC record is not present for the From: address domain, you can check yourself if the SPF domain or DKIM domain (d= tag) match up with the domain in the From: header (not the Sender: header or Reply-to: header or any other header).

Holy grail

There is no such thing as the holy grail of anti-phishing. There are DNS and ASCII-art attacks possibly impacting DMARC results. DMARC can pass on a common domain A while the Display Name used was from common domain B. ex: From: Bank of America <support@uber.com>.
You need to apply all tactics and always think twice when you are requested to fill out PII, credentials, banking information or download attachments or click links.


Is it fundamentally possible to validate that an unmodified version of your client connects to your server? Is it fundamentally possible to validate that an unmodified version of your client connects to your server?
I was just thinking about the idea of having my client-side app hash its own source code and sends that as a key to the server with any requests as proof that it's unmodified, but that's silly because anyone could just have the client send a hash of the unmodified version via a modified version.
I was wondering if there might be a secure way to do this though, via some sort of proof that the client was unmodified.

It is fundamentally impossible to validate a client on a system you don't control.

That doesn't mean it can't be done to a sufficient degree.  eBook readers, for example, generally try to ensure the client is authentic.  They (seem to) do so in a manner that is secure enough to defend against their threat.  Good enough to protect nuclear secrets?  No.  But good enough for their threat environment.

Figure out how important that control is for your application, and determine the compensating controls you'll put in place to limit the damage when someone goes through the trouble of ripping apart and then mimicking your application.  Don't think in terms of black/white, possible/impossible; think in terms of acceptable and achievable security.


Is a security question you just have to 'remember' a good idea? I was setting my eBay security questions and one of the choices were:

Now I've seen sites that allow you to "type your own question" and "type your own answer" but unless they forgot a text field, this seems like a bad idea!

Not only would you need to remember "your own phrase" you would also need to remember the answer.

Is this a scheme a good idea?

Edit:

I just realized this could most likely means you type in the phrase as the answer. Don't know why I didn't realize this.

Usual process

There are two common ways to implement the so-called "security question" (which I don't think to be very secure anyway, but that's another subject):

Propose the user to choose a question from a set of already defined questions,
Propose the user to type his own question.

The issue with the first possibility is that you will have a very large ratio of your users who will reuse the very same question like their first pet's name, for instance. This can be a weakness since an attacker can, with this example, use a dictionary of common pet names against all users who chose this question.

With the second possibility, you just encourage your users to use different questions. While the risk here is that they may use even weaker question, at least there will be a wider range of different questions making any automation attempts a bit more difficult for the attacker.

However, in both cases the question remains public, only the answer is secret. When you click on the "I forgot my password" link, in any of these situations you will be prompted with your question (either the one you've chosen or the one you typed) and will have to provide the correct answer to get back your access.

If you encounter a website requiring you to type both your question and answer during the password reset procedure, then you can bet that this process has been designed by someone a bit screwy (and that this process will most probably be changed quickly when the support department gets fed up with users' complaints).

Screenshot's specific case

The goal of any authentication system is to let you prove your identity in some way. The most quick one is by using a secret password, or in another word a secret shared between you and the service to which you would like to prove your identity.

If you forget such shared secret, then comes the security question(s): they will offer you an alternative way to prove your identity by giving some details regarding your personal life that (hopefully) only you may now.

Having a question asking again for a shared secret seems just plain useless, as it does not provide any alternative way to prove your identity: if you have lost your main shared secret, most chances are that your have lost this other one too.

So I would definitively class this one in the "screwy" category.


How to replace certain backup files on a website every 30 minutes? I have a website built with WordPress, unfortunately somebody hacked it several times, deleted my adsense code and put his own adsense.
I tried many security techniques, changed database name, did some stuff to prevent anybody from editing files through admin panel etc...
But this guy infiltrated and put his adsense code again yesterday. Because of this, I couldn't make any money yesterday, google adsense doesn't appear immediately, it takes more than 12 hours.
He only changes 2 files, header.php (template's file) and ads.txt (on the main directory).
How can I renew these 2 files (replace old ones with backup ones) every 30 minutes automatically?
Thank you!

Reverting the changes every 30 minutes is not a solution. You absolutely need to find out the root cause and stop this from happening by removing the vulnerability or the persistence. This may include monitoring the logs and other forensics, but also a fresh installation of WordPress (or in worst case the entire server) might be required.


Google Chrome "Your connection to website is encrypted with obsolete cryptography" Google Chrome is showing new information in the certificate section.

Is this a big deal? If so how can I fix it on the server end?

EDIT: Thanks for the answers but I'm not skilled in cryptography so the only thing I can update with is this certificate was created by Shell in a Box, and I was also wondering if this was ruining the security of TLS/SSL communication with the application and if so, how I could fix it.

Your exact case is that RSA is used as the key exchange mechanism. Instead, you should use DHE_RSA or ECDHE_RSA.

To remove the "obsolete cryptography" warning, you'll need to use "modern cryptography" which is defined as:

Protocol: TLS 1.2 or QUIC
Cipher: AES_128_GCM or CHACHA20_POLY1305
Key exchange: DHE_RSA or ECDHE_RSA or ECDHE_ECDSA

Twitter discussion: https://twitter.com/reschly/status/534956038353477632

Commit: https://codereview.chromium.org/703143003

This has nothing to do with a certificate. There is a special "outdated security settings" warning when a certificate uses weak signature algorithm, but this is about authentication, not about encryption. Note that you are still getting a green lock, even in case of obsolete encryption.


When websites use SMS as part of a password reset scheme, why do they ask for the user's phone number? I've noticed if you do a password reset on iCloud, for example, it prompts you for your phone number before sending the SMS.

Since many people already know your phone number, or it may be listed publicly somewhere, why do websites do this? Is it just to add a small measure of security or to make the user feel good?

It is a continuation of the multi-factor approach.  The phone number (that the service already has saved) could easily be looked up.  That is, they could send you the SMS recovery code without ever asking you anything other than your user name.

But, by asking, the service is checking a "something you know" (normally a password, but now your phone number) token before validating the "something you have" token (your phone to receive the SMS).  This means that even the password reset is a 2-factor-authentication operation.

It has the added benefit of preventing automations from using the service as a way to SMS spam folks (causing annoyance to the users, costing the service provider money for all the SMS transmits, and potentially setting up a [D]DoS scenario).  The username and phone number have to match before the SMS message is sent, which is an efficient safety.


Is there now an increased risk of ransomware in pirated software? Ransomware is on the rise, much due to new ransom-paying opportunities via Bitcoin.

Has there been a reported increased risk of ransomware in pirated software (i.e. so called “warez”) – outside of the so called “scene” verified releases –  in public BitTorrent trackers and P2P?

Ransomware adds new dimension of monetization for the malware-maker. As compared to previous infection motives (like adding the infected computer to a botnet, scraping personal data, or just deleting your stuff for fun), does this new opportunity for monetization increase the likelihood of pirated software hurting infected users to a higher degree?

It is my understanding that most ransomware implementations usually builds on a few “ransomwares” such as CryptoLocker, KeRanger and others. Since ransomware implementations then are built on the same foundations, are they identifiable by standard antivirus suites usually used by average users – or are the implementations modified in such a way that they pass detection?

In short, bottom-line: Is it advisable for the average user to avoid pirated software, even if they use antivirus protection, due to these new circumstances? This is of course notwithstanding the legal and ethical implications of using pirated software.

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

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

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

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

In order to avoid propagation, I have:

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

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


Do long password actually help protect your accounts on websites attacks We are told to use password that are long with high complexity to prevent attackers from using brute force attacks on our accounts

The thing is that many websites will pick this up and either enforce timings e.g. 30 seconds between tries or lock you out altogether. In this scenario is a high complexity password worth the effort and the associated risk of a password safe or manager

Please assume the password is not easily guessed. Also this is not referring to scenario's were brute force attacks could happen like an excel file or some middleware that could be copied

There are two parts to your concern about password length, the threat model and the rationale behind longer passwords.  As you state,  a lot of websites have protections against common attacks, and if the password database hasn't been leaked, your password isn't easily guessable, and online protections against brute-force protections are in place, longer passwords don't make much of a difference.  When those assumptions fail, long passwords can make sure your password is too expensive to crack, as demonstrated in research.  The more general case of this question, "Why have strong passwords at all?", is covered in this question.

Threat Model

The threat most password policies are concerned with is an attacker trying to crack the hash of the password which has been stolen or leaked from the system, also known as an offline attack.  This usually has some of the strictest requirements. However, these offline attacks aren't the only threat model.  You password could be compromised in other ways, like:

Brute-force on the website itself, as you mentioned:  Most secure websites have protections against this, which are further discussed below. Long passwords do help you from online brute-force attacks, although the cost/attempt is much higher than an offline password cracker.  These kind of attacks are somewhat common.
You reused a password and the password was compromised elsewhere:  The only prevention here is to not reuse passwords. Password length won't help here and too stringent of password requirements might even discourage users from setting a different password for each site.
A friend, colleague, or social engineer is trying to guess your password based on their knowledge of you: While password length helps here, you don't need very long passwords to stop this attack, and often services are rate limited to only a few attempts per hour per computer.
There are also methods like phishing, exploiting the password reset, and stealing a plaintext database. In all of those threats it doesn't matter how complicated your password is; it's gone anyways.

Focusing just on online attacks and limiting log-in attempts is bad practice because password database leaks do happen.  LinkedIn, MySpace, Adobe, Dropbox, and others have all had password hashes stolen. You can check if you appear on any public leaks here.

Don't Websites Block Online Brute-Force Attempts?

A major part of your question appears to be why password requirements are such a big deal if protections against brute-force attacks are in place.  PCI compliance, for example, requires account lock-out for at least 30 minutes after 6 failed attempts. The biggest problem in preventing these attacks is working against botnets with thousands of computers without causing a denial of service.  How do you prevent thousands of computers each trying to log in a few times without also locking out the user when they mistype their password while using a new computer, or using the same proxy as the botnet?

There are other ways other than lockouts to rate-limit attackers, like asking for CAPTCHA. However, there are some ways to work around CAPTCHA.  This OWASP page discusses more of the best ways to block brute-force attacks.

Why Longer Passwords Help

A few decades ago when Unix was king, it was considered that five-character passwords were pretty good.  Now the stakes are higher, advanced hardware is cheap, and hashes can be broken faster than ever so the requirements for good passwords are higher.  This is part of the reason more companies are pushing for longer passwords.

Longer passwords help because the difficulty of password cracking goes up exponentially with password complexity.  Just adding one random word to your password can make it thousands of times more expensive to guess- the difference between seconds and hours of cracking time.  Adding another random word turns those hours into years.

Many people advocate for using symbols and creating passwords from larger and larger character sets to make passwords more difficult to crack.  However, several examples in research show that requiring longer passwords instead of very complex passwords leads to harder-to-crack passwords (and is more user friendly).  The longer passwords side was also famously supported by xkcd's "correct horse" method to generate passwords.

One caveat is that longer passwords aren't always more secure since extra characters can make a password more predictable.  "orrect horse battery staple" is more secure than "correct horse battery staple", although the latter is much more memorable.  Good password meters like Telepathwords or zxcvbn take this into account and will warn you when the extra characters are predictable.

How Long Should Passwords Be?

The specifics of how long your password has to be, and how hard it is to crack, can't be answered without knowing how your password is generated, how the password is hashed on the server, and the attacker's resources. For more details see this question.

I'll warn you, that password policy is a matter of opinion.  I've tried to show the best solution based on research, but there are some experts who disagree with me.


Can my oppressive government trace my Twitter activity and detect me? I want to be active on Twitter against our oppressive government. Can my government trace and detect me?

Twitter is banned here and we must use VPNs. I use Outline (Shadowsocks) mostly. Is there any way to trace users via information from the ISPs or something? If using Outline is not a good option, is using TOR a good solution?

The importance of this question is that I can be sentenced to death for just a Twitter post! I don't want to be traced. I remove metadata of Images I post and do some basic methods but I want to be sure there is not any problem with my activity on Twitter. What I have to do?

While the communication between your browser and Twitter is encrypted with HTTPS and also additionally in case of Shadowsocks, the messages you publish can be seen by others - that's the point of Twitter. Depending on the content and time of these messages it might be possible to narrow down who might have send these messages. And the more messages you post and the more specific these are the better user profiling can be done.

Since the connections from within Iran to the outside can be monitored by the government they could in theory also align traffic behavior with selected new Twitter posts and from this get your IP address which can be associated with a specific ISP and this ISP knows the customer behind this IP. And again, the more you post the better profiling can be done.

Using Shadowsocks might protect you from some monitoring. But on the other hand using Shadowsocks or VPN can be detected too and can be considered suspicious behavior by its own. And while these technologies hide the endpoint of the connection (i.e. Twitter) they don't hide the sender and they don't hide traffic pattern. It is likely not impossible to use these information for profiling too.

Note that I'm not implying that everything which is possible will be actually done in practice. Even government agencies have only a limited amount of time and money so they will not be able to do everything which is possible in theory. And note that all of this is only about how digital traces you leave on the network can be used to detect too. But it might also be that you talk about your activity to friends and that these friends are not as trustworthy as you assumed. And there are also traces on your computer - see Serge's answer for more on this.


Working of SSH connection through Proxy I have to configure my web browser's proxy to 172.18.10.1:3128 every time I want to connect to internet from my college. Since I'm configuring a web browser's proxy, I believe that the proxy is a "HTTP Proxy" and the proxy server is able to accept the HTTP connection because it has the knowledge of HTTP headers and packers.

Now, can I use this proxy to set up a SSH connection? If yes, how would this connection work? My concept of it is that SSH and HTTP have different header/packet structure because they are two different protocols and for this reason my college's HTTP proxy server would not be able to forward SSH traffic. Please correct me if I'm wrong.

You are correct on the different headers (a.k.a. banners), and that plain SSH will not traverse an HTTP proxy.  But proxies come with inbuilt traversal methods, and an HTTP proxy come with the HTTP CONNECT word.  Since you are not sure whether is is an HTTP proxy or not I'll also add info about SOCKS proxies.

There are pretty much only 2 types of proxies out there: HTTP or SOCKS (other proxies are often just hacks put together).  3128 is a (more-or-less) standard port for the squid proxy, therefore it is highly likely that is the software being used to create the proxy.  And squid can run either HTTP or SOCKS proxies.

Both Firefox and Chrome have setting to use the proxy as an HTTP proxy or a SOCKS proxy.  It is written next to the option where you input the address of the proxy.  If both work, then squid is configured to accept both.

Either way, SSH can be configured using ProxyCommand to use that command to traverse a proxy.  But you still need a command that will be capable of traversing the proxy itself.  There are several options out there, my favourite is ncat (the netcat program provided with NMAP) and I'll use it in the example below but I'll add more options at the end of the answer.

Inside your ~/.ssh/config you can add

ProxyCommand /usr/bin/ncat --proxy-type http --proxy 172.18.10.1:3128 %h %p

Where --proxy-type can also be socks4 or socks5.  SSH will use that command to traverse the proxy and then establish the connection.

Other options

Plain nc can also be used, as follows:

ProxyCommand /usr/bin/ncat -X connect -x 172.18.10.1:3128 %h %p

And for SOCKS the -X arguments should be "4" (SOCKSv4) or "5" (SOCKSv5).  Unfortunately, nc varies from platform to platform and some options may not be available.

If you still have a firewall after the proxy see Gilles's answer on unix.SE for an extra bag of tricks.

Extra note

You can disable HTTP CONNECT in squid.  And if that is disabled all bets are off, since the proxy will not allow any traffic that is not a valid HTTP WORD (that is not disabled, e.g. GET, POST) from traversing it.

Yet, the big problem with disabling HTTP CONNECT is that then HTTPS traffic cannot traverse the proxy, therefore it is unlikely that an HTTP proxy has HTTP CONNECT disabled.

Update: Can't a proxy simply allow "native" HTTPS to pass through?

This is a question in the comment by @Pacerier which I found may be interesting to address.  Full question:

  Can't a firewall allow native HTTPS while blocking HTTP CONNECT HTTPS?

Which I will mangle into (since we are talking about proxies really):

  Can't a proxy allow native HTTPS connections while blocking HTTP CONNECT HTTPS?

Yes and no.  First, a proxy do not block connections that do not go through the proxy, it only decides on connections that go directly to the proxy.  In theory a proxy could allow "native" HTTPS to go through, the problem is that "native" HTTPS is basically any stream of bytes since it is encrypted at TCP level.  In other words, HTTPS is not a protocol that is visible by looking at the packets, that is by design.

The counter argument to that would be that a proxy would be capable of checking whether a stream performs the HTTPS handshake at the beginning and, if both sides "complete" the handshake then allow any stream of bytes to continue going through this connections.  Note that one cannot know whether the connecting parties succeeded in the handshake, that is also by design, therefore a proxy can only know that a handshake was sent or not.

Assuming the above, you can now use your proxy for any protocol since you can simply fake an HTTPS handshake and then send whatever you want.  This defeats the purpose of most proxies, i.e. you turned your OSI layer 7 (HTTP) proxy into an OSI layer 4 (TCP) proxy.  And on a layer 4 proxy it does not matter anymore whether you are using HTTP, HTTPS, FTP or LDAP.

References (not very related but I took some info from there)

How to use ssh over http or https?  on unix.SE


Storing session in querystring I'm applying for a program through organization X's website. I logged in, and was astounded to find a URL like this:

https://www.whatever.org/application?session=80_CHARACTER_HASH

80 characters in [0-9a-f] gives 1680 =~ 2.14 × 1096 combinations.

So I deleted the hash and reloaded the page, lo and behold, I got a 403 Unauthorized response. Changing the hash also causes a 403. Lastly the hash changes on re-login, so I think it's safe to assume that a hash is generated, stored in the database for the user, and then appended to the querystring and checked on page load to find the correct user record in the database.

All pages inside user-specific pages require the session parameter to be correct. I don't know if/when login expires, I haven't sat around idle to find out.

To verify that this is a problem, I opened a new incognito window, copy/pasted the URL, and I had access to my account and application information.

Some problems that I can think of:

Copy/pasting your live session through URL sharing
The URL could be bruteforced (though it would be pretty hard to stumble across a valid hash)
The URL is in various logs (firewall, server, 3rd party aggregating services, etc.)

What are the risks of storing a user's session in querystring parameters?

This used to be a common usage in the old time when clients did trust neither web sites nor web browser for their security and privacy and consistently refused javascript and cookies. As HTTP is a non connected protocol, the session must use some piece of data to pass the session id between the client and the server. That means the if you cannot use cookies for GET requests, you are just left with an URL parameter. That was implemented in many web applications as session through URL rewriting.

It is now seldom used, because browsing most site while disabling cookies is simply impossible. So users have been educated to consistently allow cookies in their browsers.

On a security point of view, passing the session id in the URL is not worse than passing it in a cookie: if someone (except for the user itself) can intercept the URL, he can as well intercept the cookie. And session fixation is not easier with URL than with cookies: it is the problem of the server than should invalidate old session ids, and create a new one after a successful authentication. Logs is not a problem either: a session id make sense only for the duration of the session and is not a long term sensitive information. The only place that could cause problems is cross site requests of redirections. In that case, the REFERER header could contain the session id. So a well designed application using URL rewriting for its sessions, should consistently store the client IP in the session server side, and control that the session ID and client IP match.

TL/DR: That usage is known as session through URL rewriting. It is now seldom used because session through cookies are much more common. The problem is not security because the security of an URL parameter is not different than the one of a cookie, but that extra parameter is displayed in the browser bar, and can intrigate a user, or require removal for storing an clean URL as a bookmark.


Using given RSA private key without the associated public key I'm currently following a small game to get more familar with linux and security and got the following task:

  The password for the next level is stored in /etc/bandit_pass/bandit14 and can only be read by user bandit14. For this level, you don’t get the next password, but you get a private SSH key that can be used to log into the next level. \ Note: localhost is a hostname that refers to the machine you are working on

For now I'm logged in with the user bandit13 in the machine where user bandit14 exists and got the private key. When executing the ssh -i command on the machine (as logged in user bandit13) I get access to the bandit14 profile:

ssh bandit14@server.org -i privatekeyfile

Now what bothers me is, can one log into your user account by just using the given SSH private key from any remote client? I tried to log in using my system but however, the server refused my key. I tried with PuTTY on windows and with the terminal on Mac OS X (with the same command). From what I know is, that the associated public key needs to be put into the authorized_keys file at the server (i.e. the machine that get's accessed). But why does logging in from the remote machine not work but from the local one?

Note: The public key is unknown, I got no access to the authorized_keys file on the server.

Now as I understand this a game, certain liberties might have been take.  I could be wrong is it possible that the game did the following:

Installed the public key in authorized_keys
The private key isn't encrypted, not requiring a password
Restricted access by IP, so only local clients could connect.

Pretty contrived (it is a game after all), and no one would really do this... but it would fit the scenario.


Is there any practical weakness to using MT19937 to generate passphrases? Suppose I use MT19937 to choose random words out of (say) the Diceware word list.  I know MT19937 is not considered a cryptographically secure PRNG, but Wikipedia suggests the weakness is rather uninteresting for this purpose:

  The algorithm in its native form is not cryptographically secure. The reason is that observing a sufficient number of iterations (624 in the case of MT19937, since this is the size of the state vector from which future iterations are produced) allows one to predict all future iterations.

Since it seems rather unlikely that I would need anything like that many iterations to generate a strong passphrase, I don't see how an attacker could exploit this weakness, assuming my password is securely hashed and salted to industry standards (e.g. PBKDF2 with 10k+ rounds and a unique salt per account).  It looks as if this is only considered a weakness because it makes MT19937 unsuitable for use in long-running cryptographic protocols and other situations where an attacker could plausibly observe a lot of iterations.

Since MT19937 has a much longer period than the number of possible passphrases, intuitively it sounds like it ought to be safe for this kind of usage.  But I don't like to rely on intuition.

My naive estimate of the passphrase's entropy is log2(N!/(N - r)!) for N = the number of words in the dictionary and r = the number of words in the passphrase (we're sampling without replacement; if sampling with replacement the numbers go up a bit, but not by much, and I don't want a passphrase with repeated words anyway).  This is simultaneously large enough to be impractical to attack, and substantially smaller than 19937 bits for reasonable values of N and r (e.g. N=2^12 and r=5), so it looks safe.  But I didn't account for MT19937's use because I don't know how to do that.

Are there any known or reasonably likely attacks on passphrases generated, salted, and hashed in this fashion?  In particular, does knowledge of the PRNG used allow us to significantly reduce the entropy?

You don't have to worry about the cryptographic strength. Indeed you will not be getting enough values from it for that attack to matter and even if you did, nobody can observe those values. (Of course if you create millions of passwords and assume that some percentage of them is compromised that might change things.)

What you do have to be careful about is what your initial seed is. If you use for example the time then an attacker only has to guess at what time you created your password.

Knowing the PRNG only helps to reduce the entropy if the PRNG is extremely bad. Way worse than MT19937.


No clients appearing when using wireless attacking tools in Kali Linux I'm new to Ethical Hacking so please bear with me. What I'm trying to do currently is to crack the password of my personal router using aircrack, wifite and fern wifi cracker.

However, I observed in all three that i am not getting any mac addresses connected to my router or clients that are showing whenever i use aircrack, wifite and the fern tools. I do have multiple devices connected and one of which is my phone, but apparently i'm not able to see any clients in my stuff.

To add up, i'm not sure if my wireless chipset is being supported by these tools. Monitor mode is being enabled, but i'm not sure if this is enough. So far i only know that this is my chipset: Broadcom BCM43xx 1.0 (7.21.171.130.1a1)

Btw, I'm also trying to follow this tutorial: http://lewiscomputerhowto.blogspot.com/2014/06/how-to-hack-wpawpa2-wi-fi-with-kali.html

If you clicked the link I am stuck in step 8. In step 8, I don't see any clients connected to my router, but there are devices connected. I tried both being close and not to distant to my router, but still no luck. I also tried to leave my laptop for 4 hours straight, but still no clients showing up. Not sure if i need to wait for more than that.

For reference, i'm using MacBook Pro 2012. I just use Kali Linux Live via bootable flash drive.
For the complete details of my machine, you may refer to this link: https://support.apple.com/kb/SP649?locale=en_US&viewlocale=en_US

I've had issues with Broadcom devices in the past, in my experience the driver supposedly supported monitor mode but I couldn't capture traffic over the air.

I'd recommend getting yourself one of the following:

Alfa WUS036NH - Ralink chipset
TP-Link TP-WN722N - Atheros chipset

Note: Don't bother with the TP-WN722Nv2 it has a Realtek chipset with poor support.


Log user out after change of IP address? Does it make sense to log a user out from a web service after the user's IP address is changed?

I understand that a change of an IP address might indicate a man-in-the-middle attack. Then again IP addresses of end user devices (mobile phones) might change frequently when switching from network provider to local WLAN.

I personally think that adding a logout mechanism like this would not really add to the security of a website.

What aspects do I need to consider to make a solid decision about whether to use such a logout mechanism or not?

If you want to implement a security measure, you need to know what you secure yourself against. In this case, you want to secure yourself against a Man-in-the-Middle attack.

As you said yourself, a change of IP address is not a good indicator for that, for actually two reasons:

There are many reasons why an IP address would change for legitimate reasons, such as the user gaining or losing a Wi-Fi connection, the user connecting to a VPN, etc. As such, this alone is a really bad indicator for an attack.
For the detection to work, it assumes that a user first starts a session on their own, and is then intercepted by the Man-in-the-Middle. If your user is already being intercepted, the IP of the Man-in-the-Middle is the only IP you will ever see.

As such, this security measure is rather prone to false-positives and false-negatives, making it rather unreliable.

But there is a security measure employed by Google that works in a similar way. It detects the usual behavior patterns of a user, such as the usual locations and IP address ranges they connect from. Should a login deviate from this pattern, a security alert is triggered.

This is most prominent when users want to check their emails on vacation or similar, but can truly be an indicator of possible compromise if the user's regular usage patterns are clearly established.

This should be an example as to how information from IP addresses (and other sources) can be used to analyze behavior and thus detect anomalies. Anomaly Detection is a field all on it's own, so don't expect a comprehensive introduction in one paragraph. This example should merely serve illustrative purposes.


Does AV software protect web applications (Twitter, Facebook, etc) from attacks? (CSRF, etc) Is it correct to say that AV software focuses on downloaded executables and locally malicious activity, and it doesn't actively scan HTTP/S content for web based attacks such as CSRF, XSS, phishing URL's and other attacks?

Is there anything that can be installed on a desktop (Mac, PC or Linux) that can protect against this class of threats?

Note: Since asking product recommendations are generally frowned upon on this site, I'm looking for a keyword or technology to search for.

(sample fictitious keywords: Facebook Firewall, AV 2.0 + social media protection, CSRF Shield)

The main problem with attack vectors like XSS and CSRF is that they are largely the responsibility of the web application that is being browsed to rather than the client browser itself.  Both are in the OWASP top 10 coding errors and suggested approaches are to fix the validation of user input on the website itself - so there's not a great deal you can do to protect from the client point of view.

However, having said there is a small subset of XSS that relies on malformed JavaScript will only operate on certain versions of browsers.  Keep the browser up to date solves that problem.


Hacking by metasploit Is it possible to hack an Android device while the victim is using vpn?
I've tried hacking my Android device on WAN and it worked but when I connected my cellphone to a vpn network it seemed that the session was unable to be opened . Now I'm wondering if there is a way by which Android devices can be hacked while they are connected to a vpn network.

If your metasploit console is not public accessible, the cellphone will never be able to connect. That happens if you are running the console on your computer on the local network.

Run metasploit from a VPS with a public and reachable IP, it must work.


How to protect against exploitation using a lapsed domain Consider a domain that had been in active use for some time but is no longer desired — perhaps the company is out of business or a name change took place years ago, or whatever. The domain registration will be allowed to lapse.

I'm guessing there are potential vectors of attack by "dumpster diving" a second-hand expired domain.

One thing I can think of are user accounts registered using email addresses from the expired domain. I imagine that the new owner of the expired domain could submit email addresses to "forgot password" forms on any site and gain the logins of dormant accounts.

Some critical logins such as banking, hosting or DNS accounts even ask for a secondary email address to help users in case they lose access to their primary email address. In fact, it's often these secondary addresses that get forgotten that they were once registered somewhere. This could leave them exploitable should that dormant secondary email end up in someone else's hands one day.

Are there other known exploits to be concerned about with expired domains?

When planning to vacate a domain, what steps can be done to protect the original users of the domain?

This is a nobrainer. Don't let the domain lapse. Domains are cheap, security incidents are expensive.


If my password is not on rockyou.txt does it mean that is a good password? I have been wondering if all my online and wifi passwords are complex enough.

So to test this I was checking if the password was already present on the rockyou.txt wordlist.

If the password is not present in the wordlist then can I conclude that my password is complex enough ?

TL;DR: No. it only means nobody on that list have the same password as you.

Stop right here, install a password manager, then come back.

Done? Good.

That list was from a company (RockYou) that stored all passwords in clear. No matter if someone had a 64 byte password, with a mix of symbols, letters, numbers, capitals, and unicode chars, if he had an account at RockYou, the password leaked. And that wordlist is used on lots of bruteforce tools, so it will be used on emails, routers, Active Directory accounts, and everything on the internet that uses a login and password for authentication.

That's why everyone needs a password manager. No exceptions. It solves the two most prominent issues with passwords: weak passwords, and password reuse.

If your password is weak, it was used by lots of people too. So a leak like RockYou will mean your simple password is leaked, and a service you use will probably be compromised.

If you reuse passwords, no matter how complex the password is, some day the password leaks, and every service you use can be attacked.

A password manager solves both problems: creates long, complex and unique passwords for every service, and requires you to only remember the master password. They are not perfect, they can have security issues, but not using a password manager is the equivalent of saying that bridges can collapse, so you will swim across the river.


Command injection — filtering bypass I am testing a python script that provides a ping function

os.system('ping ' + command)

all of this characters are filtered

'&', ';', '-', '`' , '||', '|'

i can't use null bytes like %0A i'm passing arguments script.py -p

any idea how to bypass the filter to run command like /bin/sh or nc -e  ?

Use $( )

The $( ) construct is equivalent to the backticks, executing the inner command:

$ python -c 'import os; import sys; os.system("ping " + sys.argv[1])' '$(cat /etc/passwd > /dev/stderr)'
root:x:0:0:root:/root:/bin/bash
...


Does public key auth in SSH prevent most MITM attacks? I found this article that claims asymmetric crypto signature of DH-obtained key prevents MITM:

http://www.gremwell.com/ssh-mitm-public-key-authentication

Key idea:

  The value of 'signature' is a signature by the corresponding private
  key over the following data, in the following order:

string    session identifier
byte      SSH_MSG_USERAUTH_REQUEST

  Now the attacker has a problem, as the client and the server have different ideas about what session identifier is supposed to be. Obviously, the server will reject the signature supplied by the client and public-key authentication will fail.

I'd like to verify if my understanding of this is correct:

Let Alice (A) be client, MITM (M) an attacker and Bob (B) a ssh server.

Assumptions:

M sits in the middle of communication, intercepting all communication between A and B
M somehow tricked A into thinking that he's B and also tricked B into thinking he's A (re fingerprints etc).
However, M has not managed to penetrate either A's machine nor B's machine, leaving A's public key at A's account on B machine intact

As long as above conditions hold on top of this one:

  The session identifier is calculated based on (among other things) the shared secret negotiated by the peers using Diffie-Hellman algorithm.

=> while M can fake DH exchanges to A and B, those necessarily will have to be 2 different (fake) shared secrets (unless there's some way for M to compromise that by modifying exchanged DH numbers, not by observing them).

When this shared secret is used as component of creating data to be signed (part or whole of session identifier), one thing that M cannot fake and does not know is A's private key that will be used for signing session ID based on (1st) faked shared secret.

So either digital signature of session ID (+other session data per description above) fails verification at B, or session IDs will not match, effectively breaking communication.

Questions:

is this reasoning correct? if not, where are the mistakes?
is session ID creation the "weakest link" in this chain? That is, if M could predict it (e.g. if it's predictable one-way hash that is susceptible to statistical attack, even if DH itself isn't) and guess it somehow (very improbable, yes, but is it even theoretically impossible?), then M would have "genuine" session ID signed by A and so B would think that auth signature is OK?

I realize this is near impossible in practice, but is it completely theoretically impossible?

1.Yes it is correct. There are 2 possible ways:

  A) Alice blindly accepts the new fingerprint from the attacker mallory.
  Alice and Mallory could connect and authenticate each other. Problem
  here for Mallory is, that he couldn't sign the session id, exchanged
  with Bob. Because Mallory doesn't own Alice's private key. And
  also Mallory couldn't redirect the signed session id from Alice to
  Bob, because the session id would be, with high probability,
  different.

  B) When Alice doesn't blindy accept the new fingerprint, Mallory could
  send the public key and thereof the fingerprint from Bob. Problem here
  would be that Mallory couldn't authenticate to Alice, because Mallory
  didn't own the private key from Bob.

NOTICE: In Case A), when Alice also accept a password authentication, mallory would configure his server to authenticate the client with password authentication and so mallory would get the username and password.

2.Yes, theoretically it would be possible.
See in A), why should Alice not accept the right signed ID from Bob? She would accept :) And also Alice would accept the right signed id from Bob. Mallory needs only to show Alice the Public Key from Bob on connection build up.


Site exposes user's GPS location through EXIF data Recently while lurking around one of the social networking sites popular with local folks, I have found out that the site does not scrub out the GPS data from uploaded pictures. I've contacted them and told them about my concerns, but their reply was that they believe uploading images with (potentially) your home address is only a user error.

I've tried to argue with them, that because

A lot of the users like to post selfies on the site, so there are quite a lot of pictures
The userbase of the site contains a lot of teens and other potentially vulnerable people (to real life abuse if their home/work address would leak)
The site's API makes it very easy to search for selfies and other pictures
And finally once someone comments on your photo you cannot delete it anymore (so even if someone realizes their mistake they cannot fix it anymore, unless contacting customer support to remove the offending pictures). Even quitting the social networking site alltogether will not delete your already uploaded pictures that have comments on them.

this is something to be concerned about, but based on their reply they didn't think so, even after I showed them some of my findings, like the fact that using their API around 13% of the pictures have GPS information in their EXIF data.

To help raise awareness I created a (yet unpublished) blog post and an (also yet unpublished) open source application that uses the site's API to go over the pictures of a user, and tells them whether they are vulnerable or not. If they are, the app also suggest them that they should contact customer support and ask them to completely purge the offending pictures from the system (as that is the only way to get rid of them).

Unfortunately while I'm trying to make the app only return the bare minimum data (it only tells the user whether they are vulnerable or not, but doesn't plot the locations on a map or similar), I'm worried that a malicious person after realizing the hole could modify the app in a way that would allow them to easily plot the locations of people who have uploaded pictures with GPS data.

My questions are:

Is this actually considered a security risk, or are they right that this is just user error?
Is my approach of releasing a blog post and an application with it that can tell you if you are vulnerable or not the right one to do, since I couldn't get the developers to plug this hole?
Should I be concerned that if I make my findings public it can lead to a surge of malicious use, which I'm worried that could lead to real life stalking and abuse of some of the members of the site, or am I just worrying too much?

Is this actually considered a security risk, or are they right that this is just user error?

  Is my approach of releasing a blog post and an application with it that can tell you if you are vulnerable or not the right one to do, since I couldn't get the developers to plug this hole?

  Should I be concerned that if I make my findings public it can lead to a surge of malicious use, which I'm worried that could lead to real life stalking and abuse of some of the members of the site, or am I just worrying too much?

The developers not wanting to fix it does not make the issue go away.  Let's examine two possibilities for your first question:

If users of the site agree with the developers and don't care after it has been explained to them, there was no harm in your blog post, or in anyone else using your code.

If users of the site disagree with the developers and do care, they can now a) petition the devs to change their minds, b) stop using the site, c) implement scrubbing on their end, or d) take other actions to fix the issue.  The issue was already present, so your blog post has lead to a better situation for those users.  The only way this wouldn't be the case is if you're assuming no one else has, or ever will, discover the issue, and history says that's a poor assumption to make.


Authentication for server to server api I want to design an api which an organization is going to use to connect with my server. For a client-server application, a simple jwt-based authentication is done by verifying user credential and generating a token for them.

My question is what should be the process for authenticating another system? How that organization is supposed to receive the credential required to get the authentication token? Like, should i define some static values and tell that organization to use them for authentication? What is the best practice?

You already tagged your question correctly with the oauth tag. There is an OAuth 2.0 flow specific for machine-to-machine communication, called Client Credentials Flow. Details can be found in RFC6749, section 4.4.

The initial authentication takes place using a pre-shared key, called client-secret. OAuth 2.0 doesn't specify a token format, so any sufficiently complex static value (e.g. a random 512 bit string) will do. After successful authentication, the authorization server provides the access token to the system requesting access. This access token, which is used as a bearer token, is used to connect to the target APIs.


What is a Security Guideline and how does it stand in relation with Standards, Policies, Procedures? I'm currently working on the definitions-section of a paper. Therefore I have to define the term "Guideline" and how its relationship to other terms (Standards, Policies, Procedures) looks like.

However, all I can find are some definitions that somehow contradict each other.
e.g

Guidelines usually provide a general overview, and may be used in situations where no specific policy or standard applies.
A guideline is a statement in a procedure or policy that determines a specific route or course of action.
Sometimes security cannot be described as a standard or set as a baseline, but some guidance is necessary. These are areas where recommendations are created as guidelines to the user community as a reference to proper security.
Guidelines are more general statements about things that should be done to realize the policy. They are designed to support standards or serve as a reference for policies
Still, guidelines are an important part of business processes. They help employees know how to act in situations where they’re not sure how a standard or policy applies.

On one hand it is stated that they take action when no policies or standards are in place (1 & 3 & 5). On the other hand they are used to guide policies and standards (2 & 4). So I don't really get the main idea of guidelines.
Could anyone clarify how guidelines are used in practice?

Welcome to the quagmire of documentation terminologies!

In short, there is no single standard way that documents are named and labeled. It is best to pick a set of definitions, either from an established framework (NIST, ISO 27000, etc.) or define the terms in your organisation (and stick to it!)

I have worked in a number of organisations and when the topic of "what do I call this security document?" comes up, everyone sighs and rolls their eyes. In practice, everyone has an opinion, and each organisation does it differently. The (series of) meetings about what to call things can be lengthy indeed for what should be a simple process ("'policy' seems like such a stuffy and unfriendly term!").

What complicates it all the more is when you need to combine different types of documents into a single document so that "we don't have dozens of different 1-page documents that no one will read".

In general, a guideline document is an over-arching set of goals and intentions that can be used when there is no policy/procedure in place, and potentially to guide the content of policies/procedures. It's more of a cultural document than a technical one.

A great example is the "User Password Guideline" document. The policies and procedures for how to handle passwords at the system level are set independently and may have technical controls in place. But the organisation wants to encourage good use of passwords by the users. So, even though the system password Policy states that passwords should be no shorter than 8 characters (or whatever) the Guideline for users is about encouraging them to use very long passwords. It's not something you can force to happen, but there's a guideline in place to handle the risks of poorly formed passwords when the policies, procedures, and technical controls might not be able to address that risk on their own.

In some of my organisations, I combined the Password Guidance and the Password Policy into a single document. One part to explain the whys and the organisation's expectations about how passwords are handled, and then all the technical bits after. If users follow the Guidance, they will be fine. If they need to get fancy with the requirements, then those details are available, too.


SSL3 "POODLE" Vulnerability Canonical question regarding the recently disclosed padding oracle vulnerability in SSL v3. Other identical or significantly similar questions should be closed as a duplicate of this one.

What is the POODLE vulnerability?
I use [product/browser]. Am I affected?
Is [product] vulnerable to the POODLE attack?
What do I need to do to secure my [product] with respect to this vulnerability?
How do I detect POODLE attacks on my network?
Are there any known POODLE attacks?

References:

Google security announcement
POODLE Whitepaper (PDF)

What is the Poodle vulnerability ?

The "Poodle" vulnerability, released on October 14th, 2014, is an attack on the SSL 3.0 protocol. It is a protocol flaw, not an implementation issue; every implementation of SSL 3.0 suffers from it. Please note that we are talking about the old SSL 3.0, not TLS 1.0 or later. The TLS versions are not affected (neither is DTLS).

In a nutshell: when SSL 3.0 uses a block cipher in CBC mode, the encryption process for a record uses padding so that the data length is a multiple of the block size. For instance, suppose that 3DES is used, with 8-byte blocks. A MAC is computed over the record data (and the record sequence number, and some other header data) and appended to the data. Then 1 to 8 bytes are appended, so that the total length is a multiple of 8. Moreover, if n bytes are added at that step, then the last of these bytes must have value n-1. This is made so that decryption works.

Consider the decryption of a record: 3DES-CBC decryption is applied, then the very last byte is inspected: it should contain a value between 0 and 7, and that tells us how many other bytes were added for padding. These bytes are removed, and, crucially, their contents are ignored. This is the important point: there are bytes in the record that can be changed without the recipient minding in the slightest way.

The Poodle attack works in a chosen-plaintext context, like BEAST and CRIME before it. The attacker is interested in data that gets protected with SSL, and he can:

inject data of their own before and after the secret value that he wants to obtain;
inspect, intercept and modify the resulting bytes on the wire.

The main and about only plausible scenario where such conditions are met is a Web context: the attacker runs a fake WiFi access point, and injects some Javascript of their own as part of a Web page (HTTP, not HTTPS) that the victim browses. The evil Javascript makes the browser send requests to a HTTPS site (say, a bank Web site) for which the victim's browser has a cookie. The attacker wants that cookie.

The attack proceeds byte-by-byte. The attacker's Javascript arranges for the request to be such that the last cookie byte occurs at the end of an encryption block (one of the 8-byte blocks of 3DES) and such that the total request length implies a full-block padding. Suppose that the last 8 cookie bytes have values c0, c1, ... c7. Upon encryption, CBC works like this:

So if the previous encrypted block is e0, e1, ... e7, then what enters 3DES is c0 XOR e0, c1 XOR e1, ... c7 XOR e7. The ei values are known to the attacker (that's the encrypted result).

Then, the attacker, from the outside, replaces the last block of the encrypted record with a copy of the block that contains the last cookie byte. To understand what happens, you have to know how CBC decryption works:

The last ciphertext block thus gets decrypted, which yields a value ending with c7 XOR e7. That value is then XORed with the previous encrypted block. If the result ends with a byte of value 7 (that works with probability 1/256), then the padding removal step will remove the last 8 bytes, and end up with the intact cleartext and MAC, and the server will be content. Otherwise, either the last byte will not be in the 0..7 range, and the server will complain, or the last byte will be between 0 and 6, and the server will remove the wrong number of bytes, and the MAC will not match, and the server will complain. In other words, the attacker can observe the server's reaction to know whether the CBC decryption result found a 7, or something else. When a 7 is obtained, the last cookie byte is immediately revealed.

When the last cookie byte is obtained, the process is executed again with the previous byte, and so on.

The core point is that SSL 3.0 is defined as ignoring the padding bytes (except the last). These bytes are not covered by the MAC and don't have any defined value.

TLS 1.0 is not vulnerable because in TLS 1.0, the protocol specifies that all padding bytes must have the same value, and libraries implementing TLS verify that these bytes have the expected values. Thus, our attacker cannot get lucky with probability 1/256 (2-8), but with probability 1/18446744073709551616 (2-64), which is substantially worse.

I use [product]. Am I affected? Is [product] vulnerable to the Poodle attack ?

The attack scenario requires the attacker to be able to inject data of their own, and to intercept the encrypted bytes. The only plausible context where such a thing happens is a Web browser, as explained above. In that case, Poodle is, like BEAST and CRIME, an attack on the client, not on the server.

If [product] is a Web browser, then you may be affected. But that also depends on the server. The protocol version used is a negotiation between client and server; SSL 3.0 will happen only if the server agrees. Thus, you might consider that your server is "vulnerable" if it allows SSL 3.0 to be used (this is technically incorrect, since the attack is client-side in a Web context, but I expect SSL-security-meters to work that way).

Conditions for the vulnerability to occur: SSL 3.0 supported, and selection of a CBC-based cipher suite (RC4 encryption has no padding, thus is not vulnerable to that specific attack -- but RC4 has other issues, of course).

Workarounds:

Disable SSL 3.0 support in the client.
Disable SSL 3.0 support in the server.
Disable support for CBC-based cipher suites when using SSL 3.0 (in either client or server).
Implement that new SSL/TLS extension to detect when some active attacker is breaking connections to force your client and server to use SSL 3.0, even though both know TLS 1.0 or better. Both client and server must implement it.

Any of these four solutions avoids the vulnerability.

What do I need to do to secure my [product] with respect to this vulnerability?

Same as always. Your vendor publishes security fixes; install them. Install the patches. All the patches. Do that. For Poodle and for all other vulnerabilities. You cannot afford not to install them, and that is not new. You should already be doing that. If you do not install the patches then Níðhöggr will devour your spleen.

How do I detect Poodle attacks on my network?

You don't ! Since the most probable attack setup involves the attacker luring the victim on their network, not yours.

Although, on the server side, you may want to react on an inordinate amount of requests that fail on a decryption error. Not all server software will log events for such cases, but this should be within the possibilities of any decent IDS system.

Are there any known Poodle attacks?

Not to my knowledge. In fact, when you control all the external I/O of the victim, it is still considerably easier to simply lure the poor sod on a fake copy of their bank site. Cryptographic attacks are neat, but they involve more effort than exploiting the bottomless well of user's gullibility.


Credit Card Creation for Member ID I have a bit of a unique application. I'm trying to create fancy ID cards for local membership.

It's a cocktail club, and they're doing some cool things with the front of house and service structuring. All that to say, they want to use some nice brass magstripe cards for members IDs, but they'd like to further integrate them into their POS, which is currently Square for Restaurants.

I've talked to them about RFID, and about magstripes, but I'm further not entirely familiar myself with what the POS system looks at from a credit card stripe, which stripe the data lives on, how it's encoded past the reader, etc.

I've got a reader/encoder that I can use to read data, but I'm not seeing consistency between the selection of cards I have in front of me. I have some work to do on the interpreting side, I suppose.
Does anyone have experience encoding data on a magstripe specifically for use by a POS system?
I'm only trying to create a card that mimics the functionality of a credit card for ID purposes, so not for payment, and I'm not trying to take part of the credit card magstripe data from another real credit card to then repurpose on a created ID card for ID. These cards are totally separate from real credit cards, but use the magstripe out of convenience.

Since you asked in a security forum, mag stripe cards are considered wildly insecure. They’re easily clone-able, which data is easily read and written to. The data on the card is static and pretty much free for all.

However, you might consider a cocktail club a relatively Low-value target, and can generally accept this risk given chip cards are way more expensive to both print and process.

For more details, typically card data is encoded onto the ‘tracks’ of a mag stripe card, with some details here. I’d bet you can buy off the shelf electronics to both process and handle magstripe cards anywhere.


Valuable languages for working malwares I would like a recommendation for programming languages which will be valuable when dealing with malware. I learn to code on C not on expert level(thanks god I didn't). But C doesn't seems so popular anymore the only new malware(from 2000 year till now) I can name is stuxnet. So what will be the most valuable language when dealing with malware(analyzing, writing etc..). I think this will be C++ because there are so many malwares written in C++ for example Zeus, Spyeye the list is endless probably all botnets and other Trojans are written in C++ those days. Also I want to mention that Assembly isn't counting Assembly is a must for me.

To be working with malware, especially reverse engineering, then you must be good at programming, especially low-level programming. There is only one way to be really good at programming: learn many languages. This helps a lot finding out what really is at the core of the concept of programming, and what is purely a matter of syntax.

You know that you master a language if you are able to, at least conceptually, write an interpreter or compiler for that language. If you want to analyze malware which has been written in C, then you must know how a piece of C code gets translated to assembly.

So don't ask on what language you should concentrate; you should be learning all of them. Or at least a decent selection. I suggest assembly (for at least two platforms, e.g. x86 and ARM), C, C++, Java or C#, with a bit of Forth, and some Lisp dialect (Scheme would be best here). For a start.


What CSS is considered Safe or Unsafe within a multi tenant website? I'm reading the Azure Patterns and Practices multi-tenant guidance and in there it says

  Cascading style sheets Behaviors are
  one feature that the Surveys site will
  not support.

What CSS features should I support in a multi tenant website?

There are two issues.

CSS can contain Javascript.  Older browsers will execute the Javascript.  The Javascript receives all of the privileges accorded to the web site, so this would allow each tenant to gain privileges he/she should not receive (e.g., privileges to mess with other tenants, or to mess with your surrounding site).  For instance, the Samy worm and a recent Facebook vulnerability both involved malicious CSS.
Newer browsers will not execute the Javascript, but there are still many older browsers out there.  Ways of including Javascript or other active content in CSS include expressions like url(javascript:alert()), url("http://evil.com/evil.js"), expression(alert()), -moz-binding:, behavior:, and possibly others.

CSS from one tenant can try to set styles on the HTML for other tenants, or for your surrounding site.  This might cause negative impacts.

In principle, you could write a CSS sanitizer to defend against these attacks and still allow tenants to specify their own CSS.  However, that is quite tricky to do right and it would be easy to introduce a mistake, so it's not something to undertake lightly.


Someone knows about online labs? I'm looking for an online training lab for pentesting/hacking and security.

I've found one at hacking-lab but it's seems troublesome to work with and it has some issues on VPN server authentication.

Someone knows about something similar?

Or something like Hackademic RTB1 and RTB2?

I wish for more resources to learn with.

thx in advance.

There are a few different kind of labs available. There are ones you can construct yourself in VM's such as Vulnhub and they have a lot of links to good resources there. Another site i can recommend with good resources is Pentesterlab, i tend to steer clear of the online sites such as hackme so can't give much as to online but hope these help.


Does bcrypt on top of md5 reduce its security? A GitHub project I recently checked has a flawed security as they're using an unsalted md5() to hash the passwords. I opened a bug and they acknowledged it. However, the transition from md5() to bcrypt would mean that every user would need to log in so the password can be migrated.

So my question is, does using bcrypt over md5() reduce it's security?

// For already logged in users:
if (password_verify(md5($_POST['pass']), $DBHash)) {

  }

In that way, the whole database could be migrated easily, instead of migrating each user individually.

Should there be any other problem besides the fact that PHP might timeout if not handled correctly? (around 1 second for each hash).

Absolutely not. In fact, this is almost the standard procedure for migration from a weak hashing scheme to bcrypt in every project I worked with.

What usually happens is that a flag is set for each user indicating that their passwords use the old scheme, and whenever they login the application uses the backward-compatible login logic. Once the user logs in, you have their plaintext password, and now you can simply take the new password and store it using bcrypt only, the unset the flag. All new users use the new bcrypt-only scheme.

Alternatively, you can go by CodesInChaos's suggestion and stick to the new bcrypt(md5()). While he's indeed correct that there's no security gain, I personally like to keep it bcrypt() only.


Are there joint password accounts? (Like bank accounts) Online joint accounts that are similar to bank accounts that are joint accounts?

Say you want to have two partners for a certain account, let's say a PayPal account, and you want to make it so that if one partner wants to change a password he must get confirmation from the second person.

Are there currently any online accounts that have a such a feature?

It's generally undesirable to have multiple people knowing the same password.

Instead, systems that requires multiple user to be able to access the same resources usually requires each user to create their own accounts, each with their own password that's only known to themselves, and the system would simply allow all the users to access the same resources. This means that a Joint Paypal account would have worked by allowing multiple user accounts to transact from the same wallet.

This means that it's unnecessary to get the approval of the other account holders to change password.


Generate cryptographically secure token in mySQL I need to have MySQL generate cryptographically secure tokens for me. To my knowledge, there is no built-in function for the purpose. Would something like the following suffice, or is this a foolish solution?

SELECT TO_BASE64(AES_ENCRYPT(UUID(), UUID()))

This is a bad idea. GUIDs are designed to be unique, not random.

The GUID generation algorithm was designed for uniqueness. It was not designed for randomness or for unpredictability

Also from https://stackoverflow.com/a/2621604/569090:

  Do not assume that UUIDs are hard to guess; they should not be used
     as security capabilities (identifiers whose mere possession grants
     access), for example.  A predictable random number source will
     exacerbate the situation.


Is Windows Sandbox a viable alternative to conventional VM solutions considering its design? The idea of having a fast, disposable VM at the palm of my hand appeals to me very much. It makes adding an extra layer of security to any thing I want to do so easy - just launch the sandbox application in a matter of seconds and you're done. Of course, that is considering the VM actually does the job it's supposed to do...

A little disclaimer beforehand - I've read the article Beware the perils of Windows Sandbox at Magnitude8, describing how the Windows Sandbox comes with a NAT pre-enabled and thus any malware running on the guest would still get a direct access to your intranet, which is already a large problem. But for the purpose of this question, let us just consider the host-guest scenarios.

Windows Sandbox claims to "achieve a combination of security, density, and performance that isn't available in traditional VMs", by leveraging a different approach to memory and disk management. If I understand things correctly, everything that in theory can be safely shared between the host and the guest, gets shared. According to the official documentation, the Sandbox shares both the host's immutable system files, as well as the physical memory pages.

Despite that, Microsoft seems to remain confident that their solution is secure as implied by one of bullet points mentioned in the Sandbox overview:

  Secure: Uses hardware-based virtualization for kernel isolation. It relies on the Microsoft hypervisor to run a separate kernel that isolates Windows Sandbox from the host.

This obviously raises a lot of questions, because at the first glance, all this resource sharing should increase the attack surface greatly, leaving more space for exploits to be found. Also, even the most sophisticated technology, which changes only the implementation and not the design, does ultimately make the discovery of an exploit only more time and resource consuming, but not less possible, doesn't it?

So, my question is

Would you consider Windows Sandbox to be a viable alternative to conventional VM solutions in terms of security, or do the shortcuts used to achieve the performance undermine the VM's core principles too much? Or am I just not understanding the technology and all of what the Sandbox is doing is technically safe?

An extra question: Does the situation change when we're talking about a web-based attack, such as opening a malicious site in a browser from within the Sandbox, or does it come down to the same situation as running an infected executable? (disregarding the extra layer of sandboxing done in the browser itself)

Would you consider Windows Sandbox to be a viable alternative to conventional VM solutions in terms of security

Because sandbox serves different purpose than virtual machines, sandbox can not replace virtual machines. One simple difference can be all the changes done are lost in window's sandbox once the machine is done with. Virtual machine generally encompasses the features of sandbox and more.

  or do the shortcuts used to achieve the performance undermine the VM's core principles too much?

The Window's sandbox also uses hypervisor tech so essentially it seems not very different in implementation than other hypervisors out there, only key difference is the operation on virtual machine(window's sandbox here) are lost after it is shutdown.

  Does the situation change when we're talking about a web-based attack, such as opening a malicious site in a browser from within the Sandbox, or does it come down to the same situation as running an infected executable? (disregarding the extra layer of sandboxing done in the browser itself)

It may help with certain situations but not all attacks are same, Question is very wide to answer.

One typical situation assumed is when you have a session running and site is vulnerable to XSS, in such scenario sandbox has no role to play.


Is there a convenient way for a CS representative to verify the caller's id without compromising security (too much)? As of now, we're accomplishing this by hashing, salting and storing the first three characters of the customers' passwords in one table and hashing, salting, and storing the full password in another table.

BCrypt is used for hashing and SQL Server for storing.

When a customer calls our customer service, the representative has the option to verify the caller's id by asking for (among other things) the first three characters of her password.

The system used for this is behind all kinds of security measures and in no way exposed via external GUI nor API.

With the desired outcome in mind, verify the caller's id fast and easy, is there a more secure way to gain the same benefits?

(For other searchers who are concerned about separate storage of the first three characters, the asker's other question about that technique here has some solid and detailed replies, explaining why extracting a subset of secret information like a login password may be suboptimal).

More generally, there are a couple of canonical ways to verify identity. Most involve asking the customer for information that both the customer and the company would usually only know:

Recent activity. For example, if it was a financial institution, you could ask them to describe the amount, merchant, and date of a recent transaction.
Credit history data. If your business has access to credit history information (loan types and amounts, previous addresses, etc.), you could leverage this information.
Account support password. Separate from the password used by the customer to access the services directly, you could simply have the customer supply (at signup) a password that will A) be stored on your servers in plain text, and B) only be used by customer service to verify the customer's identity.

You can also throw in, in addition to the above and selected at random, some other information that is naturally collected at signup and stored (address, birthdate, last four of SSN, etc.). For obvious reasons, these would only be used to supplement the questions above, and would need to be adjusted based on your business model.


password strength audits and mitigations Reading this article about detecting bad passwords in the enterprise, made me  want to ask if anyone here has attempted any audit like this.  It would be an effective attack:  There may be a good password complexity policy and a good account lockout policy in place, but if someone just wants to try 100 worst passwords that still match the policy and change the username with each login attempt instead of the password, then it seems given that eventually they'll find a user with a bad password.  So my questions are:

has anyone attempted this on their Active Directory hashes?  How did you sell it to management?
Has anyone used some mitigation strategies such as maintaining a list of 100 to 500 hashes of easy passwords that still meet the password policy and block users from using these?  How effective would this be?

Yes, regularly. For many of my clients we create policies that require at least annual audits of passwords across all devices, including Windows AD, that tests accounts against the top 500 most popular passwords (and also a list of password derived from their names etc. using various encodings). Accounts in non compliance are marked as having to change at the next login and the users are reminded of the password strength policy.

Management in all case have understood the risks of not checking for this kind of weak password and has been supportive. Given that the number of violations almost always decreases year on year the 'sell' to management seems to get easier.


Does the terms stream and block ciphers apply to both symmetric and asymmetric ciphers? Does stream and block ciphers only apply to symmetric key algorithms or does it apply to both symmetric and asymmetric?

Stream and block ciphers are usually used with symmetric keys. This is for performance reasons as public-key cryptography is much more expensive.

That said, public key encryption also encrypts blocks of data (block sizes in RSA are based on the key size), so it technically uses block ciphers, we just don't usually focus on that.

In short, it's more about the cost of encryption/decryption than anything else. It would be prohibitively expensive to do public-key encryption for large amounts of data.

Symmetric keys give you cheap computation but the problem of a shared secret. Public keys give you expensive computation but easily shared information needed to communicate securely.

This is why the common approach is a hybrid one:

Key encryption key: use public key cryptography to encrypt a symmetric key generated on the fly
Data encryption key: use the symmetric key to encrypt/decrypt the actual data


Why can't I delete the default AWS security group? There are no inbound nor outbound rules. It's an empty group. What use does it serve?

The default security group is created when a VPC is created.
By default, it allows ALL traffic from instances that belong to that security group and all incoming traffic. The fact that your default group doesn't have any rule suggests that you deleted the rule.
AWS doesn't allow deleting default security group because many API call/CLI command allow omitting the security group, so AWS needs a default security group to place instances with an unassigned security group.
See Default security group for your VPC in the VPC documentation.


Data at Rest vs Data in Storage I have a question about regulatory compliance. If I am required to have data at rest secured (encrypted), what are they looking for? Should my database files be encrypted, or is data at rest referring to my actual disk drives being fully encrypted? Or maybe both?

You might want to ask your company lawyer to help define what that means in your specific circumstances.

As for the usual definition of the term "data at rest": It means "stored data which isn't currently being accessed". So, for example, data at rest would be data sitting on a server's hard drives while the server is turned off, or data on backup tapes, or data sitting in a file that isn't opened by any of the running processes on a system, and so on.

So I'd say that what you need to do is encrypt all the data that falls under the requirement to be secured when it is at rest. Depending on what your data is, it might be enough to just encrypt the contents of a database before you store them in the database, or you might need to encrypt the file system the database sits on.

Edit: If you just encrypted the file system, but not the application data itself, you'd also need to make sure that backups of your application data, which also constitute data at rest, are encrypted, and so on.

For example, if you only encrypt text fields in a relational database, that might not be enough, because the relations between records would still be accessible. If you only encrypted your filesystem and then took a backup of the data while the filesystem was mounted and the plaintext data accessible, you'd then also need to encrypt the backup.

Like I said, do have legal counsel define it; your circumstances might vary, and security.stackexchange.com isn't law.stackexchange.com.


Asymmetric Key Encryption in Group Chat I am working on a chat application which supports both single user chat as well as group chat.

We planned to encrypt messages in single user chat by public key of receiver and decrypt it using private key of receiver.

If we go by this approach then we are clueless about implementing it in case of group chat.

Any thoughts?

This depends on model you use for group chat:

Peer-to-peer: You need to encrypt each message with the recipient's puiblic key and send it to each user separately, and create the "illusion" of a group chat.  This will prevent new group joiners to see previous messages.
Client-Server: You upload the messages "signed" to the server, and encrypt them to each user.

Alternatively, you create a key pair for this "group" and send a copy of the private to all members of the group, but I'm sure you see the problem with that already.


Record IP pseudonymously? I'd like to be able to ban an IP from my website, but for privacy reasons I would like to not have a record of the IP itself. Hashing the IP would allow for the hash to be brute forced in mere minutes, and salting it would be useless because anyone with access to the bans database would have access to the salt. Is there any way that I could keep some kind of "fingerprint" of an IP, probably involving hashing, that would be feasible to generate on a server but infeasible for an adversary with moderate resources to brute force?

IP addresses aren't usually considered private information, so why you'd want to protect the data I'm not sure. If someone is trying to misuse your system the IP address is a valuable piece of data which you will want to be able to access. Checking IP addresses against a blacklist is an example of where the data is useful. Knowing where the IP address is located geographically could clue you in on who may be attacking you.

In any case you don't have a problem as your goal is to protect the data from yourself, not from others. As you say, if someone can access the database they probably have access to everything. You could store the salt on a different system and access it with some sort of API, but that could be intercepted. The data has little value to an attacker anyway, so why would they bother?


Swap file may contain sensitive data Is it possible that the swap file will contain chunks of data by a file you have accessed, and could this be detected during a forensics analysis?

How could you prevent this situation ?

Is using deep freeze or similar software a valid solution ?

Yes, swap files can contain sensitive data.

On Windows you can configure the page file (swap file) to be cleared at shutdown this way:

Start regedit32.exe
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Set the data value of ClearPageFileAtShutdown to 1
If the value does not exist, create it with the type REG_DWORD and set it to 1
Restart

I don't know for sure if this is a secure deletion of the swap data, but from the fact that it adds minutes to the shutdown process and from the text on Microsoft page about ClearPageFileAtShutdown:

  Some third-party programs can temporarily store unencrypted
  (plain-text) passwords or other sensitive information in memory.
  Although clearing the paging file is not a suitable substitute for
  physical security of a computer, you might want to do this to increase
  the security of data on a computer while Windows is not running. "

I would think the data is securely wiped.

On Linux you can manually wipe the swap partition:

Display swap details: swapon -s
Unmount the swap partition: swapoff -a
Overwrite it with zeros: dd if=/dev/zero of=/dev/sdaX bs=1024
Get the UUID of your old swap partition from /etc/fstab
Create a new swap partition with that UUID: mkswap /dev/sdaX -U <old_uuid> 1024
Mount it for usage: swapon -a

Better wiping tools are provided by the Secure-Delete package which comes with the following commands:

srm (Secure remove) – used for deleting files or directories currently on your hard disk.
smem (Secure memory wiper) – used to wipe traces of data from your computer’s memory (RAM).
sfill (Secure free space wiper) – used to wipe all traces of data from the free space on your disk.
sswap (Secure swap wiper) – used to wipe all traces of data from your swap partition.

Sswap is designed to delete data which may lie still on your swapspace in a secure manner which can not be recovered by thiefs, law enforcement or other threats.The wipe algorithm is based on the paper “Secure Deletion of Data from Magnetic and Solid-State Memory” presented at the 6th Usenix Security Symposium by Peter Gutmann, one of the leading civilian cryptographers.


Should I use sudo with the normal user or root or sudo with another user? on a UNIX OS, ex.: OpenBSD (used as a desktop by me only), which one is the best choice in regards to security. I want to run desktop operations (like pkg_add) with root permissions.

 1. having the root user and using it with su - root
 2. having the normal user in the wheel group
 3. having another user in wheel group, so the normal user isn't in the wheel gr. So if running commands as root you need to first "su - anotheruser" with the normal user then you can "sudo pkg_add"

Or are there any other possibilities?

UPDATE: so not "1." OK. But which one then? "2." or "3."?

Normal user and sudo, always: you want to spend as little time being root as possible.

As a bonus, the act of sudoing before giving a command reminds you to be careful.


How exposed am I using older Firefox version (56)? Due to one add-on not being compatible with newer Firefox versions (57 and up), I'm stuck with Firefox 56 (running on Debian) for a while.

I'm OK with things like performance or looks not being the best you can get. However, I am worried about security issues and wonder how dangerous it is.

Should I choose Firefox 52 ESR instead of the Firefox 56?

The versions and security fixes are listed here: https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/

While it is not recommended to run older versions with known issues, one way you might be able to get along is to run the old Firefox in a container or virtual machine in order to get some protection for your personal data on your host.


Difference between public key and private key validity period In the section about certificate extensions, the ITU-T X.509 recommendation writes:

  The private key corresponding to a certified public key is typically
  used over a different period from the validity of the public key. With
  digital signature keys, the usage period for the signing private key
  is typically shorter than that for the verifying public key. The
  validity period of the certificate indicates a period for which the
  public key may be used, which is not necessarily the same as the usage
  period of the private key. In the event of a private key compromise,
  the period of exposure can be limited if the relying party knows the
  legitimate use period for the private key. There is therefore a
  requirement to be able to indicate the usage period of the private key
  in a public-key certificate.

I don't understand why there is a difference in public vs private key validity period.
Why would the private key be used over a different period? When the private key is compromised, there is no point in using the public key anymore. Except to authenticate a message that we know has been issued before the private key's compromission. But then why would the public key lose validity after some time?

But then why would the public key lose validity after some time?

One reason is that the way certificates are signed might become outdated.

For example because either the hashing algorithm or the signature algorithm/key length is too old.

Take the hashing algorithm for example. At the moment SHA-1 signed certificates are on the way out. Because that hash no longer seems secure.

And before SHA-1 was used there was MD5 in certificates. And that has been phased out as well. (And people had to ask their CA to please resign their public keys with some other, stronger parameters. MD5 -> SHA1, SHA1->SHA2, etc.)


I unknowingly visited a hacked site, what are my next steps? I stumbled onto a hacked site a short while ago. Firefox blocked Flash from running, but are there any other vectors I should be concerned about? I'm pretty sure I had an account on the forum in question; does that change anything?

As of posting this, the site in question is still hacked. Some searching turned up that people were trying to contact the site owners about it at least 5 days ago.

I also have a screenshot of the page and a url, but if it really is potentially dangerous to visit, it's probably best not to send people there.

There are a variety of other vectors that can be used, Java and Javascript based ones being the other most common ones, but also images and other vectors.

If you're worried, shut off the computer you're worried about, right now.  Malware can't do anything when it's powered off, whether it's a virus, ransomeware, or anything else.

If you're truly worried, shut off everything on the same network.

Regardless of your worry level, if you share passwords with the hacked site and any other site, change them all immediately from a computer not connected to the one you're worried about.

And after that particular site is up and claiming to be unhacked, change your password there to something long and cryptographically random - don't give that site any hints as to your other passwords.

If you're worried, then run several different offline, bootable/live/livecd/rescue antivirus/antimalware products

Use several because no one product covers everything, but by using several different products, you reduce the uncovered space significantly.  I'd recommend:

at least one of AVG and Avira (or both)
at least one of Dr. Web and Kapersky (preferably both), to get some Russian involvement.
Comodo Rescue Disk (it advertises rootkit scanning, too)
Pick another couple of your favorites.

PCSupport.about.com has a pretty good top 15 list as of Feb 2016
If you're truly worried, do this on every machine on the network.

It won't really take much more time - you can put AVG in one, Avira in another, Kapersky in a third, Dr.Web in a fourth, and then simply move them to the machine on the right when they're done in round-robin fashion.

They're almost certainly going to find tracking cookies - that's normal, and nothing to be concerned about, though I'd always delete them.

After all of this, once you're fully online again

Make sure your OS is patched, and stays patched.
Make sure your antivirus is patched and up to date, and stays that way
Make sure your firewall is patched and up to date.

Consider something a serious like pfSense, which is legally free software, and can run on an old computer with a couple of network cards, a small, low power fitlet PC, a pfSense store device, or other machines as your firewall.

And then look at the Snort or Suricata plugins for IDS/IPS funcitonality, which have a great chance of blocking threats as they're coming in.

Note that these packages require quite a bit of tuning to balance protection and convenient usability, they are NOT plug and play.  They are, however, very powerful.

Make sure your browsers are patched, and stay patched
For Firefox in particular, try the following addons:

Noscript
Policeman

This plug allows you to choose specific content types (images, scripts, etc.) to be allow only from site A to site B, specifically, though it does allow more and less specificity for each site.


Do TLS standards require applications to be picky on case sensitivity of hostnames? I've come across a couple issues now with various vendor products where connections to https://example.foo is handled differently from connections to https://ExAmPlE.FoO with the latter sometimes resulting in errors.

Is there a clear stance in the TLS standard for if applications should care?

AFAIK, it shouldn't matter and both should be treated the same.  After all, isn't this essentially what web users do all the time?  It's not like a user typing https://www.GoOgLe.cOM won't actually get to google...

Short answer: the hostname part/CN is case insensitive. The issue is not with TLS standards, but with the way other things are implemented, e.g. web server configuration, vendor-specific implementations, etc.

Long answer:

RFC 4343 clarifies that hostnames are case insensitive (RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification), see Section 6 Security Considerations. The section states cases where capitalization may have security impact, so the CANONICAL form of domain names must be used (as is the case with common names (CN) in digital certificates). In general the domain part of your URL should not be case sensitive. The rest is case sensitive, e.g. the full URI is definitely cases sensitive.

Also, see RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, section 2.7.3, which explains that the protocol specifier (http or https) and the hostname are case insensitive. This is confirmed by RFC5890, Section 2.3.2.4, where the actual algorithm to comparing hostnames is defined.

International domain names generally follow this (although via UNICODE transformations, as defined in RFC3454 and RFC3491).

The only possible explanation for the behavior exhibited is that it is possible that web server configuration may be case sensitive (e.g. the Virtual Host definition), or it is possible that something wasn't implemented exactly as defined in the standard by a vendor (won't be the first time, and won't be the last).

In a nutshell, the issue has nothing to do with the TLS and Internet standards, but with other factors.

I hope this helps!