Security of Yahoo's new authentication: On-demand password Yahoo is trying to remove passwords from authentication and use on-demand password authentication system instead.

I wonder how this new system will be secure? Even if somebody steal your mobile can easily access to your email with your SIM, or governments can easily use their power to login in your email by forcing service providers.

Is this on-demand password secure at all?

It is more secure than a password in some ways, but as you describe, it also makes accounts more vulnerable to other attack vectors.

As a best practice, properly implemented two-factor authentication offers much superior security to a single factor, regardless if that single factor is a memorized password or an "on demand" password.

Reduced Vulnerability to internet-based attacks

I can see the logic in why Yahoo has implemented this alternative authentication system however, as one of the primary ways that spammers, automated email-hack bots and human hackers gain access to Yahoo accounts is through password re-use.  Yahoo e-mail is a large service that has been around for a long time; and many of its continuing users are not technically savvy.  Thus, they often reuse passwords on different sites; even going so far as to register with their yahoo e-mail.  Then their account is compromised, and we see spam, scam solicitations (the "I've been abducted please wire money" emails, etc) and the like.

Also, typical malware attacks such as keyloggers and password-interception would be unable to gain access to the account, simply because the password would only be usable once; and once expired a remote system could not gain access.  This reduces vulnerability to a very common method for malicious parties to access others' email.

So, if those users switched to this phone-based password system, these attack vectors would be largely eliminated.

Increased Vulnerability to Physical Attacks

As you point out, however, this opens up an entire new attack vector in that if the user's phone is compromised, one could easily gain access to their account.  This changes the attack vector from remote (internet-based hacks from other countries) to a physical hack.  Thus, anyone with physical access to your unlocked device can gain access to your e-mail from another computer.  Users however typically have their e-mail sync with their phone, so if this was the case anyone with access to the device could simply read the e-mail from the phone as well.

SMS Security

There is also the question of SMS security.  If a code provided by SMS is all that is needed to login, it is vulnerable to various eavesdropping attacks -- notably from "Stingray" devices provided to law enforcement agencies across the US.   Also as you point out there is the less sophisticated physical attack of stealing the SIM card (and potentially cloning it) and inserting it into another device and triggering the message. This opens up a whole new attack vector, but again it is localized as the attacker must be physically near (or have equipment near) the target.  Two-factor authentication lacks this vulnerability because the other factor (e.g. a password) would not be vulnerable to the same attack.

Governments have more effective ways

On the subject of governments, generally they can go through legal means to obtain data from providers so they are less likely to attack a web-based email account via a hack; and either get the information from the provider or force the target to hand over the password or data.

Use Two-Factor Authentication as a Best Practice

However, if a user wants to truly take the best measures they reasonably can to keep their e-mail secure, using two-factor authentication is the best option and one should not rely on a single factor, no matter what it is.


Firewall and PCI DSS Requirement I would like to ask about the first requirement of PCI DSS which is build and maintain a secure network.

Is it required to have a physical firewall or it can be a software  example using operating system firewall iptable rules?

A physical firewall is just a network-connected computer running software, so of course a firewall implemented in software is acceptable. There's no other kind. What it can't do for PCI compliance is to run the firewall software on the same machine as any of the services that it's protecting.


Create RSA public, private key pair having numbers generated already I want to know how to generate working RSA key pairs, with the correct syntax.
Let's say I have already generated somehow my numbers for a 512bit key, which are:

e = 00065537

d = 2a3ff2f501835d7d0f7ccad34265525b0c91f800fc252324e4bb5668392ba55a65d812d658b7065725c259a12115918dbdbbea6cead9225a91c3fcc6b43f1cb3

m = 4bb26cf2e1e1cdbbf78f89a60d5af5cf094a7216f9fe2d0e2288dc14e6005e0b6de46dc38f0e92b8b3281e9f1cf87257fb54bff579907e8a3c114133b74cb815

How I can generate a proper key pair from this? Is there a generator somewhere to automate that?
Best solution for me would be to generate that keypair in javascript that would work here https://www.pidder.com/pidcrypt/?page=demo_rsa-encryption with pidcrypt.

A RSA key pair consist in the following:

The modulus n, a big integer which is equal to the product of two big prime integers, p and q.
The public exponent e.
The private exponent d. d is such that ed = 1 when taken modulo p-1, and also when taken modulo q-1.
The first factor p.
The second factor q.
The value dp = d mod p-1.
The value dq = d mod q-1.
The value q' = q-1 mod p.

The public key contains only n and e.

The private key contains all of the values specified above. Stricto sensu, only n and d are needed for a perfunctory RSA implementation, but the other values allow for faster operation, and also "masking" (protection against side-channel leaks), so the RSA standard defines that a private key contains all the values (see appendix A.1).

From the value you have, assuming that your "m" is really the RSA modulus, the other values can be recomputed, at some effort (less than one second worth of CPU, but more human time than I care to invest in it). From all these values, you could then encode standard-compliant RSA public and private keys; but this requires some knowledge of ASN.1. Finally, a 512-bit RSA key is weak; use at least 1024 bits, preferably more (2048 bits ought to be fine). Some RSA implementations will refuse to work with RSA keys shorter than 1024 bits.

Bottom-line: don't generate the key yourself; use OpenSSL. With the command-line tool:

openssl genrsa -out rsakey.pem 2048

will generate a 2048-bit RSA private key with all the proper encoding; then this:

openssl rsa -in rsakey.pem -pubout

will print out the public key, there again with the encoding done.


How are hashing algorithms useful if the implementation is public? I may be misunderstanding, but if I want to use a hashing algorithm such as argon2, what's stopping from someone seeing how it works and reversing what it does?

Being public is exact the point: you show everyone how it's done and how difficult it is to reverse it. It's like showing you a ginormous jigsaw puzzle with a trillion pieces, but with every piece in its place, and shuffling everything down. You know all the pieces form the puzzle (you just saw it), and you know it's very, very difficult to put everything back. A public hash shows you how it's done (the result) and how difficult is to do everything in reverse.

A public hash function is just a set of mathematical operations. Anyone can (but only a few will) do the operations by hand and prove that the algorithm works as expected. Anyone can reverse it too, but it takes so much time (trillions of years with all computing power of our planet combined) that the most cost-effective way to reverse it is a bruteforce.

Unless it's a pretty basic insecure hash function.


Does disabling WiFi and mobile data make my phone impossible to hack online? As I understand, a relatively outdated phone (Android 5, not updated for a few years) could be easily compromised by using security exploits through WiFi, mobile data, NFC or Bluetooth.

I'm about to participate to an event where other people might try to hack into my phone (I suppose there is a similar issue when going to the conferences such as DEF CON). Given that NFC and Bluetooth are already turned off, is there any chance for another person to hack into my phone if I keep WiFi and mobile data turned off as well?

Naturally, physical stealing of the phone is out of question, but the intruder can get within centimeters of the phone in a crowd.

By disabling WiFi and mobile data, you shut down some attack paths. That means that your system is more secure, and probably immune to most "script kiddies" attacks.

However, the telephony part will still be active. It is certainly harder to exploit, but a smartphone is far from a 1960s telephone, and even the telephony part has interaction with the phone's OS. That means that is is still possible that a combination of calls and SMS triggers an unexpected condition leading to a possible exploit. I know none of those, because even the Stagefright bug cited by @SteffenUllrich in his answer uses a crafted MMS. And a MMS can only be delivered when mobile data (or possibly WiFi) is active, and will never be if only telephony is allowed.

If you can be sure that god himself was among the engineers that designed your phone system, you are absolutely safe. In any other case, bugs are always possible...

Of course, if you use other functions of your phone like displaying photos, viewing videos, or playing music, you open new doors for attacks with every new application.


Could someone stop another from accessing their own online account? Suppose Alice isn't able to break into Bob's email account, but Alice can still do damage to Bob (a VIP) if she can stop him from being able to use his own email (or any other online) account to send and receive important emails.

So what she does is she writes a computer script that guesses a random password (since most email addresses have the same username) so that it locks her out. Could this also lock Bob out?

What if instead of one or two computers, she goes on the black market and uses thousands of bot computers around the nation to target Bob's account? Or she manages to hack Bob's wifi network so she even has the same IP address? What's there to stop Alice from making sure Bob never gets to use his own account ever again? (Besides two-factor authentication, which most people don't use.)

Essentially you're just talking about a very targeted Denial-of-Service. There would be plenty of ways to achieve this other than just locking out their account. If they were on the same network then there would be plenty of other ways to do it other than just locking out someones account


Is it better to rate limit API requests based on UserId or IP address for authenticated users? I'm thinking of rate limiting anonymous requests based on IP, but for users with a valid authentication token, I can't decide if it's better to log and rate limit requests based on their UserId or IP address.

Option 1 : 15 requests per minute per UserId

Option 2 : 30 requests per minute per IP address

Option 3 : Do both

If a malicious person/entity decides to run a bot attack against the APIs, the best option seems to be rate-limiting them based on IP address because they can potentially have a lot of tokens ready for users with different, say, email addresses (assuming each user registers with a unique email address).

However, there is also the possibility that a sophisticated individual can switch IP addresses during the attack but pass the same authentication token and abuse the system with the same UserId.

The third option seems enticing, but for me, it means every API request needs to be written twice to the database (records are horizontally partitioned based on UserId and there is another partitioning scheme based on IP address. Sharding will make it easier to look up and count requests).

Are there any best practices as far as which option (or something else) to pursue when rate limiting authenticated users? I'd like to have a general idea of what to do before I'm deep into writing all the validation logic?

I would say it depends. In generall IP blocking is a good practice because the IP is the only identifier that exists for anonymous users. But keep in mind that a user can "switch" IPs using online proxy services AND on the other hand that maybe multiple users share an identical IP when they use a proxy server (which ist often the case in enterprise environments).

If your users are authenticated then you should block the userId when the user is doing malicious stuff.

Another aspect, how easy is it for an anonymous user to create a new account in your app? When he can create new accounts without a problem, then blocking userIds is useless, because when the attackers user 1 ist blocked, He easily can create a new user.

So you should rely on both techniqus and check how easy it is for an individual to create new accounts.


Detect Wi-Fi login attempts How can I detect Wi-Fi login attempts? I was thinking to put an Wi-Fi interface in monitor mode and look for leaked SSIDs.

To monitor network devices there's essentially two possible protocols: Syslog and SNMP. Both work including for Wi-Fi. But for any detection to happen, you must configure your device to do so.

Many wireless routers log by default failed login attempts. If your actual router device is not sufficient to accomplish this because it does not support certain features, you can upgrade its firmware to DDWRT or OpenWRT.

Once you have a syslog or snmp working, you then can use quite many tools (SNMP Trap Watcher, Kiwi Log Viewer, SysAid Monitoring, SNMP Log Even sentry, etc) to analyze what is happening.


MITM attack using ICMP packet injection I came across an infosec presentation from a conference which discussed how ICMP packets can be used to compromise a connection between two machines. More specifically, they described the process as:

The attacker can forge a spoofed ICMP packets to force the host to make an ARP request. As a response, an illegitimate ARP replay is generated and effectively routes the victim's traffic to the attacker's machine.

But it is not clear to me how this works and how the attacker exactly would be able to compromise the connection. Could you please explain this further? Additionally, why would someone use this approach?

ICMP here is not used to perform the MITM attack, but indirectly to enable it. In short, it's used to circumvent ARP spoofing protections:

Some MITM attack (not specified in the citation) is the goal.
ARP spoofing is used as a tool to alter victim's routing, helping in gaining MITM position.
Different operating systems handle unsolicited ARP responses differently i.e. the OS can reject them. The ICMP packet is used to make the victim's OS try and connect the machine it tries to reply. If the destination IP / MAC pair is not already cached, it invokes an ARP request. After that, the ARP response becomes expected.

Despite the chronological order is actually 3-2-1, the reasoning is easier to understand if you start from the expected results and then ask how to achieve them. In other words, you have read a story of the execution of an attack, whereas a story of how the attack was planned would have been more educative.


Everything there seems to indicate that someone tried to talk to your web server using the wrong protocol.

Lack of a user agent means no User-Agent header was sent.  Assuming you're using a standard HTTP log format, it looks like you got no Host header either.  That combination by itself is reasonably indicative of someone using the wrong protocol, and the 400 response code adds to this.

The actual request string is binary data.  \x00 is C-style string escape code notation, indicating a byte with a hexadecimal value equal to the two characters after the \x.  The request string looks like it might just be encoded in little-endian UTF-16 (based on the alternating null and non-null bytes, with the null bytes being second), but decoding it as such gives us:

  VYz5zV\x06!VéWWêëÌÌÌ¥Ìé°!éÌ{zY|(W|!é¥é°!{|(é({(éY(¥¥¥5°°Yê|!WëVÌ{¥ÌVÌWÌ|V|{!\x06Ì|5(°{ëÌWêÌëV\x06|é{é\x06ëYéY°ÌYÌêV°!ê¥é{\x065ê°|(\x06ë!|Y!5Y¥°WêW¥5\x06é{{z\x06{5|zézW°!|°(°éê{ë¥êê{|¥z¥V¥!¥ëVWëêzëV!{W¥\x06WVÌ5Yz55ë5Ìz\x06ÌêYVVé\x06|¥\x06Yê¥|°°Vzz{ëWëY(|5W\x06Wz5z\x06Wê55ë!ë°°(5|ÌW{Y5(°Vë5|Vê°Ìê({!ë(\x06zz(!Ì°ê5\x06W¥é|°\x06{Y¥|V{ê\x06ëëW!|ë\x06êWééW(|!!V|\x06WÌzY¥zY((\x06é!°éÌY!|YYzYV(ë°|WYÌ{Ê

Which is pretty obviously not a request string, but does reinforce the fact that it's not just random data, but is somewhat structured.  There's a slim possibility it could be some other encoding, but it's more likely it's just binary data.

Now, just because this happened doesn't automatically mean it's an attack, or even a bot.  There's a lot of stuff that uses ports 80 and/or 443 simply because it lets them cross a vast majority of firewalls and NAT routers without issue.  Simple misconfiguration of such a program can easily lead to it accidentally trying to talk to a web server.  I don't recognize the request string as one of the more common protocols you're likely to see with this, but all that means is that I've never seen it before.


Why don't online banks use WebAuthn? My ideal bank would offer online banking from a browser with user/pwd and WebAuthn, for example with a NFC or USB key. No OTP or SMS or apps on the smartphone or physical devices required. (It goes without saying, no recovery questions or stuff like that.) This would only require to keep one device safe from attackers, i.e. the computer running the browser. Moreover one could use the same key with many other online services.

There seems to be no bank in the world as of 2019/10/10 doing this.
Is this an issue with legacy/proprietary technology, or lack of convenience/ease of use by customers, or what? In other words, what prevents them from doing this already?

Username and password alone or together with WebAuthn1 only offer an authentication of the user.

Modern authentication methods used by the banks like PhotoTAN instead authenticate each transaction separately: not only it gets checked that the user is present but the transaction information are displayed on an independent system (app on mobile phone or extra hardware) so that the user can verify these before authenticating the transaction. Even proper SMS based methods show the transaction details together with the created TAN in the message.

This kind of independent verification of the transaction details and transaction-dependent verification is needed since in the past trojans or man in the browser changed the transactions on the fly, i.e. the user was seeing the correct transaction in the browser or mobile app and authorized it while in the back the submitted transaction information where changed in favor of the attacker.

In other words: username+password and WebAuthn1 only authenticate the user. This is not sufficient and an additional transaction-dependent authentication is needed.

1 As mention in a comment WebAuthn does in theory support authentication specific for a transaction. This still requires an extra device or app though since it is "intended for display on a trusted device on the authenticator". Thus just WebAuthn without such additional trusted device is not sufficient.


Cellphones IMEI public exposed? Currently I'm in the middle of a developement process, and I have some security questions for you. I have a webservice, asp.net which is configured to run over https. The first authentication step for the cellphone is to retrieve the certificate from the server, public key ofc. The next step is to send the IMEI to a service to be sure that this particular phone is registered and allowed to send transactions to this webservice. My questions are:

Is it possible for someone to get the IMEI without having physical access to the phone?
Should I require the a client certificate from the cell phone?

Thanks!

On Android and Blackberry, applications can access the IMEI with no special privilege. On iOS, there is no documented API, and you may or may not get away with using undocumented APIs.

The IMEI isn't a terribly good way to identify a phone. Some exotic locales like North America have CDMA phones with no IMEI. All major platforms have a way to report a supposedly-unique identifier which doesn't change during the phone's lifetime (Android, iPhone), but they aren't always reliable. You can never know whether the reported ID is genuine (unless you make additional assumptions, such as your application being used on a non-jailbroken phone), so it isn't a method of authentication.

Unless you need a device identifier that survives uninstalling and reinstalling your application, generate a client certificate at provisioning time. You'll need something like that for authentication anyway, so you might as well use it to identify the device too.

If you want the ability to install your application to be tied to a particular piece of hardware, most smartphones today don't offer this. On any rootable phone, users can back up their installed applications and restore them on another device.


Why is 128bit AES considered very strong but 160bit SHA depreciated? Why is 128bit AES considered very strong but 160bit SHA 'insufficiently secure'? Google/chrome/browsers seems to drop support for SHA1 SSL certificates. I assume it's more simple to calculate SHA than a round of AES but there are a lot more bits in SHA. I understand MD5 was depreciated bc the algorithm was broken enough that it was not difficult to create a collision but I don't think that comes into play with SHA?

For hash functions (like SHA-1) being used to sign SSL certificates, the security is completely undermined if you have successful collision attacks.  Due to the birthday paradox, a N-bit hash function effectively provides about N/2 bits of security against collision attacks.  That is a brute-forcer can create collisions for a N-bit hash function after generating about 2N/2 potential strings to hash.  Hence an 160-bit hash function provides about 80-bits of security against collisions (meaning it takes about 280 effort to generate a collision via brute-force).

For a block cipher (like AES), you use a N-bit key that maps a block of text (128 bits in the case of AES) into a block of ciphertext in a reversible way if you possess the N-bit key.  Hence, to brute force a block cipher with an N-bit key (and no other vulnerabilities), you need to try about 2N possible keys until you find a key that transforms the ciphertext into the original message.

Thus (without looking at any specific flaws in the two algorithms), a block cipher with a 128-bit key is much stronger (which takes 2128 effort to brute force) than using an SSL certificate signed with a 160-bit hash function (which takes 280 effort to find a collision and completely undermine the security).  In fact it is roughly 248 ~ 281 trillion (1012) times more secure.

Explanation of why collisions break SSL certificates

Basically, an SSL certificate consists of some plaintext information p and a signature S provided by a certificate authority.  This plaintext typically includes the name of your organization and your domain name and similar information.  If you want a new certificate, you then submit this information to a certificate authority (CA) that popular web browsers  intrinsically trust.  The CA checks your information (e.g., they verify you own the domain, by say emailing a code to the email address listed in the DNS records for that domain, OR you pay for an extended validation certificate and the CA does more checks that you are the organization you say you are).  If the information checks out, the certificate authority will agree to sign it and issue you the signature to complete the certificate.  The signature consists of hashing the plaintext information H(p) in the certificate and then using the CA's private key (K_priv) to encrypt that hash (S = E(K_priv, H(p)).  Then anyone can use the corresponding public key of the CA (K_public)  (and your operating system and/or web browser typically comes with a list of public keys of trusted certificate authorities) to decrypt the signature to find H(p) = D(K_public, S) and verify that the signature matches the hash of the plaintext information in the SSL certificate.

Thus if you generate roughly 280 different plaintext messages p (some in the form needed to be a certificate for a domain, some in the form of certificates for intermediate certificate authority), it could be possible to find a pair of two messages p1 and p2 that collide.  If say p1 identifies a randomly changed domain (sgnjnjrafaftjhyqsv.com) that you can easily buy (or you vary subdomains of domains you already own like sgnjnjrafaftjhyqsv.blah.com), then you can verify ownership of p1 to a CA and you can get a CA's signature of p1. Since the hashes match H(p1)==H(p2), you can take the signature from p1's certificate and use it with p2 to generate a valid certificate.  If p2 for example was an intermediate certificate authority that allows you to sign other certificates, you could then use that intermediate certificate authority to sign any certificate you want (and could for example spoof any website you want -- at least ignoring other protections like certificate pinning).

For reference, this attack was successfully used to create fake intermediate certificate authorities against MD5 (128-bit hash) signed certificates around 2008.  Note, ignoring specific flaws in the relevant hashes finding a SHA-1 collision is only about 65,000 times more difficult than finding one in an MD5 hash.  With the cost of computation decreasing, it is believed to be feasible for sophisticated attackers to collision attack SHA-1 and undermine SSL security.  Using a 256 bit hash (like SHA-256) is about 18 billion billion (18 x 1018) times more secure than a 128 bit hash (like MD5) against collision attacks (again ignoring specific flaws in the hash functions).


Can I consider files compressed with password safe at all? A follow up to my 7,5 years old question. Back 10-15 years ago, when I wanted to send an executable file over Gmail from my PC, all I had to do was to change file's extension to some meaningless one or compress that file with a password.
The mentioned question (and all answer to it) proven that contents of ZIP file can be browsed (or even changed) without knowing the password used to build up such ZIP archive. But I still had some (stupid?) faith in 7zip.
Today it turned out that mobile Gmail for Android "knows" that I am trying to send executable .apk file (or prevents me from doing so for any other reason) even when I am:

sending as plain file (obviously),

changing .apk extension to .dat or some other,

compressing with ZIP with no password,

compressing with ZIP (ultra compression) and encrypting archive with a password,

compressing with 7ZIP (ultra compression) and encrypting archive with a password,

using an 7 years old idea of double compression:

compress .apk file into .zip file without password,
compress resulting .zip file again into another .zip file with password / encryption.

The last one actually "killed me". If Gmail "knows" what type of file am I sending, even if I treat that file with a double compression, adding a password-based encryption on top of it, then how can I treat files sent over Internet (even encrypted ones) as secure or even safe?
I am by no mean an expert. This question may sound like a naive one. But, still... I wonder, why should I encrypt files at all, if a simple mail client is able to "break through" password-protected file and tell itself, what type of file is contained there?

This is the classic weapon/armor problem.
Sysadmins do their best to reject content that they think possibly harmfull, while users do their best to hide their data.
Here the most probable detection way used to detect the real content is the name of the file which is (by default) left unencrypted when you put it in an encrypted zip file.
So on a public network where no protection exist againts unreadable data, you should:

rename the data under an unrelated name
store it in an encrypted zip file, still with an unrelated name

On corporate network, encrypted files are often rejected by the mail servers, precisely because it is not possible to scan them for possible malwares. In that case, there are no bullet proof way except steganography, but encoding the payload as base64 in a plain text file is often enough.


Totally different IP addresses assigned when using the same router For some time I have observed a strange behaviour when connecting to the internet through my WLAN. Depending on the computer I use on my network, the ISP assigns me totally different external IP addresses (some begin with 81. ... some with 221. ...). I have the strange feeling I get observed. Normally I always had a static IP beginning with 81, but this changed some weeks ago.

How can my ISP identify the computer I'm using? I tried to change my computer name and my MAC address but wasn't successful.

Private network IPv4 ranges are:

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

Since the IP address ranges you're receiving are from your ISP (you can look them up on a site like arin.net) you're receiving DHCP passthru addresses because your Airport Extreme is in Bridge mode (page 31).

You can better protect your local network by disabling bridge mode, since bridge mode is meant to be used in situations where you're using your own DHCP server to give out addresses and not use the one built into the router. It makes the router act like an access point instead of a router.

This will not slow down your internet connection, but you will no longer be able to connect to your devices directly from the internet without going through the router. Then you can connect to devices on your local network from within your local network, and you'll have better control over the IP addresses you're receiving since you'll be assigning DHCP addresses from the Airport Extreme itself.

They label it in the interface as "connection sharing" which unfortunately confuses people. Also they do mention that you'll get different IP addresses, but they're talking about the IP addresses on the internet (external IPs) as opposed to local LAN addresses (which you will have when you enable DHCP outside of bridged mode).


Is it possible for a hacker to bypass upload php file? I wanna give a filtering system in my script.
here it is :

<?php
$allowedExts = array("gif", "jpeg", "jpg", "png","bmp");
$temp = explode(".", $_FILES["file"]["name"]);
$extension = end($temp);
if (in_array($extension, $allowedExts)){
//here is rst of codes
?>

Means my script will check extension for uploading file with explode .
So, now is it possible for a hacker to bypass this system ? And upload  malicious code script ?

A lot can still go wrong given an application that contains this small snip of code.

An attacker could use a local file include vulnerability to obtain
remote code execution by putting PHP code within the metadata of
an uploaded image.
An attacker could potentially write an image with a valid file
extension in any directory using directory traversal.
In older versions of PHP an attacker could use a null byte to
control    the extension by truncating the filename,  but FILE
functions will escape null bytes as of PHP 5.3.4.


How come iOS exploits/jailbreaks are worth so much in the "0-day trade"? Zerodium, a "premium exploit acquisition platform", bought an iOS jailbreak vulnerability from a child in UK for around 1.5 million USD. They are offering the same amount on their website currently, but my question is, why are they worth so much? What property of a jailbreak makes them cost over one million dollars, as compared to regular exploits like Windows RCE, or even an Android jailbreak.

Any exploit worths much more before the vulnerability is known (AKA, 0-day) than after. The reason is simple, there are no available patches for an "unknown" vulnerability, so the exploit works in every device using the vulnerable software given the proper conditions for the exploit to work.

Once the vulnerability is known (publicly, or to the authors of the vulnerable software) the patch is developed, this may take some time but is happening. Once the patch is available the exploit only works on outdated software, which is much less than before it's patched

That explains why it worths more as a 0-day than as an exploit abusing a known vulnerability. The specific price for an iOS 0-day exploit worthing 1.5 million USD is probably cause Apple was paying up to 500.000 USD last year for a 0-day in their devices, if the "legal market" raises the price the "dark market" will raise it too, if not why would someone sell a new exploit in the dark market with all the legal implications it has if the company already pays more without any legal implication?

Edit: Just as a reference (Real price may vary) you can check how much it's estimated to worth an exploit before and after the vulnerability is known here, and you'll see that proportion between both prices remains aproximately the same for every CVE


How to disable conntrack protocol parsing in the linux kernel? Security researcher Jacob Appelbaum suggested to avoid certain code paths in the linux kernel that are related to conntrack that do protocol parsing (such as fdp, sip, etc.) right in the kernel for hardening purposes.

How to disable conntrack protocol parsing in the linux kernel?

You can disable the module.

modprobe nf_conntrack nf_conntrack_helper=0

More info about securing helpers without disabling the module entirely can be found here https://home.regit.org/netfilter-en/secure-use-of-helpers/


Security implications of running multiple virtual machines on shared CPU cores Recently there has been the recommendation to disable hyperthreading. I was wondering if there is an increased risk of an attack or information disclosure when multiple virtual machines use the same CPU core or when a core is shared between a VM and the host. Should a single core be pinned to a specific VM?

Edit:
To be a bit more specific: recent Intel and AMD processors with x86 architecure, "average" desktop computers or notebooks.

The x86 architecture (both in 32 and 64 bits) isn't really designed for a full isolation between (threads|processes|VMs). There are many low-level hardware pieces that —designed for efficiency— may leak some amount of information between them.

This isn't anything new. See for instance the 2005 paper Cache-timing attacks on AES by Daniel J. Bernstein.

This is also what happened with Meltdown and Spectre. Speculative execution allowed one CPU thread to figure out things that supposedly it couldn't.

Note also that these attacks are statistical by nature. It is a big deal that you only had a 0.03% error data when reading kernel data (meltdown) but it doesn't mean that it would succeed reading sensitive information, or that it was in memory at all!

Is it a risk? Yes, it could end up being one. And vendors (hardware manufacturers, Operative Systems, crypto library developers…) try to mitigate them as much as they can. Should you be too concerned about it? Probably not, but it will depend

A) How sensitive your workloads are

B) How evil are the other VMs

C) How much risk you are willing to take

D) The amount of funding you have available.

If you are the NSA, surely you can buy completely separate physical systems, but perhaps not if you are a home user. It's also different that your other VMs are (hopefully) clean than used to automatically run any malicious executable while continuously signing SSL certs with a CA key!


Would using Google reCAPTCHA allow Google to cheat? Wanting to go a step further into reducing the attacking surface from my "register new user" form I think on using reCAPTCHA (the one Google offers).
Having bots sorted out from being able to register and hence not being able to easily break my website seems good. And to what I understand reCATPCHA helps with keeping automated things from using my register form.
Anyway I started wondering. If the attackers had the consent of Google (which I use to determine the "attacker is a bot"-attribute), then there seems no way the Google reCAPTCHA can stop bots anymore.
In essence: If I import the Google reCAPTCHA feature into my protection-system for my website it will only protect against to the extend

that reCAPTCHA itself cannot be bot-answered
Google does not allow some bot to cheat.

Is my assumption true that importing something as reCAPTCHA functionality already opens potential doors for Google and their partners?
So Google reCAPTCHA can be bypassed by Google, right?
Update and further information
The assumption chance for cheating possible with Google's reCAPTCHA product seems even worse now that I know that to get it to work you actually need to include a Google JavaScript into your website. Perfect to potentially infringe the form data privacy of your users. At least if I am not wrong this is even a worse change for cheating, then the initially worry I had about circumventing a bot attack.
At a further look, when logging in to the StackExchange Q&A network there is yet another Google JavaScript; ajax.googleapis.com is loaded into the website. So if Google wanted to cheat… even here is plenty of chance :-(

Yes, you are correct. The administrators running reCAPTCHA could request a CAPTCHA from your site and then perform a look-up to see which CAPTCHA was generated for your site and therefore the expected string which validates.

The trade-off is that 1) they are probably trustworthy not to be doing this because of the potential damage to reputation if/when caught and 2), it's still probably better than you could implement yourself.


Should I prevent user from operating with site during some first seconds? Imagine the following scenario: User is at attacker.com and plays a game there. Just before he clicks at some point he is rerouted to victim.com using browser's history. User thought that he clicked at attacker.com but really he clicked at victim.com thus involving undesired operation.
See demonstration of it at http://lcamtuf.coredump.cx/clickit/.

How can owner of victim.com protect from such attacks? And should he?

In theory, the website operator can prevent such attacks by using window onfocus and onblur events. For example, on window onfocus event one could create a <div> overlay over whole page for half a second, thus preventing interaction with page elements. I didn't see that in use anywhere though, and I don't suspect it will gain popularity as it will probably be bypassable anyway.

The attack you describe, created by Michael Zalewski is just one of many proof-of-concept novelty attacks demonstrating why 'the web is broken' at a fundamental level. Some of his previous attacks based on timing - HTML5 geolocation consent hijack - exploited similar vector and has been fixed at a browser level. One would suspect this class of vulnerabilities will be fixed in browsers in the (possibly far) future, but they are very tricky to fix as they exploit human imperfections that may manifest in various ways.

Long story short: You could try to experiment with onfocus and onblur events, but be prepared for browser quirks and don't spend too much time over it. It's unlikely to be massively abused by black hats.


Website being probed from the Ukraine I have a landing page setup for my business located at www.jdmxchange.com and have been getting some strange error logs from ELMAH. I apparently have users (or bots) in the Ukraine probing the hell out of my site. It seems they are trying to figure out what technology I have running under the hood. I get exceptions for invalid paths such as

.../wp-login
.../webalizer
.../js/javascriptfile.js
.../user

and so forth. At one point I received about 32 errors within a few minutes. This is my first time with a public-facing site and I am not sure which direction to go into reading up on making sure my site is secured. Can anyone point me to a good place to start?

Requests like the ones you are seeing exist ubiquitously on the Internet. It's called "background radiation" and it's something that everyone with a public service has to deal with.

Don't worry about it. They are random probes looking for holes and if you have properly secured your site against this "background radiation", then you just weather it like everyone else. Assuming, of course, that you have secured your site against this type of threat.

If you are a startup, one of the investments you will have to make is to implement basic security, just like a new brick-and-mortar business would have to invest in locks and a security system. Contact a professional consultant to help you through that process.


SHA256.DB30.com listing of email account After searching a gmail account in Google I've found a result for the website SHA256.DB30.com. The page just shows the name of the gmail account and a list with major and minor hash.

From my basic understanding of SHA256 I guess it's nothing to worry about in terms of having the gmail account hacked, but I was wondering if anyone knows whether this is just a standard internet register or if it could be caused by malware or any other exploit?

Thanks in advance!

I also found my email address listed on db30. After a bit more research I found out that my address and password had been harvested during a Gmail security breach in September. Try checking your address at haveibeenpwned.com to checked if yours is listed in any of the major security breach lists.
Also it could be a good idea to change your passwords for your email and any other sites that you use eg.online banking, shopping etc.


Incoming Packet From Source Port 80 I'm sure no daemon or browser is using network resources, but I found incoming packets from Wireshark:

98.126.43.174 source port 80 --TCP--> MyIp destination port 339 [SYN, ACK]
98.126.43.174 source port 80 --TCP--> MyIP destination port 339 [SYN, ACK]
67.11.225.49 source port 27725 --UDP--> MyIP destination port 10112
67.11.225.49 source port 27725 --UDP--> MyIP destination port 10112

I've setup deny all incoming packets in my firewall.  But it seems that my firewall configuration still allow incoming from TCP port 80 and incoming to UDP port 10112.

I'm sure my IP is not initiating any connection to port 80 to that IP. I  also don't have any daemons that will respond to port 339.

My question is how attacker benefits by sending packet from source port 80?  What is the risk?  Where can I find more detail about this kind of attack?

REVISE:

If I didn't block this packet by using stateful firewall and keep replying with [SYN, ACK] as defaults, what is the worst risk that could happen?

Since the first two packets are SYN+ACK, they look like a response to a connection attempt: the server on 98.126.43.174 might be a totally honest and genuine Web server, who received a connection request (a SYN packet) on port 80, which, from the point of view of that server, was coming from your IP (and port 339). It is possible that the server 98.126.43.174 is currently under a SYN flood attack and the attacker selects random IP and ports for each of its malicious SYN packets; in that case, your IP was randomly selected as purported source for one of the SYN packets.

As for the firewall, some simply block basic SYN packets, i.e. the first packet in the TCP three-way handshake. These firewalls rely on your OS to drop all others since your OS never received the initial packet to start with. This would explain why these packets reach your machine: the firewall lets them pass because it knows that the packets will be either legitimate (follow-up on a SYN packet you sent) or harmless (if you did not send a SYN packet).

As for the UDP packets, they might be responses to previous requests. Some software use a lot of UDP with randomly selected ports, Skype being the usual suspect.


Why does generating a self-signed X509 certificate not require my public key? Let's say I have an RSA (2048) keypair that I generated

private.key
public.key

For testing purposes I'd like to generate a self-signed X509 certificate.

My understanding of a certificate is that it -

Shows proof of ownership of the public key, as verified by some other party (in this case verified by me, since self-signed)
Contains the public key within itself

It looks like openssl lets me create a certificate pretty easily:

openssl req -new -key private.key -out certificate.csr

But here's where I'm confused - why does it require my private key?

I can imagine it probably needs to sign it with something, hence the use of the private key. But then, how does it get my public key to embed into the certificate? It's mathetmatically impossible for it to reverse-engineer my public key from my private key, right?

Thanks!

The private key is the secret that identifies you, any signing or verification of your specific identity need the private key. So any operations that will generate something meant to be derived from your identity will require it.

Also, you are not creating a certificate here, you are creating a certificate signing request, something you would hand to another party to whom would then generate the certificate to grant you access.

if you want to create a self signed x509 certificate you should add the -x509 parameter, something like this:

openssl req -x509 -nodes -days 5000 -newkey rsa:2048 -keyout mypem.key -out mycert.crt

where days are how long the cert is valid (5000 is effectively
indefinite)
nodes skips password business (skip for testing, omit for anything real)
and also output the key and cert for later use

And @bartonjs is correct, private key to public key is possible, public key to private key is not. That's why you can hand out the public key and noone can use that to impersonate you. The private key must be secret at all times.

If you are planning to act as the client wishing to gain access to the server and also the server granting the request you will first need to set up your certificate authority on the server, and the server's certificates.

Somone on stack overflow has a great answer on this already:

https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority

But the basic juiste is, you set up the CA and crt of the server then you do something like this on the server:

openssl x509 -req -days 30 -in request.csr -CA ca.crt -CAcreateserial -CAkey ca.key -out signedrequest.crt

you hand the "signedrequest.crt" back to the person who requested it.

I forgot to mention, get rid of -nodes in my command above, it skips the password process. Good for testing, Bad for security. Just FYI.


What are human weaknesses at generating a password which shall be random? Assuming I know a person who made-up a password with the goal that it should be random because he will use it for a important service. I would like to figure out how I can increase my chance to guess the password. The first step is to think about the typical human weaknesses at generating a password.

One weakness which comes to my mind is that certainly some characters are typically more often chosen than other. I think we have a strong bias to [A-Za-z0-9] because these characters are easy to type.

But I think there are a lot more human weaknesses. For example humans are very good pattern-recognition machines so maybe we unintentionally use patterns for example from words or numbers (even if we try not to do it). But that's very vague.

So what are additionals weaknesses and why they exists?

Disclamer: I have no source for this. This is all based on personal experience

Since most sites today dictates a password policy where passwords must have at least one digit and one uppercase character, the structure is almost always:

One uppercase character
X lowercase characters
One or two digits at the end.

If symbols are required, they're often appended after the digit - most commonly !


Is HTTPS required for PCI Compliance when downloading desktop software patches, if no PII is transmitted, and content is digitally signed + verified? We have a desktop app that downloads patch content via HTTP. The content is digitally signed and verified by client software after download.

Is HTTPS required to achieve PCI compliance if:

No PII is transmitted
Digital signatures are used to sign and verify

If HTTPS is required, is there a specific rule # or section in a specification that mandates this requirement?

Also, if so, is there any other way to achieve PCI compliance without employing HTTPS (more expensive)?

Any guidance appreciated.

As per my knowledge, https is not required if Card data is not present.

Thanks


How safe is SSL on an untrusted computer and network? In situations where the consumer doesn't trust/control the workstation and the network, can consumer safely do potentially sensitive activities (like making a payment or transferring confidential documents) over the internet when HTTPS is used?

For instance: when I use my employer's computer and am on the company network, or I am in an airport and use a public kiosk there, is there a way to keep them from spying on me?

Naturally, IT administrators in these circumstances are in full control of CA management, and could potentially use a proxy and load the proxy's certificate into the trusted root list, so my browser would show everything being fine.

My current understanding is that as long as I can verify that the cert isn't spoofed and is signed by a well known CA, I can be assured that there's no one eavesdropping on the traffic.

Now if my previous statement is correct what is the best way to verify that cert?
I understand that I can just open it up and inspect the CA's name, but are there any extra steps I can take? For instance, could I somehow export the cert I'm receiving from the HTTPS site and submit it to some service for verification?

Validating the certificate will be the least of your problems if you're using a computer that you do not have full control over. If you are really worried about security, the bigger problems would probably be:

web history buried deep within the hard drive (depending on the way information is accessed)
keylogger software
forgetting to log out of accounts

As for the certificate, other signs you can look for besides the name of the CA being a known, trusted organization are that the domain names match and that the certificate is not expired, both of which the browser is built to do. However, this aspect could be tampered with as well since the administrator of the computer can create an intermediate certificate and add their fake CA to the list of those trusted by the browser.


How to diagnose No Certificate alert I have written an application (in C#) to communicate with one of our customers via a web service.  Our customer requires us to use bi-directional SSL.  The customer has sent us their certificate (in the form of a .p7b file).  The client certificate was provided to me in the form of a .cer file.

I've installed the certificates and in the program I use the HttpWebRequest class and add the client certificate to the ClientCertificates collection.

When I run the program I get an exception:

System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

I have used WireShark to try to diagnose the error and I see this (IP Addresses redacted):

1615    12.259771000    CLIENT_IP   SERVER_IP   SSLv3   112 Client Hello
1629    12.429299000    SERVER_IP   CLIENT_IP   SSLv3   1488    Server Hello, Certificate, Certificate Request, Server Hello Done
1630    12.445672000    CLIENT_IP   SERVER_IP   SSLv3   397 Alert (Level: Warning, Description: No Certificate), Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
1645    12.666191000    SERVER_IP   CLIENT_IP   SSLv3   61  Alert (Level: Fatal, Description: Handshake Failure)

It seems the server has sent their certificate, but for some reason, my app is not sending one back, so it sends the No Certificate alert.  However, in my code, it seems to find the certificate and it is added to the ClientCertificate collection of the HttpWebRequest class.  Since I fairly new to SSL, I am not sure where the problem lies?  It could be a programming mistake, but using some test certficates seemed to work.  Does the alert indicate that there is a problem with the client certificate?  Some posts that I have read seem to indicate that although the private key is not sent to the server, it is still needed on the client side.  But after loading the certificate (using the .Net X509Certificate2 class), I notice that the PrivateKey property is null.  Could this be the source of the problem?  The .cer file was provided to me by someone else in the company.

Any assistance or suggestions would be helpful.  I have refrained from posting code as I'm not sure it's welcome here, but I can post some if need be.

Well no, that won't work for you. The point of a client cert isn't really the cert part, but the private key tied to the client cert. If you don't have the private key you can't do anything useful. What would happen is that the request you send is encrypted with the servers public key and decrypted with their private key. Conversely, any response the server sends is encrypted with your public key (the cert). To decrypt the response you need a private key.

What you need from the other people is the PFX file. In actual fact, you should generate the keys locally, and send THEM the client cert. Just the cert though, not the private key.


How can digital signatures assure the sender their message has been correctly received? I am going through a short course on security. One of the videos is talking about non-repudiation in regards to cryptography and sending messages between Alice and Bob. This video talks about how digital signatures can be used to verify the sender of a message, which I understand (Bob decrypts the message with his private key, and then has access to the certificate which contains Alice's identity and a hash that can be verified with Alice's public key). It also talks about how Alice can be assured that Bob has received the message and that, in general, the message has been received by the correct party.
It does not explain how this is possible though. I have seen some mention online that one method might be that Bob then sends a digital signature back to verify he has received the message. Is this indeed a method of doing this? Are there other methods to do this? If this method is right, how can Alice be sure that Bob isn't just randomly sending digital signature out, and has in fact seen the correct message?

PKI ensure that if the message reaches its destination it has not been altered (if signed with sender private key) and/or has not be compromissed (if crypted with recipient public key).
If the sender wants to make sure that the recipient has actually received the message, a higher level protocol must be used. For example the recipient could send a signature of the original (optionaly decrypted) message using their private key. So if the round trip:
A -> message signed with A private key -> B
A <- signature of the original message with B private key <- B

completes, then A can be sure that B has received the correct message.
If you do not set up that round trip, even with modern system where the sender can be sure that the message reaches the recipient system, you have no protection against the message being destroyed between its arrival on a machine and the moment when the human being named B could read it.
This would be more or less an implementation of what was the QSL in the early days of radio frequency message (mainly using Morse code). BTW that QSL was still in use in the 80's to ensure that a message had been received and understood (*): until the sender had not received a QSL to message number xxx they periodically try to send it again or try a phone call to know whether the recipient system was off or out of use (at least at French Met Office).

(*) as QSL to message ... had to be manually sent, it meant that somebody could read the message number and declared having understanded the full message.


How can I migrate from filter-on-output to filter-on-input? I recently joined a company with a million+ lines-of-code PHP app.  The security approach to XSS appears to be to filter output whenever the dev thought of it.  Not surprisingly, they didn't catch everything, and we've got some real doozy XSS opportunities.

In a past life I've used the approach Rasmus advocates: filter all input to be XSS safe, and don't sweat it on display.  This approach worked well: most data works perfectly most of the time, and code that uses filter(UNSAFE_RAW) isn't exactly forbidden but it sure gets extra attention in code reviews.

The problem I'm having is: How do you migrate from one approach to the other?  Seems like now I'm going to have to encode all the contents of the database and play whack-a-mole to remove all the new double-encode bugs I'll discover.  (It should be a little easier since I can grep for the existence of htmlspecialchars() but I can't grep for its absence. :) )

A really useful answer might be a blog about a successful project or even a post-mortem.

Filter on output is the preferred method of XSS defense.  One reason why this method of XSS defense is popular is because it is not dependent on data in your database conforming to an arbitrary encoding set.  Filter-on-input means that the view of the application must trust the database,  as it is assumed this data has already been "filtered".   If the database is compromised with SQL Injection,  an attacker could introduce tainted data to the database.  Here is an exploit I wrote that uses SQL Injection to obtain persistent-XSS on a filter-on-input application,  persistent-XSS would not have been possible on a filter-on-output paradigm.

Filter-on-output is also a more secure approach to XSS defense,  and I'll give you an example in PHP.

Lets say we have a PHP application that uses htmlspeicalchars($var, ENT_QUOTES); blindly, on all input.  The classic case of an attacker introducing  would be prevented in most cases (a decode operation such as base64decode() performed after the htmlspeicalchars() would result in tainted data).  However,  this blanket security measure does not prevent all XSS in the application, most importantly it won't prevent XSS in DOM events.  For example:

Or here is another example,  where javascript:alert(1) is the payload:

go back

Not all data is used in the same way,  therefore its impossible to apply a blanket security measure.  URLs conform to a different XSS rules than that of event handlers, and both of these are very different from the general case of XSS.

So how do you migrate from a filter-on-output to filter-on-input?  DON'T.  The best way to prevent XSS is using a XSS-aware tempting system such as Twig.  XSS is problem with the view,  so you need a view that is secure.


Does Wifi encryption create a private tunnel between the adapter and the accesspoint? When non HTTP/S data is sent over Wifi, can that data be seen by other machines that happen to also be connected to that same access point?

Does the privacy of the HTTP data depend on the encryption mode of the network?

Edit: Reading this post: Are WPA2 connections with a shared key secure? I realise that I know too little about the topic.
Original post remains below.

  Does Wifi encryption create a private tunnel between the adapter and the accesspoint?

No. Not even with 802.1X Authentication. -> See https://en.wikipedia.org/wiki/IEEE_802.1X#Shared_media

  When non HTTP/S data is sent over Wifi, can that data be seen by other machines that happen to also be connected to that same access point?

Yes. If you're logged in to the same WiFi (and connected to the same base station on the same channel if there are multiple ones), then you can usually listen to all other participants. It's basically as if you were connected into the same wired-LAN-hub: Everyone hears everything.

Unless you're too far away from some node in which case that node is hidden to you and you won't be able to hear it: https://en.wikipedia.org/wiki/Hidden_node_problem

  Does the privacy of the HTTP data depend on the encryption mode of the network?

No. Not if somebody is properly logged in to the same WiFi.


Is there multi-factor authentication for machines? Most of what I have seen on mutiifactor authentication (eg wikipedia or here on se) seems human centric. Ie it is a human interacting with a machine and the factors are associated with authenticating the identity of the human to the machine. The factors are related to a person:

something you know (pin, passwords, etc)
something you have (tokens, cellphone, etc)
something you are (speech recognition, fingerprints, etc
somewhere you are (location - you are where you should be, or you are somewhere 'out of place' or 'less trusted')

If all of these, "you" is a person. Single factor authentication is generally 'something you know' and is considered less secure nowadays because of the prevalence of keyloggers, malware, dictionary attacks, as well as all the exploits against the server holding the password. So the security community has come up with these other factors to reduce the risk.

Are there multi-factors for machine to machine communication? Most of our machines communicate via ssh and are 'single factor' (something the machine "knows"). Because it's a machine, 'strong' keys (ie long ones) are used. Because of their length, they are less prone to dictionary attacks. However it is still 'single factor' - once you know the password, the system can be compromised.

Iptables and firewall rules could be considered a second factor akin to 'somewhere you are'. Proper restrictions could help limit the attack surface.

@tom-leek points out the difference between "the threat to a person is impersonation" and "the threat to a machine is subversion". Once a computer is subverted, "what a computer can do, it can do". I am interested in ripple beyond that original subverted computer. Even if I destroy the subverted computer (easy enough to do in a cloud application), the attacker still knows the ssh keys and can use them from other machines (ie it is an impersonation threat). I believe the standard way to mitigate this would be to repudiate that public ssh key. This ripples into many other machines and I was wondering if there were other factors to help with the 'impersonation' threat.

What other 'factors' are there in machine-to-machine authentication?

When authenticating humans, the main danger is impersonation: someone else posing as the expected user. Since humans are biological and not digital, there must be some link between the two worlds: something which ties the concept of the physical identity to sequences of bits on which computers can feed.

We use multi-factor authentication because every single factor we could think of is kinda weak. Passwords can be guessed (they cannot be unguessable because otherwise users would not remember them) or grabbed (by recording with a fast-pace video camera the actual typing of the keyboard -- with a simple telescope, this can be done from several miles away !). Biometrics require visual control (i.e. an armed guard who verify that what goes on the fingerprint reader is indeed a human finger still attached to the rest of the human). Hardware devices can be stolen (especially smartphones, the most stolen kind of object). By piling several factors together, we hope to cope with that crummy situation.

With computers, the situation is completely different. Any computer can contain an extremely robust authentication token, e.g. a big, fat asymmetric key. The main danger for computers is subversion. Indeed, what a computer can do, it can do. Meaning that if a given server is hacked into, then all the "authentication factors" that the server could use are now equally accessible to the attacker. Thus, the scenarios which imply a failure of a computer-controlled authentication factor, i.e. the scenarios in which supplementary authentication factors would be deemed useful, are precisely the kind of scenario where extra authentication factors add no benefit at all.

You could imagine a mixed human/machine setup: computer contains a private key, used to authenticate with other computers, but the key is stored encrypted with a password that the computer does not know; it must be typed at boot time (or possibly at regular intervals). This would bring some additional security, at least in some subcases of subversion. However, servers which cannot reboot in an automated fashion tend to be unpopular with sysadmins.


Where is Enigmail's keyring stored? I have a GPG public/private key to send email with Enigmail and Thunderbird. I received an encrypted email but Enigmail did not recognize it. I tried to use the command line, but gpg complains gpg: decryption failed: secret key not available. I imported the public key that was sent with the mail. I thought maybe the Cygwin gpg was using a different home directory than Windows programs, so I tried

$ gpg --homedir  /cygdrive/c/Users/Chloe/.gnupg --list-secret-keys

And it showed nothing. So where is the secret key that it is asking for?

$ ls -l /cygdrive/c/Users/Chloe/.gnupg
total 40
-rw-r-x---+ 1 Chloe None 9188 Mar 30  2015 gpg.conf
-rw-rwx---+ 1 Chloe None 9956 Mar 30  2015 pubring.gpg
-rw-rwx---+ 1 Chloe None 9956 Mar 30  2015 pubring.gpg~
-rw-------+ 1 Chloe None    0 Mar 30  2015 secring.gpg
-rw-------+ 1 Chloe None 1200 Mar 30  2015 trustdb.gpg

GnuPG on Windows (unless a copy installed from cygwin/Baboon, which obeys the standard ~/.gnupg path of the unixoid versions) has its home directory in %APPDATA%\gnupg, (usually) expanding to C:\Users\<username>\AppData\Roaming\gnupg since Windows Vista (a slightly different path for earlier versions of Windows).

This should translate to following path in cygwin:

$ gpg --homedir  /cygdrive/c/Users/Chloe/AppData/Roaming/gnupg --list-secret-keys


Is a single pass enough when disposing of a HDD? I am in the process of wiping a number of hard drives using DBAN.

I always believed that a single pass makes the data near impossible to recover, but DBAN has a default of 3.

Is it any more secure, and if so, is it worth the extra time required?

According to the articles linked below 1-2 wipes will be enough.

  For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, “A good scrubbing with random data will do about as well as can be expected“. This was true in 1996, and is still true now. “

Even if some data is left unerased or recoverable after the wipe, it is highly unlikely that someone will be able to find it.

  “…with modern high-density drives, even if you’ve got 10KB of sensitive data on a drive and can’t erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 200GB of other erased traces are close to zero.”

Articles:

HTG Explains: Why You Only Have to Wipe a Disk Once to Erase It
How Many Overwriting Rounds Are Required to Erase a Hard Disk?


OAuth 2.0 Resource Owner Password Grant - Handling of Access Token Upon Logging Out I am new to OAuth 2.0. I used BShaffer's OAuth PHP Server on Authorization Code Grant, and I understand that the client application can have its OAuth token separate from its session authentication, that is, if a user logs out, the access token is not revoked, and the refresh token is used to get new access token upon expiry.

I am building a trusted application using an API with OAuth User Credential (or Resource Owner) Grant.   My questions are:

Since I am in OAuth User Credential Grant, should OAuth hold all the user credentials and solely be the user authentication layer (which would act like an SSO layer)?
With that, can I use an OAuth token as a session token?
Upon logging out of the client application, should I revoke the OAuth token?

I don't understand what you mean with Oauth holding the user credentials. That should not happen. User credentials should only flow between the user and the authorization server.
Yes.
Yes. I think it is the expected behavior.


Storing Username and salt in separate table You have a User table:
UserID (auto-incrementing Integer)
Password hash
LastLogin

All related tables are linked by the UserID.
You also have a Username table:
Username
Salt
IncorrectLoginCount
LockedUntil
etc.

A user creates an account. You take the Username + Password and a unique, random salt and hash it all together with Argon2:
hash = argon2(username + password + salt)

You store the hash and the next generated UserID in the User table and the Username and randomly generated salt in the Username table. There is no way to directly tell which Username corresponds to which UserID.
The user attempts to log in. You take the submitted Username, fetch the record in the Username table (unless the account is locked), grab the salt, take Username + Password and salt and hash it. You then search for the hash in the Password column of the User table. If you don't find it, incorrect login and if you do, you log the user in with the UserID.
Let's say you have 100 users.
You then dump 999,900 bogus records into your Username table with no corresponding record in the User table. They look like Usernames, except they correspond to no user in your database and there is no way to tell which ones are real. Now the attacker has to waste time trying to crack the passwords of non-existent users, which make up 99.99% of the records in the table and will run the full length of the attempt before abandonment because they will fail every check since they have no corresponding record.
I'm trying to create a situation where the attacker has to waste time attempting to crack the password of users that don't actually exist.  Also, if the initial attempt to collect the password doesn't succeed, the attacker doesn't know for certain whether it is a dummy record or a user with a strong password.
The Invalid LoginCount and LockedUntil would be cleared once a day.
When a new user account is first created, you search the UserID table, which only has 100 records at the moment, for a matching hash.  Let's say you get a hash collision once a decade or even once a year, even one collision as frequently as once a decade is an absurd stretch in my opinion.  This is especially the case that you are only generating hashes for the much smaller UserID, not the massive Username table.  You simply throw away the hash, generate a new salt and rehash.  You then create the User Account.
Would this significantly slow an attacker down if your database and application code was compromised and the attacker knew exactly what you were doing?
If you attempted to crack the hashes in the UserID table itself, you would have to hash each candidate password separately with each Username.  Let's say you hashed 30,000 times.  Each candidate password would have to be hashed 30,000 times for the first Username, 30,000 times for the second Username, 30,000 times for the third Username, etc.  This would have to be done for every candidate password.

Before getting into the analysis of the process to slow down cracking the hashes, I want to address something far more important first:
If I log in, and my hash happens to match some other user, I will get authenticated to that user. So your whole "look in the Users database to blindly find any match because I don't tie password hashes to users" is a horrifying approach to authentication.
Please don't do this.

Kirchoff's Principle suggests that a system must be secure even if an attacker knows how you do something. So, let's assume the attacker knows that you added fake usernames. Fine, now all the attacker has to do is to look for valid usernames and tie it to UserID before starting to crack hashes.
And to do that, I would look at the logged user activity in the database. I do not know what is logged in your app, but one has to assume that the user's activity will suggest the username associated with it, if it is not stored, specifically at some point in the database. Things like timestamps can make correlation easy.
And since your threat model includes the assumption that the attacker has access to the codebase and the entire database, your approach appears to do nothing but increase your design overhead and database size.
So, your entire approach relies on an attacker never being able to correlate UserId and Username. This is known as "Security by Obscurity" and, while it has its place, it is not a basis for a secure control.

Now let's tie my first point to my second. Let's say that I want to log into UserID 1 because I can see that it's the admin (or an account of interest). I know the password hash. Now I can take all the usernames and their salts to find a hash that might match User 1's hash. It no longer matters which username I use. It might be unlikely to find an exact match like this using Argon2, but this highlights the larger problem with your approach.


Please critique my encryption scheme for a very small microcontroller I am new here and not an cryptography expert; but I have been using encryption library for a while. My company is working on a small hardware device. It is powered by a microcontroller so memory is an issue we have to deal with. So we decided to come up with our encryption scheme when sending messages to the devices. This is what we are planning to do.

Key distribution is not an issue as we physically update the shared secret almost everyday and it is not stored on the device itself.
For encryption key. The shared secret is concatenated with a very large true random number (used as IV), then a hash function is applied x number of times to obtain a fixed length key for the first block of data.
To encrypt subsequent block of data, a new vector is derived by the block number and the IV. A new key is then generated like in 2 just for this block of data. Hence every block of data has its own key.
We know some hash functions are expensive, but speed is not an issue here since the device is slow to begin with.

So this is what we have come up with and we will appreciate your comments.

Edit: After more research. I found that what I described is just CTR mode here? So I will go with an existing implementation. Any recommendation on a library? I also heard some people said they had encountered cross platform issues between iOS and Android. Any comment on this?

Well, for one, the description of your scheme is not a scheme description. This is just a collection of vague intents. The description of a cryptographic scheme must be such that by reading the description alone, I could write an independent implementation that interoperates with yours. A good description looks like this. Or that.

Also, in your description, you don't actually say how you, you know, encrypt things. You seem to allude to some key derivation scheme from which you obtain "vectors" that appear to depend on the shared secret, but not on the data itself. What these vectors do, and how the data is encrypted and decrypted, is unclear.

In any case, designing your own cryptographic algorithm is a bad idea for the main reason that it is extremely hard to come up with a secure algorithm. Most of the training in cryptography consists in understanding just that: making a secure algorithm is a hard endeavour. The conceptual reason for that is that there is no test for security. The best we can do is to write down a complete and detailed specification (including a reference implementation, test vectors, and a heavy rationale for why it might be secure) and then submit that to a bunch of cryptographers and let them try to find flaws. It takes dozens of cryptographers, and several years of effort. This is why that kind of job is done through organized "competitions" like it was done for the AES.

A ten-line question on security.SE cannot be considered to be a reasonable alternative.

Moreover, most situations that warrant encryption (to ensure data confidentiality) also need something to guarantee integrity, because attackers are evil, don't play "by the rules", and may try to alter the data in transit, possibly to learn things about the data and keys based on how the systems behave when facing the altered data. Integrity is obtained through the use of a MAC. Combining encryption and a MAC securely is harder than it looks, so, there again, it is a job for competition-powered cryptographers (usual recommended solutions are GCM and EAX, but there is, indeed, an ongoing competition to get something better).

And when you have a good protocol (a secure assembly of secure algorithms) that should fulfil your needs, then you are not done yet; you must still get an implementation that is correct, robust, efficient, and (crucially) does not leak information. Side-channel attacks can be particularly deadly for careless code in embedded systems. There again, this is a matter of science and also a lot of skill, that cannot be improvised.

To sum up, you are in need for, at least, some serious help from a professional cryptographer (no, I am not for hire at the moment). Unless you are in a case where the data you want to protect is uninteresting, which ensures ultimate security: nothing protects data more than making the data so boring and useless that nobody actually bothers to try to access it.


SQLmap POST parameter 'txtLoginID' is not injectable I have a lab machine that I have been practicing some SQL injection on.

I know that the POST parameter that I am trying to exploit is vulnerable as I was able to extract the user DB manually.

I then went to do this with SQLmap with the below command.

sqlmap -u 192.168.1.50/base-login.asp --dbms="Microsoft SQL Server 2000" --data="txtLoginID=admin&txtPassword=test&cmdSubmit=Login" -p txtLoginID --method=POST

Every time I run the sqlmap command I am told that the txtLoginID is not injectable. I thought this was weird as I know for a fact that it is. (I also tried the above command with the highest risk and level set)

I proceeded to take a capture of the traffic to see if I saw anything out of place. Everything looked okay and I even took some of variables that sqlmap was trying to pass and manually entered them. When I did this I was given output as you would expect when injecting SQL.

I even captured the HTTP headers with Live HTTP headers plugin and was able to successfully replay them which produced output as I would expect.

I am new to sqlmap so I was wondering if I am missing something? From everything I have read/seen on the internet it appears I am doing it correctly.

To be sure of your syntax, you can intercept a regular request of your post by burp for example. You save it in a file and you can inform sqlmap to use this request for testing an injection.
For that the option in sqlmap is -r.

Target:
    At least one of these options has to be provided to set the target(s)

    -d DIRECT           Direct connection to the database
    -u URL, --url=URL   Target URL (e.g. "www.target.com/vuln.php?id=1")
    -l LOGFILE          Parse targets from Burp or WebScarab proxy logs
    -m BULKFILE         Scan multiple targets enlisted in a given textual file
    -r REQUESTFILE      Load HTTP request from a file


Why most of the web applications use CRSF token as a prevention method instead validating through origin header? Why was crsf token discovered at the first place? One can always check from the the request generated by origin header

"the user agent MAY use the Origin header field to inform the server of the security context in which the script was executing when it caused the user agent to issue the request"

It is not obligatory for a browser to supply the header. In the absence of a valid Origin header, what assumptions should the application make?

"The Origin request header indicates where a fetch originates from. It doesn't include any path information, but only the server name"

Hence:

Your suggestion would only provide protection against attacks initiated from other vhosts, not from different applications on the same vhost
will cause legitimate requests to fail if the application implements domain sharding
requires the application to know the domain it is being served up by

Further, origin support is patchy.

Given that it provides a mechanism for user tracking/de-anonymization without relying on client side persistence, it is unlikely to be viable in the long term as a means of ensuring session integrity.


HDD password cracking I recently changed the decryption key to my WD My Passport HDD two days ago. Before I left for the weekend, I tested to make sure that the key would work. However, the password that I set, which got from the pseudo-random key generator,  does not work anymore. I copy/pasted the password into the field to change it, and I always make sure that I have copied the correct item before confirming the change. That all said, there exists a possibility I hit a key while trying to copy the password and did not notice, so I hopefully know the 95% of the password.

Are there any tools available to crack external hdd in a scenario like mine?

Edit: I used WD's Drive Unlock full disk encryption

Assuming the software doesn't have a power-up limited number of tries, you could script the GUI interactions with sikuli.

http://www.sikuli.org/

Don't expect hundreds of tries per second.  I would expect less than 10 tries per second... but that could very well be enough.


Clarification on Digital Certificates I used the makecert tool to create:

self-signed certificate
client certificate

These are the commands I used:

makecert -n "CN=MatthewCA" -r -sv MatthewCA.pvk MatthewCA.cer **for self signed certificate**

makecert -sk localhost -iv MatthewCA.pvk -n "CN=localhost" -ic MatthewCA.cer localhost.cer -sr localmachine -ss my -sky exchange -pe -b 01/01/2013 -e 01/01/2020 **for client certificate**

The two commands generated the following files:

MatthewCA.cer
MatthewCA.pvk
localhost.cer

I then installed MatthewCA.cer in the Trusted Root Authorities section inmmc.

The localhost.cer was installed in the Personal section in mmc.

When I view the certificate of localhost.cer from mmc, it says:

  You have a private key that corresponds to this certificate.

Does this mean that the certificate contains the private key?  If I send the localhost.cer to someone else, can they extract the private key?  If yes, how can I separate the private key from the certificate?

When the machine says that "you have the private key corresponding to this certificate", then this means that you have the private key which corresponds to the certificate, not that the certificate itself contains the private key.

Asymmetric keys come in pairs: the public key and the private key. They are mathematically linked to each other, but rebuilding the private key from the public key is considered unfeasible (way too expensive with existing technology). This is why the public key can be made public: this does not reveal the private key (which is kept private).

The certificate contains only the public key. The certificate is inherently public and can be shown to the whole World. When the certificate is used in SSL, it is indeed sent, as part of the protocol, to the peer. The private key, of course, remains private. In your case, the private key was generated within the entrails of Windows and it stays there. The localhost.cer file contains only the certificate.

(Unfortunately, some documentations designate by "certificate" the union of the certificate itself and the private key; this abuse of terminology is a great source of confusion. In the Windows world, when a certificate and a private key travel together as a file, the file follows the PKCS#12 format, also known as "PFX".)


Please help verify my understanding of Domain Validation (DV) SSL Certificate This is what I understand so far from reading various knowledge bases and articles about DV SSL. Can anyone please help clarify if any of these is wrong?

DV SSL (and SSL certificate in general) is only associated with a domain name, not the IP address configured under DNS for that domain. Hence if I change the IP on my domain's A record I don't need to repurchase another SSL certificate
Most DV SSL providers (eg: GoDaddy) will verify domain name ownership by sending an email to the address registered in the domain 'whois' record
Although DV SSL is the 'lowest end' of SSL certification, as long as the private key and the email password did not fall into the wrong hand, no hacker should be able to register a DV SSL for my domain and / or setup a fake phishing website under my domain name without the browser warning the user for possible attack

A Certification Authority, before issuing a certificate to an entity E, with E's name and E's public key in the certificate, is supposed to verify that the public key in question really belongs to E. For SSL server certificate:

E's name is a host name, like www.google.com, possibly with a "wildcard" (*.google.com). This is what SSL clients verify; this is all about names, not IP addresses.
The public key is received by the CA as a certificate request.

So the notion of "identity" in force here is really a question of domain ownership. The CA wants to make sure that it received the request from someone who controls the domain. There are several methods for that; the two most used are the following:

The CA sends a challenge by email to the email address specified for the domain in the WHOIS database.
The CA challenges the requester with some information to be included in the domain, e.g. a random host name to be included in the DNS.

These checks are not extremely robust (they rely on the "impossibility" to hack into, respectively, emails or the DNS, neither being well protected) so there is a recent fashion for stronger verifications, called Extended Validation Certificates. For an EV certificate, the CA is supposed to do a lot more paperwork to make sure that it talks to the right entity. Retrospectively, non-EV certificates are dubbed "DV" (as "domain validated").

The net effect of an EV certificate is that Web browsers recognize them as such, and may show that fact to the human user with a more lavish display, with a lot of green. But non-EV certificates technically work just as well. An EV certificate is worth the effort only if your users are trained to recognize EV certificates and feel more comfortable with an EV certificate than they would with a "normal" certificate (which is still shown with the famous "padlock" icon). Right now, I'd say that most Internet users are far from being aware of the distinction, so buying an EV certificate is kind of useless.

(EV certificates will become useful when they become mandatory, i.e. when Web browsers begin to reject or warn about SSL server certificates which seem valid but are not tagged "EV". This is a rather tough transition and I don't see it happening in the near future.)

For a bad guy to obtain a seemingly valid certificate with your server name in it (the prerequisite for mounting a really successful impersonation attack), he must do one of the following:

Fool the CA. Fooling the CA is harder for EV certificates (that's the point). However, even if you get an EV certificate, it would not prevent the attacker from obtaining a non-EV certificate in your name from a gullible CA. An EV certificate will protect you against sloppy CA only as long as your clients are trained to pause and become suspicious if they see a seemingly valid but non-EV certificate bearing your site name. This hardly seems realistic right now.
Steal your private key. If an attacker steals your private key, then he can use it with your certificate (which is public) to install his fake server. EV or non-EV is irrelevant here; what matters is that you should protect your private key well. If your server is broken into, inform the CA so that it may revoke your certificate, and issue you another one (with a new key).
Fool the human user into disregarding the very red and scary warnings from the browser when an invalid certificate is shown. You cannot really defend against that, except through educating your users. The warnings shown by Web browsers tend to increase in scariness (and redness, too) over time.
Fool the human user into connecting to an attacker-owned domain with a perfectly valid certificate, and a name which looks like the intended server name. E.g. www.gogle.com or www.google.business.com instead of www.google.com (fictitious examples). There again, only user education can really work against that.

Most phishing attacks are based on one of the last two methods, so this means that you should not be overly worried over the DV/EV dichotomy. The really important point for security is user education.


How do I prevent XSS in direct access to AJAX/JSON APIs? In my rich client, I escape user-provided data before rendering to prevent XSS.

The data comes from the server unescaped. That is necessary for application logic, e.g., avoiding  situations where I mistakenly check   "O&amp;Donnell"==="O'Donnell"

Yet an attacker can send the user a link to direct GET access to the underlying JSON API; or the user might stumble upon it. This enables XSS.

How do I prevent this? CSRF tokens?  Setting content-type to plaintext or JSON and not HTML? Some other approach?

Setting content-type to plaintext or JSON and not HTML?

If the API returns JSON, then you should the content type to application/json. Apart from just being correct, this will also stop any XSS issues. If a user navigates directly to an API endpoint in their browser, the browser will just show the raw JSON and not try to render any HTML or run any scripts.


HTTP paranoia/concern I am currently creating a personal "local" website. I do not plan on port fowarding to make it accessible to those outside my network. Will that be good enough for security, what about people on the same local network as I am, how can I block any other PCs from accessing my website, or password protect it?

I feel that HTTPS is not needed for this type of setup due to it being a local website, but I have connection to many APIs: Google Maps API, Facebook API, etc. Can my site be compromised without having HTTPS?

Local network or local machine? For the latter, bind to localhost only for the webserver, database and such. If you are running the application in a LAN on a remote server, then HTTPS is not that strange. Depending on the threat you expect, create a access policy on the webserver.


A neighbor took the Mac address from my router It would appear one of my neighbours is monitoring my internet traffic, I am wondering firstly how is this possible and secondly would using a VPN stop the attacker from being able to read / intercept my traffic? They are posting my data online and others are harassing me for it.

What can I do to stop this? Will replacing my router help in any way?

Remember, just because you are using a wired connection, doesn't mean that your router/modem doesn't have a wireless connection.  Most ISPs that I'm aware of, give out a wireless modem/router these days since wireless has become more prevalent.

The person you spoke to at your ISP is correct in saying that wireless connections are relatively easy to crack, especially if they are left to their defaults, which I'm assuming that yours is since you said that you aren't using it.  You may want to contact your ISP to find out if you do in fact have a wireless modem/router and if you do, how to disable it.


Using fail2ban for detecting suspicious activity whitin a webserver I know that fail2ban is mostly used for blocking IPs trying to brute force an SSH endpoint and other stuff like that.

However, I am wondering if you could also use fail2ban to detect (not necessarily prevent) suspicious activity within a webserver.

For example: Let's say an attacker managed to break into a webserver as a non-privileged account (by whatever means: be it a Remote Code Execution flaw in the web application, brute-forcing a password or even a vulnerability in the Operating System). The attacker is now able to run commands on that machine. One of the things an attacker might now try to do is to somehow conduct a privilege escalation attack to gain root access. I guess that most attacks like that and other activities and intruder will normally do within a webserver would cause some traces within the log files - which could be monitored and admins could be warned via email or something like that.

If this is the case: Does it make sense to use fail2ban for this task?

If yes: How do you do that? Which log files should be watches for what kind of regex? Are there ready-to-use fail2ban jails for that somewhere on the web? (Couldn't find any.)

The webserver I'm talking about is of "midlevel importance" I'd say and runs with Ubuntu 18.04.

(I know there are many tools or Intrusion Detection Systems better suitable for that task. However, using fail2ban would have some advantages in my case.)

Sounds like you are trying to build a web application firewall (WAF) over Fail2Ban by creating a bunch of custom filters. The problems with this approach include:

Fail2Ban works after something has already been achieved. Now the attacker only needs to wait for the ban time or simply use another IP address to collect the prize.
Fail2Ban can only monitor the parts of the requests that are logged somewhere; e.g. POST data and cookies sent by the client aren't usually logged anywhere.
Youd would need to create and maintain a huge variety of filters. That's awfully lot of work.
Fail2Ban consumes lots of CPU time processing all the logs against all the filters.

Instead, you should be using an existing WAF that has a wide and maintained rule set, like ModSecurity with OWASP ModSecurity Core Rule Set (CRS). After the suspicious requests have been blocked with ModSecurity, you can use the logs produced by ModSecurity to block the IP addresses using Fail2Ban. E.g. with Apache you could use the updated filter from Kazimer Corp.


Spam email text analysis A spam email was filtered by my email service provider.

The obvious footprints such as email address, 'click here' links, coupon code, urgency to receive the rewards are all there. At the bottom of the email, the text below was present. This text was hidden by a black text highlight colour. Note there is a blank space between the email body and the text below. Presumably, for a handheld smart device user who at a first glance will be unable to see the text below on its screen.

Question. What is a purpose of such a text? To fool the spam filters in an attempt to appear a genuine email (not to mention a deliberate spelling mistakes are included)? Surely the other attributes mentioned above will block the email anyway then why the additional text?

Here is the text.

For starters, I've been patronizing M Grill for years. I think it hit its prime (with me) two years ago; since aphidsn externalisations staff seems to change frequently and with this, idem level of service has been quite volatile. I don't require a lot of attention at Fogo or M grill; I just need my bottle of water replaced once in a while, plates cleared when heroicsy've been placed to keratogenous side, some "is everything okays?" And I'll be a happy camper. I don't feel like I should go on a witch hunt to find some attention. My last visit I went for a quite little dinner. No one stopped by our table after we sat and got our initial bottle of pelligrino; I'm parched, annoyed bc I want some bread and a little service, and to top things off a busser drops a dirty fork off his tray and into my favorite LV bag, jokes, and laughs. Mind you, he didn't even collect our table's plates. I didn't think it was amusing. Very fortunate for fuselagesir manager, Robert Ilgenfritz, who made up for all clapperboards mishaps of blanketers evening. Our server can thank him for jovialise 22% tip he got. And M Grill can feel confident ensepulchersy have found a good find in hiring him. He was constantly walking around dialogs restaurant, which is why I even got any attention. And, why my bag will be receiving a nice dry cleaning.

You are correct, it is an attempt to fool the spam filter by throwing off the statistical analysis of the text.  Without all this nonsense text, the filter would rate it, say "90% likely to be spam" because of "Click Here" and other text.  Now, with all this business speak in the hidden text, the filter can't be so sure and might rate it "50% likely" and with a better rating might squeak under the block.  Also, the nonsense text would allow way more randomization so that it wouldn't match at all an otherwise identical email that has been flagged by a human as junk.

You said "Surely the other attributes will block..."  It really depends on how the filter is configured.  This wasn't a sophisticated attempt but administrators are always tweaking the configuration so that they don't lose important emails.  So, it is never a yes or no answer to "Is this Spam" but a likelyhood so that an admin can say, "We want to block what our filter says is 75% or more likely to be spam but allow everything else"  Then, it becomes an arms race of fooling the spam filter.