What is RSA OAEP & RSA PSS in simple terms After googling or youtubing, i still cant find any information on RSA OAEP & RSA PSS. Can someone explain it in simple terms to me? I understand RSA is public key and private key. Why is there so many variant like OAEP and PSS?

"Textbook"/"raw"/"unpadded" RSA has an "oops, the real world happened" problem.

Consider any RSA key whose modulus is 4096-bit. It should be nearly impossible for someone to recover a message encrypted under that key, right? Let's assume that this key has a public exponent value (e) of 3.

If Alice uses this public key to encrypt the message "No" to Bob she would do something like

"No" => ASCII("No") => 0x4E 0x6F => m=0x4E6F.
c = POW(0x4E6F, 3) MOD n => c = 0x75CCE07084F MOD n.

We know that n is a 4096-bit number (given) therefore it's larger than 0x75CCE07084F, so c=75CCE07084F.

Mallory now sees a transmission of [506 0x00s] 07 5C CE 07 08 4F.  "Hmm," she thinks, "that was a suspicious amount of zeros".  She fires up calc.exe in programmer mode (hex) to input 75CCE07084F, and switches it to decimal (8095174953039).  She copy/pastes that to Scientific mode and hits the cube root button (20079).  She cackles at the integer solution and does the copy/paste modeswitch dance to get back to hex (0x4E6F).  She further checks an ASCII chart and reconstructs that the message was likely the English word "No".  Mallory has now recovered this message without the use of the private key.

What went wrong?

The combination of the message and the exponent resulted in the modulus operation not being required. Computing n-th roots isn't pleasant, but it's not an intractable problem.

For e=3 the modulus operation won't be involved for any m whose length is less than one-third the size of the key.  For a 4096-bit key this means all m <= 170 bytes are immediately recoverable because the key wasn't relevant.

How to fix it?

One way would be to increase the minimum size of the public exponent.  That doesn't solve a secondary problem that textbook RSA has, though: sending the same message encrypted against the same key is the same every time.

Another way is to make it so that m is always "nearly n".  One could seemingly accomplish this by taking the normal message and reversing it, but that a) could exceed n, and b) fails when m ends in a lot of 0x00s.  (And that still wouldn't solve the determinism problem).

So the solution that was come up with was to always "pad" a message to ensure some high bits are set and that any exponentiation uses the modulus value.

Enter PKCS1 padding

PKCS#1 (encryption) padding looks like

00 02 [a bunch of non-zero random bytes] 00 [the message]

The number of non-zero random bytes is as many as required to make everything perfectly fit in a buffer whose size is (keysize + 7) / 8 bytes (that's divide by 8, round up).  The spec says that there's a minimum of 8.  This means that the chance of producing the same encrypted value of any message is one in 2^64, which is pretty good odds of uniqueness.  And the shorter the message is the less likely a duplicate is.

This message has a "size" of 4096-6=4090 bits. Taking it to the third produces an answer in the realm of 4090*3 = 12270 bits.  That will definitely exceed our 4096-bit modulus, so the mod is guaranteed to be involved.  We've also solved our original goal of making it so that you can't trivially decrypt the message.

What went wrong this time?

It turns out that wrong answers can "decrypt successfully".  Any message C is valid against any 4096-bit key k with odds

1/256 * 1/256 * (255/256)^8 * (1 - (255/256)^502)

("first byte is a zero", "second byte is a 2", "no zeros appear within 8 bytes", "a zero appears eventually")

0.004 * 0.004 * 0.996^8 * (1 - 0.996^502)
0.004 * 0.004 * 0.969 * (1 - 0.140)
0.004 * 0.004 * 0.969 * 0.860
1.27e-5

So approximately 1 in every 78 thousand messages is "valid", but wrong.  This can confuse Bob and make him say silly things in response.  If Eve (who has more free time than Mallory) wants to she can now start sending Bob clever gibberish and observe when he says he's confused, eventually Eve can figure out what the original message was.  (Bleichenbacher attack (Crypto.SE))

Enter OAEP padding

OAEP padding is a lot more complicated (https://tools.ietf.org/html/rfc3447#section-7.1). It is constructed in such a way that

A really high bit is still always set
Randomness is still injected, so the non-determinism is preserved
The decryption operation can determine if it got the right answer (vs "a maybe right enough" answer)

OAEP depends on a hash algorithm for the "correctness" property, and so as long as a good hash algorithm is used it means that there's no tricky secondary answers.

Okay, so what about signatures?

Similar (but different) arguments get us from textbook RSA to PKCS#1 signature padding.

The PKCS#1 to PSS transition is a bit harder to explain.  To quote from RFC 3447:

  Two signature schemes with appendix are specified in this document:
     RSASSA-PSS and RSASSA-PKCS1-v1_5.  Although no attacks are known
     against RSASSA-PKCS1-v1_5, in the interest of increased robustness,
     RSASSA-PSS is recommended for eventual adoption in new applications.
     RSASSA-PKCS1-v1_5 is included for compatibility with existing
     applications, and while still appropriate for new applications, a
     gradual transition to RSASSA-PSS is encouraged.

PSS adds randomness to the signature generation process, and a methodology for removing/verifying the randomness during verification.

Conclusion

The primitive RSA operations do what they need to do, turn a number into another number which can be turned back into the first one.  The important suffix "securely" requires a bit of constraint placed on the inputs to the functions.  The padding algorithms provide those constraints (and when new constraints are learned, new padding algorithms get invented).


Buffer overflow with zeros I'm starting to learn about buffer overflow, and I'm trying to change the contents of the return address to a specific location using gdb, but the problem is that the address starts with some zeros.
For example, I want to change the return address to: 0x0000555555554816. I tried to use Perl and passing this address as $(perl -e 'print "\x00\x00\x55\x55\x55\x55\x48\x16" x 10') but bash ignored the \x00 because this is the null byte.
Does anyone know other alternatives to work around this problem?

That's the problem with hardcoding return adddresses in your payload - the controllable memory region would normally contain zeros due to the way memory management works. Given that null bytes ('\x00') are considered as string terminators, anything that comes after will be ignored.
A cleaner way is to find the address of an instruction in the vulnerable program's code that contains some kind of jump instruction to a memory location you are successfully overwriting with your buffer. In stack-based buffer overflows, you would likely need to find a JMP ESP instruction that would take the execution flow to the top of the stack, which would execute your shellcode. Therefore, you need to overwrite the return address with the memory address of any JMP ESP within the program's instruction set (this is assuming you are not dealing with ASLR protection).


Why does an overload of requests give one root access all of a sudden? There's this saying that using a DDOS-attack, people first attack a server using millions of concurrent requests and by doing that they miraculously gain access to the server.

How does this work? Why does an overload of requests give one root access all of a sudden?

There's this saying that using a DDOS-attack, people first attack a server using millions of concurrent requests and by doing that they miraculously gain access to the server.

I think with "this saying" you refer to the recent attack at Talk Talk. There were a lot of miscommunication (like talking about "sequential attack" instead of SQL injection) and part of this were claims, that the break-in happened because of a DDoS attack. From The Register:

  The telecommunications firm previously confused security experts by stating that the customers' data may have been compromised via a Distributed Denial of Service (DDoS) attack which had targeted the company's website.

This was later rectified and made clear that it might be that a DDoS attack was used to distract from the real attack but it might have been unrelated too.
But, false information live on for a long time, sometimes in a form of "this saying" where the original source of the false information is no longer known.

To make it clear: a (D)DoS attack might be used as a distraction for another attack but (D)DoS by itself is not able to give access to data.


How can I block flash from obtaining a list of available fonts in my browser? How can I block Flash, at least in Chrome, from obtaining the list of available fonts in my browser? It seems that the combination of fonts available is the easiest way to fingerprint a browser.

Use the open source Flash/SWF player - LightSpark.

If LightSpark currently provides only a Mozilla browser plugin, encourage the developers to port to Chrome, or port it yourself.

If LightSpark doesn't currently have a toggle for disabling or anonymizing font information, upload a patch to the project, or encourage the project developers to do so.


Are honeypots successful in preventing attacks? I've been looking to set up a honeypot, but it seems that honeyd's source code is out of date, and there are few other options.

Which brings me to the question, does anyone employ honeypots as a practice? What software do you use and what options are there in the open source arena?

By the definition of a honey pot, no, they are not a prevention tool.  Honeypots are a tool for behavioral analysis (by seeing what kind of data they are after), slowing an attacker down (by giving them large amounts of noise to manipulate), or fingerprinting an attacker (you have a copy of all the files in the honeypot, and you can compare their downloads to yours).

A honeypot is only available to the attacker after they have compromised your network.  If it isn't the attackers first stop, they may not get there during their attack.

Does anyone employ honeypots as practice?  Yes, I personally know of several companies that handle medical documents that do.  Some military nets use them as well.

Look up honeynet.

Also:

honeypot list


How to store private data both securely and publicly accessible? The task may not be solvable in as broad a formulation as in the title, but this is my scenario (which is somewhat similar e.g. to newsletter subscriptions and therefore certainly has already been thought about)

I want to implement a database on a web server where private data about users is stored. The users are not supposed to have a fancy login name, instead they are to be "email validated", i.e., access to a mailbox should be sufficient to authenticate.

Users should be able to create, update, delete only their own data.
Central administration should be able to export the data from the webserver to a secured host.

The attack scenario is that the web server together with all data on it (including web page scripts and the database) gets compromised. The requirement is that private data stored there before the compromise remains protected (assuming no further user access is attempted).

Here are my ideas so far: To authenticate I have only the users email.

A new enters his emailinto a form, which causes hash(email) + publicencrypt(email) + random nonce + timestamp to be stored representing the user and the user is sent a mail containing an URL with parameters random nonce and email. (As there is only (protected) email and not (unprotected) username plus (protected) password, things like salt cannot be used and I have to resort to hash(email), don't I?).
The same happens with an existent user, where only the hash(email) will be the same as in any previous attempt. publicencrypt(email), random nonce, and timestampwill differ.
Anyone accessing an URL with parameters  email and nonce as generated above can perform operations on the corresponding database record after checking: Does there exist a record with matching hash(email) and matching nonce and not too old timestamp? If yes, the user can proceed. Note that during the web session of this user, the cleartext email is available.
The export to the secured central administration host happens by exporting the data encrypted as it is. Decryption happens with the private key matching the public key used to encrypt (the latter is considered public because it resides on the compromisable server).

Adding a new entry is completed at this point, by adding a flag isValid to the record. Deleting the record is of course easily done. Displaying non-confidential data (e.g., when was the entry created or last modified) is also a trivial task.

My problem is: How to handle additional private data securely?
I might just store it in encrypted form (like the email), but in that case the content cannot even be shown to the authenticated user. He may change it, but cannot decrypt it in a later web session. This is of course sub-obtimal.
My only idea is to encrypt the additional data with a different key: Instead of the public key of an asymmetric key pair use a symmetric key that is reproducibly produced from email, i.e., store additional data as symmetricencrypt(data,key_generated_from(email)). As the cleartext emailis available to the user himself during his web session, as well as in the decrypted export on the secured host, data can be reconstructed.

I see the following problems:

Given the restricted format of email addresses (e.g., some domains may occur very often), could a key generated from the email as described above be secure enough at all?
Actually, given the restricted format of email addresses, is the hash(email) I used in the basic concept that secures only the email  good enough at all? (Is there enough entropy in email addresses, so to speak?)
Is there a better approach?

I think you might be looking for a token based authentication system. They submit email address, the server produces a token and sends it out to them, they click on the link which must post the token back to your website in some form. The token is random and valid only for a limited amount of time ( say 15 minutes - think memcache ^.^) and can be refreshed based on user action. As for encryption, you could derive something from the email hash as a key and never keep the plain version of the email address. And refuse to reuse hashes in the new user phase..

As a side note, it sounds very scary using just the email to gain access. Mind you that most apps outhere that users will touch nowadays the first thing they will look at is the contacts. Therefore there's a very high chance someone already has a list of users and access.


Convert ECDSA signature from plain to DER format I am doing active authentication of ePassports according to ICAO 9303 standard (part11).

Send a challenge to the chip, the chip signs it using its private key (stored inside the chip, not readable)
The chip sends the siganture .
You then verify the signature using the public key (can be read from the chip)

There's two possible signature Algorithms: RSA (RSA-SHA1, RSA-PSS, RSA-SHA224, RSA-SHA256, RSA-SHA512) and ECDSA.

In section 6.1.2.3 of ICAO9303 part 11
 it reads about ECDSA: " For ECDSA, the plain signature format according to TR-03111 SHALL be used. Only prime curves with uncompressed
points SHALL be used. A hash algorithm, whose output length is of the same length or shorter than the length of the
ECDSA key in use, SHALL be used."

What I don't quite get is how do I use the ECDSA signature in this plain format with OpenSSL?
In the following code EVP_DigestVerifyFinal returns -1. How can I bring the signature oSIG from plain format to DER format?

bool doAA(std::vector<unsigned char> oRND, std::vector<unsigned char> oSIG, std::vector<unsigned char> oPKEY)
{

    EVP_PKEY* m_pPubkey;
    BIO* keyBio = BIO_new_mem_buf(&oPKEY[0], (int)oPKEY.size());
    m_pPubkey = d2i_PUBKEY_bio(keyBio, NULL);
    BIO_free(keyBio);

    if (NULL == m_pPubkey)
    {
        std::cout << "Error Public key is NULL" << std::endl;
        return false;
    }

    // check if ECDSA signature and then verify
    int nRes = 0;
    int type = EVP_PKEY_base_id(m_pPubkey);
    if (type == EVP_PKEY_EC)
    {
        EVP_MD_CTX* ctx = EVP_MD_CTX_create();

        nRes = EVP_DigestVerifyInit(ctx, NULL, EVP_sha1(), NULL, m_pPubkey);
        if (1 != nRes)
        {
            EVP_MD_CTX_cleanup(ctx);
            std::cout << "Error EVP_DigestVerifyInit" << std::endl;
            return false;
        }

        nRes = EVP_DigestVerifyUpdate(ctx, &oRND[0], oRND.size());
        if (1 != nRes)
        {
            EVP_MD_CTX_cleanup(ctx);
            std::cout << "Error EVP_DigestVerifyUpdate" << std::endl;
            return false;
        }

        nRes = EVP_DigestVerifyFinal(ctx, &oSIG[0], oSIG.size());
        EVP_MD_CTX_cleanup(ctx);
        if (nRes < 0)
        {
            std::cout << "Error EVP_DigestVerifyFinal failed" << std::endl;
            return false;
        }
        else if (nRes == 0)
        {
            std::cout << "Error EVP_DigestVerifyFinal: Signature could not be verified" << std::endl;
            return false;
        }

    }
    else
    {
        std::cout << "Not a ECDSA Signature" << std::endl;
        return false;
    }

    return nRes == 1;
}

EDIT: This is the error I get: error:0D07207B:lib(13):func(114):reason(123)

Since you're already using OpenSSL you can construct an ECDSA_SIG structure and encode it; see https://stackoverflow.com/questions/31390784/creating-a-der-formatted-ecdsa-signature-from-raw-r-and-s .

Or you can write your own DER encoder for this specific case which is fairly simple, although a general ASN.1 encoder is not:

// given int l is the curve-and-field size in octets with l<61
// (i.e. P-256 or P-384 is okay for this code but P-521 is not)
// and unsigned char plain [2*l] is the 'plain' signature
unsigned char * der = malloc(2*l+8); // worst case
int o = 2; // offset into 'der' (output)
int s = 0; while(s<l && plain[s]==0) s++; // skip leading zeros in R
int m = plain[s]&0x80 != 0; // need sign byte for R
der[o++]=2; der[o++]=l-s+m; if(m) der[o++]=0; memcpy(der+o, plain+s, l-s); o+=l-s;
s = l; while(s<l*2 && plain[s]==0) s++; // skip leading zeros in S
m = plain[s]&0x80 != 0; // need sign byte for S
der[o++]=2; der[o++]=l*2-s+m; if(m) der[o++]=0; memcpy(der+o, plain+s, l*2-s); o+=l*2-s;
der[0]=0x30; der[1]=o-2;
// use der for length o as the signature buffer
// when done free(der)
// or in C++ use new[] and delete[] if you or your style rules prefer

Edited 2019-07-30; original version didn't handle leading zeros in the fixed-length R,S, which are fairly rare but do happen sometimes.


Multiple instances of programs allowed in Windows Firewall I am new to Windows Firewall. While allowing a program through Windows Firewall, I found multiple entries present for Firefox and Java. Why is that?

(IME) Java requires firewall exceptions for both TCP and UDP (and one firewall rule can't do both) so that's always two. In addition you can easily have/use more than one java programfile if you:

use both java.exe for console mode and javaw.exe for GUI mode
use both 32-bit and 64-bit java on 64-bit Windows
use more than one major version (java 7 and java 8) and possibly with recent versions if you install new update(s) without replacing/removing earlier one(s)

Click the AdvancedSettings botton on ControlPanel / Firewall, or equivalently ControlPanel / AdministrativeTools / WindowsFirewall... or shortcut just run mmc wf.msc. Select InboundRules or OutboundRules as applicable (usually only Inbound as normal profiles implicitly allow programs Outbound), expand the Program column so you can see all of it, optionally drag columns around and/or click on the heading to sort, and you can more easily see the different programs.

Your two Firefox entries indicate the same executable in the entry name; it's conceivable the actual executables are different, and you should probably confirm, but the Mozilla people don't usually do silly things like that. But quite a few other properties of a firewall entry can differ, like protocol and address/port limitations, so scroll across and look for differences in any column(s) except Name.


For what malicious activity can one use a computer with a high-end GPU? I'm currently researching what malicious activities can one do with a computer containing a high-end GPU. So far the only uses I found were Bitcoin mining and password cracking. Are there any other possible malicious uses for such computers?

A high-end GPU makes it very easy to do any sort of computational process that can be highly parallelized, each individual process doesn't need a lot of memory, and requires similar operations to be done to differing starting input.

So if you have md5 hashes with salts that you want to find the password that goes with, its trivial; e.g., generate a simple scheme to feed the GPU billions of passwords per second to try simultaneously and compare to the hashes you have.  You could also do things like try constructing hash rainbow tables as well.

Another good candidate would be brute-forcing decryption of a file that's encrypted with a strong cipher.  A GPU could plausibly be used to parallelize the process of doing trial decryption under many candidate passphrases.

I wouldn't say bitcoin mining is malicious; its basically the intended method of generating currency (except a GPU makes it more efficient).

Off the top of my head could also use a GPU to better crack simple CAPTCHAs using computer vision techniques.


Router as MITM to steal data I was reading a blog post about ATM skimming and the following quote (at the end of the article) caught my eye:

  Ivanov allegedly used two devices — a router to steal the bank data of customers using Wi-Fi and ...

Isn't the network connection supposed to be secure? I've always believed that HTTPS (if they use https) would prevent MITM attacks. Also, at the very least, shouldn't the data be encrypted in some way to prevent or at least slow down eavesdroppers?

The quote is short, but I think the author is trying to say that the router wasn't about ATM skimming, and not even about the ATM itself. It was a MITM for customers who used WiFi (personal devices).

In this case, it was just a rogue AP that presented a fake certificate to users, and the users (or their poorly written apps) had to accept the fake certificate.


Dangerous to open a unix socket within www root? My web server is chrooted into /var/www, and its contents are available over the network.

One of my web applications needs access to a unix socket, and so that socket needs to be somewhere in /var/www to be accessible by the server.

Does it pose any security risk creating the socket in a web accessible directory?

Well, further analysis with more data may be needed, but, at first sight, it seems that the only problem you may have is a malicious user exploiting the program behind the socket, gains the same privileges as the program and may gain root access depending on the environment.

Apart from this I can't see any other problem. But consider making this exercise:

Has been the software properly tested and audited regarding security topics?
Can your program damage any other process if it gets hacked?
How much access do you concede an user if your program gets hacked?
Is there any critical information in the same user space?
Is there any other way to launch the program who attends the socket less risky? Is it worth?


Is there a cryptographic function that generates a reconizable visual pattern? I have to build a system that will ultimately print a pass allowing access to a building. The validation of this ticket will be done manually (it can also be automatic but that's not likely at this stage). There is the chance that the person checking does not have access to a computer to validate it.

The idea is to print some recognizable pattern for the day.

I started thinking about an hash, but that wouldn't work. So I thought of some symmetric cryptography where the key would generate different patterns. But that doesn't make much sense either.

The only request is that the person that checks the pattern can recognize it. This pattern would change in a daily or weekly basis.

I know these would be subject of replay attacks, but for now this would be enough.

I'm going to ignore the horrible usability issue in this answer and just focus on the title question here.

--

One idea is to generate a visual fingerprint like OpenSSH visual fingerprint. OpenSSH Visual fingerprints produce blotch of ASCII characters that are supposedly somewhat memorable can be quickly compared visually.

If you want to be slightly fancy, there's the Aestheticode. Aestheticodes like Penguin Barcode can be scanned, is distinctive and aesthetically pleasing, and is fairly easy to visually compare without a machine. Problem is that aestheticode are short and most aestheticode are generated manually; you'll need to be able to procedurally generate these images if you're going to do this everyday.


What makes VoIP more vulnerable than a "normal" phone line? NIST is deprecating VoIP SMS authentication.

I don't understand the decision.

What makes VoIP any more vulnerable than a traditional phone line? From the consumer side, I don't even know how to tell the difference! And I imagine if my service provider wants to intercept something, they could intercept either one (heck, traditional might even be easier). And if we're talking about "stringrays", well, again -- they can intercept the whole mobile connection.

What's the real issue? I just don't buy the explanation, but no one seems to be questioning it!

First off, I like the amount of passion you have for the subject!

Now for the answer:
VoIP is a digital way of sending voice communications using IP.
An example for this would be sending voice over the internet between two VoIP nodes.

Because VoIP uses the internet to communicate, the access to the nodes and to the servers handling the requests are at risk to the whole world. This means that if I scanned the internet and found a VoIP node and I found a vulnerability then I can use the node's OS for any malicious purposes (Example: using it as a bot in a DDoS attack, sniffing the traffic and there for listening to the calls and etc...).

On a traditional phone line the communication is done via a private closed off network that is wired to your house from a control box that is probably somewhere in your neighborhood (And that box is connected to another and so on until the main control system).
In order to hack that you would have to connect to this wired network. This requires physical access which already makes it harder to hack then a VoIP network.

There are many more small reasons and each have there own good and bad sides but in general the reason VoIP is more vulnerable is because it uses the internet or any other network to communicate which makes it vulnerable to all standard attacks. Either way, they are both pretty hackable each in their own way.

Note: Some service providers have already mixed together there control systems for the phone lines with the internet making it also vulnerable.


Possibility to sniff HTTPS traffic on devices without installing a certificate My goal is to sniff the HTTPS traffic of some digital devices (AppleTV, game consoles, etc.), and decrypt the HTTPS packets in my local network.

I cannot figure out a way by using some HTTPS debugging proxy tools like Charles or Fiddler, because they need to have a certificate installed on the device. I don't have access to the file system on the device, I cannot copy certificate. But I can set the proxy of the device to point to my laptop or using my laptop's hotspot.

The entire point of SSL is its resistance to eavesdropping by man-in-the-middle attacks like the one you're proposing. If you cannot make the client device trust your self-signed certificate, then your only options are:

Intercept an initial HTTP request and never let the communication be upgraded to HTTPS (but this will not work if the if the client explicitly goes to an https://... URL)
Pretend to be the server with your own self-signed certificate, and hope that the system making the request naively accepts a self-signed certificate (which is the decision-making equivalent to a user who ignores the browser's stern warnings about a possible MITM attack in progress)
Check for susceptibility to known past attacks on SSL (Heartbleed, BEAST, etc.). Note that this option is most likely to be illegal, since it may require an attack on the server (which you don't own) rather than an attack on the client (which you do possibly do own)

If you have many trillions of dollars available to you, you may have a few other options:

Successfully compromise a worldwide-trusted certificate authority and use their secret signing key to produce forged certificates for your own keypair
Purchase or discover a zero-day security vulnerability in a Web client, Web server, or (most preferably) SSL/TLS library used by the client or server
Discover a crippling weakness in some underlying cryptographic primitive used by SSL (for example, completely breaking AES might do nicely)
Spend trillions of dollars on computer hardware to perform brute force attacks on intercepted encrypted communications

If you have unlimited physical access to the device, almost certainly an attack on the device's own trusted certificate store would be easier than an attack on SSL (though it may also be far from easy).


Is is possible to shuffle an AES ciphertext without owning the key for it? I would like to know if it is mathematically feasible to change an AES(CBC) ciphertext and IV without owning the key, so that the ciphertext would look totally different while still decrypting to the same original message?

Just a random crazy thought that popped up in my mind, not even sure if it makes any sense...

No, this is not possible. If you change a single bit in a block that is put through the cipher then all bits change with a certainty of 50% (each) due to the avalanche effect. So even though only one bit will be changed in the next block, the current block will still "completely" change.

Differently said, AES is a block cipher and a keyed block cipher is a pseudo random permutation. If you change even a single bit you get another mapping to an entirely different value for that block. Only one block leads to the same plaintext block, there is no redundancy. Because of the pseudo-randomness you get an entirely different plaintext block, no matter how many bits you change.

Some padding modes are redundant though (the most common one, PKCS#7 compatible padding isn't). So there is a chance that an attacker can change the last few bytes of the plaintext. For instance, you'd have a ~ 1 / 65536 chance that you'd create an ISO 10126 padded message that is identical after unpadding (the first byte identical and the last byte indicating 15 padding bytes).

Obviously using an authentication tag / message authentication code (MAC) over the ciphertext should be considered to be secure against any of these attacks.


What are the technical reasons for Tails requiring 2 USB sticks to install? In the Tails documentation there is something I find strange. They say that creating a live USB stick that will contain the Tails OS must be done in a two step process. This is true of most platforms - generic GNU/Linux, Mac, and Windows. All of which state something similar to the following.

  As it is currently impossible to install Tails directly from Linux, this scenario requires creating an intermediary Tails on a second USB stick. This intermediary Tails lacks important security and usability features.

However, this is not the case for Debian based GNU/Linux systems which instead provide the tails-installer-launcher program that can do it in one shot.

The install documentation states the following.

  On this intermediary Tails you won't benefit from important features like automatic security upgrades or the possibility to store some of your documents and configuration in an encrypted storage.

They mention that persistent storage is one of the features that is disabled on the first USB. Also, I don't plan on using networking or persistent storage.  The first USB seems to work perfectly for my use case - key generation. It has a terminal and supports mounting other flash drives! This leads me to the following three questions.

On a non Debian based system, what are the technical reasons that this two stage process is required?
What other features are missing from the first USB?
Is there any reason not to use the first live USB stick in my use case?

The primary benefit of the two USB drives setup is that it provides a secure environment (the first Tails USB instance) to generate the encryption key for persistent storage: a non-Tails OS could unintentionally leak the encryption key, thus causing the persistent storage encryption to be comprised.

If you don't require encrypted persistent storage, then the first Tails USB drive should be acceptable as-is.

The tails-installer-launcher application available on several Linux distributions such as Debian does not require a second USB because it creates two partitions on the single USB drive: the first partition is used to house the Tails OS, while the second partition is used to house the persistent storage. The installer application only installs the Tails OS to the first partition, so the encrypted persistent storage is still only setup through the secure environment of Tails after you boot into it.

Theoretically, you do not require two USB drives to install the Tails OS with encrypted persistent storage -- even without the tails-installer-launcher application. You can perform the operation of the installer manually by simply partitioning your single USB drive into 2 partitions, installing Tails OS to the first partition, then later setting up the encrypted persistent storage from within Tails OS to the second partition.

See also

  Can I Use Tails in One Stick of USB? ( 8Gb) instead of 2 (4Gb) Stick


How do I instantly disconnect from my ISP during an exploit or suspicious activity? When I was using "Zone Alarm Security" under Windows 98 SE, there was a toggle link feature under Zone Alarm, whereby I could instantly sever connectivity to the web, while a suspicious exploit was running - why isn't that feature available under all security packages like my current security product "McAfee® SaaS Endpoint Protection"? Or is it a proprietary feature?  If it's worth having, how do I search for it by its generic feature name?

Although it looks like a nice feature to have, such kill-switch is not actually useful for common users.

Most of the times you won't even notice the exploit happening and even if you detected something strange, it is too late to stop it from running. Let's if you have such a kill-switch, how can you know for sure you stopped it in time? So, such feature can give a false sense of security.

A more drastic version of this is cutting the power to your computer and in certain cases it does makes sense. A simple example I can think of is being a bad guy and quickly cutting power to your computer when the police storm in. This prevents forensics being performed on your PC. There are tools and even hardware devices for this, for example https://github.com/hephaest0s/usbkill

You could also script something that performs the Zone Alarm feature you mention.
Right click windows desktop, New, Shortcut to create a windows shortcut then paste this

%comspec% /k netsh interface set interface name="Local Area Connection" admin=disabled

Then go into the properties of that shortcut and chose a shortcut key. You can also look for similar tutorials for other operating systems.

But remember, pulling out in time is not a good infosec practice :)


Why do some websites and programs restrict password characteristics? There are some websites and even programs that I use that have ridiculous password restrictions. Lots of forums for instance restrict passwords to ~32 characters. Others enforce a restricted charset.

What would cause a developer to put in such restrictions? As long as you do the initial hashing of a password on the client, there is no load on the server for having to calculate the hash of enormous auto-generated passwords. There seems to be no benefit of using such restrictions

I think the reason is the same as for any other input validation; to make sure it doesn't cause any problems during processing and storage. Now, for passwords this is of course completely misguided since they should be hashed and therefore neither stored nor really processed in cleartext.

I'd take any such limitations as an indication that the developers don't know what they're doing securitywise, and are probably going to store the password in cleartext. Stay away.


Reference implementation of C# password hashing and verification Does anyone have a reference implementation (ideally 3rd party certified, or government approved) way one-way hash a password for C# and or Java?

Ideally,I'd like to see something that includes a "salt and pepper" technique as mentioned here as well as any other modern security technique for validation that might be applicable.

The content I want to protect is information the user can remember, such as a password, or the answer to a challenge question.

If you don't have a complete code sample, a general description of which algorithm you would choose, and example methods of salting and peppering would be helpful.

Given your new "government approved" requirement, my guess is that one good solution would be PBKDF2 from RFC 2898.  It is implemented for .NET in Rfc2898DeriveBytes Class (System.Security.Cryptography).  You presumably want to substitute SHA-256 for SHA-1 in there.

I also just ran across the Fairly Secure Hashed Password: fshp which is like PBKDF1 but with SHA-256 by default.  It supports a variable number of iterations, defaulting to 4096.  It uses 64 bit salts.  They have implementations there for .NET, Python, Ruby, Perl, PHP5, Java and JavaScript.

As described and discussed at .net impl of bcrypt - Stack Overflow, it seems that for .NET/CLR another good option (though not NIST-approved) is BCrypt.net:

Derek Slager: BCrypt.net - Strong Password Hashing for .NET and Mono

and for Java a good option is

jBCrypt - strong password hashing for Java

I guess neither seems to have the "pepper" concept, or the space complexity of scrypt.


Questions on the variations of RSA keys I've built a simple application that reads in an RSA key, checks the header and starts identifying properties of the RSA key to make sure it is valid (Using child_process in express to run

$ openssl rsa -inform PEM -in ~/.ssh/id_rsa -check

So off of a rest call from my local server, I can check the headers, take a guess that it is PEM base64 encoded, dump out to the terminal, verify it is consistent with the proper structure of a key.

When I started seeing there were many ways that the RSA key could come in, whether PEM, DER, NET, I was hoping to get guidance from some experts on what the most likely form that you have received keys in and ways that can be used to verify their integrity or perhaps their structure.

I would be considering keys for dates after 2030 ultimately (So if a 2048 bit key came through I may suggest that the key be made 4096 bits as a stronger alternative).

TL;DR - Of all the forms that RSA keys are typically handled, what are the primary formats that are used, and what are some potential validation approaches.

Common forms are PKCS#12/PFX (an encrypted key pair, possibly with additional certificates) and PEM or DER form PKCS#1 as used by OpenSSL and OpenSSH (that's what id_rsa will be). PEM is a base64 version of the DER binary (ASN.1) form with identifying header/footer, it's not otherwise a distinct form, except that it allows encryption where as PKCS#1 DER does not.

If the key is encrypted (PEM form only) it will contain extra header lines to indicate the encryption and IV, e.g.:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,AA171F6005B3DD31
...

PKCS#1 is RSA only, PKCS#8 is a more general purpose "container" for keys, it too is ASN.1 but it explicitly indicates the type of data within, e.g. (see offset 9, line 4):

$ openssl pkcs8 -inform PEM -in ~/.ssh/id_rsa -topk8 -nocrypt \
  -outform DER -out id_rsa.p8
$ dumpasn1 -tilda id_rsa.p8
 0 1213: SEQUENCE {
 4    1: . INTEGER 0
 7   13: . SEQUENCE {
 9    9: . . OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
       : . . . (PKCS #1)
20    0: . . NULL
       : . . }
22 1191: . OCTET STRING, encapsulates {
26 1187: . . SEQUENCE {
30    1: . . . INTEGER 0
33  257: . . . INTEGER
       : . . . . 00 B1 1F 09 61 C1 A1 09    ....a...
 ...

(I'm using dumpasn1 here instead of openssl asn1parse, embarrassingly, the latter fails to parse the pkcs8 output correctly.)

OpenSSH doesn't (AFAIK) support PKCS#8 other than for import/export, they have their own format. That format is used for newer key types only (Ed25519) but is planned to be the default in future.

There are a few things you can usefully check:

identifying header/footer line in PEM, and base64 encoding validity
valid ASN.1 format (mostly limited to type and length checks)
numeric integrity of RSA parameters

You might also ruminate on the value of the public exponent (too large can cause interoperability problems, too small is implicated with security problems for some applications).

The openssl rsa ... -check command checks 1 (PEM only) and 2 implicitly, and 3 explicitly. See the OpenSSL API RSA_check_key() documentation for details of the checks. That should be sufficient checking for most, I think.

An RSA private key file (almost always) contains more than just the private key exponent, it also contains the public key parameters and some intermediate values for optimisation (via the CRT), those values can be checked for consistency or primacy. The "key size" is the length of the ''modulus'', with the caveat that there will (usually) be a leading 00 byte to ensure it's interpreted as a positive integer (ASN.1 signed-ness issue).

For a different view you could also do:

openssl asn1parse -inform PEM -in ~/.ssh/id_rsa

(but that does not check the RSA parameters)


Verifying integrity of text files While I was away from my home I needed to do some work on a java program so I booted a friends netbook(windows 8) I had with me and finished most of the works I needed to do there. Tho when I returned home I realized that the netbook didn't have antivirus, firewall and nothing security wise turned on which made me worry.

I now want to transfer these files(.java) to my main ubuntu desktop system but I am worried that something might have hidden itself inside the files header and other places, is there a way to verify the integrity of the files or a way to safely transfer the code they contain without accidentally transferring anything malicious and since these files are actually going to be compiles and put on production I'm double worried about that.

Because mythical imagined malware that might subtly modify your unique proprietary source code is very unlikely to exist, there are a couple of slightly more real threats you could check for.

If your friend's computer was compromised by a human hacker, the hacker could have copied your code to his computer, studied it, changed it, and uploaded his changes back to your friend's computer.  (This presumes an attacker who knows who you are, exactly what you are working on, how to find it, and has the means and motivation to carry out such an attack.)  As the developers, you are the only people who would be in a position to know this, and a simple code review should easily satisfy you that this didn't take place.

Another remote possibility might be that this mythical malware hid something in an alternate data stream inside your code.  While this could theoretically be possible, there is nothing on your computer that would automatically extract the payload from the ADS and execute it, so it won't simply infect your computer to copy it in.   If it's a known virus, your own computer's anti-virus would detect it.  Even if the ADS contained a virus, it still wouldn't have a way to execute to compromise your system.  If you want to go with full-blown movie-plot paranoia, this mythical malware could have planted some kind of "illegal" data in an ADS inside your files, as part of a complicated blackmail scheme.

Frankly, the only plausible scenario of risk is that the media containing your files could have been infected by this mythical malware.  Are the files now on a flash drive?  Copy them off the flash drive using a Linux machine (which will be immune to Windows executable viruses and autoruns kinds of attacks.)  Don't copy any files other than the valuable source files.  Java source code files are fine, but PDFs, JPGs, EXEs, TTFs, DOCs, and everything else is not. After you have saved the needed files, format the flash drive.  You can then use a tool like sdelete with the -z option to overwrite the bits in the drive, then sell the flash drive on eBay.


OS with encrypted RAM? Are there any applications, JIT frameworks or operating systems that focus on encrypted virtual memory, or perhaps virtual machines that do something similar? I know there are processors (albeit old, slow and weak) that allow for systems that are entirely encrypted, but I've yet to see any OS or application come up with a decent solution for x86 or one of its descendants.

I understand that L1/L2/L3 caches, DMA buffers, etc. cannot be encrypted without hardware support, but surely at least certain kernel structures and most of the user-mode memory (i.e. stuff allocated by processes) could be encrypted given support at compile-time?

I also would like to know if it would be theoretically possible (whilst obviously difficult) to translate an existing JIT compiler (e.g. .NET CLR) that produces code that automatically encrypts its user-mode memory.

Any sort of existing solutions along these lines would be a lot of fun to take a look at.

I also would like to know if it would be theoretically possible (whilst obviously difficult) to translate an existing JIT compiler (e.g. .NET CLR) that produces code that automatically encrypts its user-mode memory.

This might be quite difficult for the OS to do on behalf of a program. The reason for this is that the virtual pages allocated by the operating system are in fact controlled by the CPU - the OS instructs the CPU as to what it wants in terms of storage areas and the CPU then computes the offsets on that basis for each program and applies the result directly. Have a read up on the MMU and Paging on x86.

In short, when your program makes the computation mov eax, [edi+something], the MMU/paging handles the address translation and issues a page fault when the page is not found. That allows you to then load the page out of storage, should you need to.

So the memory access doesn't go through the kernel per se and as such can't be hooked and processed as a file read or write can (your read and writes are translated through the appropriate system calls into the appropriate file system structure. As such, the OS sees the data as it passes through. You don't need a system call to write to RAM. You could make one, but it would only work for programs that call it and so not most programs).

However, that doesn't mean to say a JIT process couldn't do this on behalf of an application, or the application itself couldn't keep data encrypted until it needs to load it into registers, decrypting it as it passes over the data.

In that case, you're into the issue SteveS covers well - you have a key storage problem. The key itself must also be in RAM somewhere. This is a turtles all the way down problem - fundamentally it's impossible to keep that key "secure".

Finally, since being able to read another application's RAM requires supervisor mode access to the CPU (i.e. kernel space) you probably have bigger issues if your concern is software interception. If your concern is hardware, I think physical security might be a better way of mitigating the risk.

Edit I had a look for papers. Here's one called CryptKeeper. Their technique is to have a large encrypted "RAM disk" as the swap file and swap all their pages out to that when not used:

  We mitigate this vulnerability with Cryptkeeper (CK), a
  software-encrypted virtual memory manager. Traditional pro-
  cessors cannot operate on encrypted data, so CK segments
  RAM into a smaller working set called the Clear, and a
  larger encrypted RAM device called the Crypt. As the working
  space fills, pages are automatically swapped into the encrypted
  portion of memory, and are decrypted on demand.

Apparently the performance isn't too bad, but I don't think there are any implementations of it yet.

Edit 2 So it turns out CryptKeeper and the OpenBSD Swap Encryption mechanisms work on a very similar level; it does not actually encrypt physical memory but uses physical memory as a swap structure, forcing page faults and encrypting/decrypting data in resolution.

EDIT from question author, December 2018: AMD now supports the SME instruction set extension which allows for hardware encryption of RAM pages, plus TSME for full-memory encryption, and SEV for use with encrypted memory in virtualisation. This appears to enable full-system memory encryption on modern AMD64 platforms.


What alternatives are there to the existing Certificate Authority system for SSL? Whilst the current CA system works very well for a lot of people, it does put a lot of power into individual CAs' hands, and makes a CA hack potentially devastating for customers and business. What alternatives are there to certificate authorities, and what are the challenges in switching to such systems? I've seen proposals for a variety of distributed P2P-like systems, but nothing has ever come of them.

"Alternatives" depend on whether you want something which may work in the future, or something which works right now, with existing browsers.

Right now, Web browsers expect that servers send X.509 certificates, and then they validate them against the set of root CA integrated in the browser (or operating system). This means that if you want something that works without any extra software installation, then all you can do is alter the set of root CA (your trust anchors). You can:

Remove some of the CA (it has been said that you can remove most of them without really impacting your browsing experience, because not all trusted CA are equally active).
Add new trust anchors. Note that a trust anchor is "a name-and-public-key that you trust a priori". Trust anchors are usually encoded as certificates (because the format is convenient for that), and traditionally are self-signed (mostly because in a certificate, there is a field for a "signature" which cannot be left empty). But you can trust certificates which are not self-signed; you can even trust end-entity certificates (i.e. you trust the specific certificate of a given SSL server: this is called direct trust). With direct trust, you manually manage what you trust with very fine granularity. Note that, with direct trust, you lose the benefits of revocation (a directly trusted certificate cannot be untrusted except by a manual intervention on your part, whereas revocation is about propagating mistrust information automatically).

(One can note that the direct trust model is exactly what SSH follows, and it works well in the usage context of SSH.)

In the future, there could be other models. There are several proposals, some being backed by existing software add-ons. To my knowledge, none has reached the "generally usable" level yet. There are, for instance:

DNSSEC and DANE: DNSSEC is about mapping a PKI on the DNS system, primarily so as to authenticate the data returned by the DNS itself, but this can be leverage to distribute SSL server keys (what DANE is about). This is still a hierarchical PKI, with a limited set of trust anchors; the difference with the existing set of root CA is mostly a change of players: the new set of gatekeepers would be smaller, and only partially overlaps with existing root CA. Also, DNSSEC/DANE binds the process of authenticating Web servers to the DNS infrastructure and actors, and it is not clear whether this is good or bad.
A Web of Trust like OpenPGP does. The WoT model relies on graph superconnectivity. To keep things simple, with a WoT everybody is a CA, and each actor is its own and unique root CA; to cope with gullible or downright malicious "CA", WoT users (i.e. Web browsers) accept a target certificate as valid only if they can verify it through many paths which go through distinct CA and all concur to posit the target server key. The decentralized nature of WoT is very popular among people who distrust governments and anything which looks like an administration. However, WoT security is very dependent on critical mass: it will not give you much until sufficiently many people collaborate. See the Monkeysphere project for an implementation (with browser add-ons)(I don't know much about the project quality, though).
Convergence is a descendant of the Perspectives project. If you get down to it, Convergence relies on Hope and Laziness. What Convergence assumes is that wannabe attackers will find it too hard / expensive / tiresome to actively impersonate a given server with a fake certificate for both a long time and in the view of many people. Namely, practical Man-in-the-Middle attacks are either close to the victim (e.g. users of a given WiFi hotspot), in which case they impact only very few people, or close to the server, which requires something wide-scale (like heavy DNS poisoning) which will be quite conspicuous, hence will not last long. Under this model, Convergence is a nice, relatively inexpensive solution, with only minimal centralization (it still requires notaries, and de facto centralization can be expected, but not as thorough as the current set of root CA).

An important point is that the current system "works". Actual attacks which target the PKI are very rare (much publicized, but still rare). The actual system with roots CA is sufficiently hard to break that attackers find it easier to bypass it through some other ways (foremost of which being abusing the credulity of human users). As such, there is little incentive for replacing it with another system which, at best, will do the same. So, while the alternate proposals have some merit (mostly in financial and political terms), I deem it relatively improbable that any of them dislodges the existing root CA in the near future, for "the Web" as we know it.

For closed architectures which are not the Web, and where you control both client and server, you can use whatever system you want, but closed architecture are precisely the situation where hierarchical PKI work very well.


Any reason why SHA-3 isn't yet present in GnuPG? I was curious about setting SHA-3 as the preferred hashing algorithm for GPG but that looks like it is not yet supported and the documentation states this:

SHA-3: SHA-3 is a completely new hash algorithm that makes a clean
break with the previous SHAs. It is believed to be safe, with no
warnings about its usage. It hasn’t yet been officially introduced
into the OpenPGP standard, and for that reason GnuPG doesn’t support
it. However, SHA-3 will probably be incorporated into the spec, and
GnuPG will support it as soon as it does.

What does this mean: "...and GnuPG will support it as soon as it does"?
Are there any development plans for supporting SHA3 or BLAKE?

Are there any development plans for supporting SHA3 or BLAKE?

These algorithms are already included in the Libgcrypt library. It is only a matter of getting them incorporated into the OpenPGP standard for GnuPG to make use of them.
The GnuPG developers are working towards getting the OpenPGP Message Format updated from RFC 4880. The current work-in-progress for the new standard can be seen here. SHA3-256 and SHA3-512 are included in the draft, but not BLAKE.


How can I control the content of the HTTP HOST header in requests issued from my website? Is anyone familiar with a way in which I can post a link on my website, that when accessed will cause users to issue an HTTP request to a 3rd party site with custom content in the HOST header (different from the actual host/domain to which the request is sent to on the IP level)? A short example to clarify my intention - a request sent to www.example.com:

GET / HTTP/1.1
Host: $$CUSTOM_PAYLOAD$$ (not www.example.com)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

I have seen several discussions on the subject of issuing requests with CUSTOM headers, but this is not the case as the header is a legitimate header accepted by the recieving party.
In addition, I have seen various publications on attacks (mainly reflected XSS) that rely on malicious input in the HOST header, although I am not quite sure how they can be executed.

If you want the user to issue the request, then it is not possible to do this with an XMLHttpRequest:

Terminate these steps if header is a case-insensitive match for one of the following headers:
Accept-Charset
Accept-Encoding
Access-Control-Request-Headers
Access-Control-Request-Method
Connection
Content-Length
Cookie
Cookie2
Date
DNT
Expect
Host
Keep-Alive
Origin
Referer
TE
Trailer
Transfer-Encoding
Upgrade
User-Agent
Via

However, this did used to be possible in Flash due to a bug in versions 7 and 8 when used in combination with IE:

In IE, it is also possible to overwrite some more sensitive
headers (e.g. Host and Content-Length) by appending colon to the
header name (this technique was described in [3] in the context
of XmlHttpRequest):

req.addRequestHeader("Host:","foobar.site");


What are the methods to find hooked functions and APIs? Many malware executables use hooking to be invisible. I am familiar with some hooking methods, I'm not sure what methods exist for detecting them. Is there a way to tell when a function call has been modified to perform other tasks through hooks?

Hooks are implemented in a whole bunch of ways:

Modifying legitimate jump instructions to point at hooks instead of the normal code.
User call table (IAT) hooking - modifying the addresses of user-mode APIs in a process.
Kernel call table hooking (e.g. SSDT / GDT ) - replacing a call table pointer with the address of your hook.
WndProc hooks (e.g. PeekMessage) - hooking onto window notification messages.
Legitimate callbacks like PsSetCreateProcessNotifyRoutine.

I'm guessing you're most interested in the first two types.

Jump hooks can be created in a near-infinite number of ways. This makes it almost impossible to write a tool to identify the hooks. However, you can use integrity checking tricks, e.g. comparing code in the binary file (e.g. exe or dll) to the code in memory. You could also hook WriteProcessMemory and other such APIs to detect modification of process memory, though this only works against user-mode attacks.

IAT hooks are a little easier to check for. Take a snapshot of the IAT of a process when it starts (e.g. from the static binary) and compare the in-memory IAT to the real addresses of the functions that should be in there. For example, if you know IAT entry 4 points to user32.MessageBoxA, you can use GetProcAddress to find the real address of that function and compare the address in the IAT to that. If they don't match, you know it's been hooked.

For further reading, there's a great paper on the subject, and I highly recommend reading "The Rootkit Arsenal" by Bill Blunden.


Why are websites migrating to HTTPS? HTTPS is the secure version of HTTP, which adds encryption, authentication and integration to the HTTP protocol.
It is clear why banking websites and the websites with sensitive information are running using HTTPS, but why will normal websites run over HTTPS? What the benefits the site owner will get?

Saying that only critical applications need HTTPS is like saying that only those e-mails containing actual secrets need to remain private.

Privacy on the Internet is a bigger picture. If most of the websites you're visiting use HTTPS, it will be significantly more difficult for an eavesdropper to synthesize a profile of you and your habits. Also, the fact that you don't consider a particular website security-relevant might not apply to someone else. Someone in an oppressive regime might be at risk just for researching a particular news topic and will benefit from any news blog that serves its content over TLS.

Privacy aside, every download over HTTP gives a man-in-the-middle the opportunity to inject their own malicious content. A seemingly harmless download of a Word or PDF document could be silently replaced by malware. Then it won't matter that you downloaded it from a small site that seemed too unimportant to use HTTPS.

Especially with free certificate providers like Let's Encrypt, rolling out HTTPS even on small websites should be a no-brainer. You're contributing to a safer Internet where encryption hopefully soon becomes the norm.


Keyboard "eavesdropping" just got way easier, thanks to electromagnetic emanations Just found this article which basically suggests that electromagnetic emanations can be used to eavesdrop on what you're typing.

http://www.engadget.com/2008/10/20/keyboard-eavesdropping-just-got-way-easier-thanks-to-electrom/

My question is, is it possible to secure yourself from such attacks?

There are electronic countermeasures you could use to foil this kind of attack, like tempest hardening, or sending out jamming signals on the frequencies that your keyboard may emanate. You could also use a soft keyboard on your screen, although screens are also vulnerable to that same kind of attack.

In reality this isn't something to worry about. It is a very sophisticated attack so would have a very limited number of attackers who could carry it out. Anyone sophisticated enough to be able to carry out this attack would have many other more reliable and easier ways to get the same data, like breaking into your place and installing a physical key logger, or using a zero day vulnerability to crack your system and install stealth malware.


Prevent apps from having full access to user files Applications should not have access to data of other applications or to user's private data unless user allows them. Isn't this an obvious need?
But every program we launch has full access to our $HOME dir, to our mic and cam. Most users will not even notice if (for example) Skype start sending somewhere their private files or streaming sound from their mic.

I'm looking for ways to fix this. Feel free to suggest anything even if your method implies writing SELinux policies, LSM modules, kernel patches, switching to another UNIX-like OS.

Here is some ideas I had and reasons I rejected them:

We create new unix users for every untrusted app. We use SUID bit to make that app always run as it's user. Bad. Because we need to blacklist every app we don't trust and every new app we install. Tons of work, easy to miss something. Also binaries may lose SUID flag when we upgrade/reinstall app. In addition, there is problem with child processes: in theory, apps that don't have some permission, can use other app to achieve their goal. And if we don't use SUID, it will be hard to remember that we need to use "su" to start every untrusted app.
We use SELinux domain transition to confine untrusted apps. Also bad. Same problem as with #1. We need to write/update/inject SELinux policies for every app we don't trust. I want apps to have no special access by default, not full access.
We create new "trusted" unix users for trusted apps. We can use groups to implement various categories of private data: photos, notes etc. But we can't use SUID and we need manually switch to that user before starting app (with password). Problem of this option is child processes. We can't allow all child processes of trusted program to be trusted (if we open media file in trusted file manager, we don't want media player to inherit trusted status of file manager). But we also can't allow all child processes to drop their permissions to default. Also bad!
We use SELinux to implement "trusted" domains for every trusted app. We can't use automatic domain transition in this case. So we need to switch domain with password. This option is slightly better than #3 because we can forbid launching untrusted apps in such trusted domains. But still bad and uncomfortable.
If we think more, we are starting to see that we can't bind permissions to executible binaries at all. For example, Python interpreter may need different permissions depending on script it runs. So we can forget about options #1 and #2.
We can make our own LSM module (like SELinux). But how it is supposed to work? Not sure I have ideas. Interactive mode? Asking user's permission every time some process attempts to read private files? Or should we take some ideas from "lomac" (low watermark) model? Say, reading untrusted data makes environment tainted and blocks it from reading private data.
Userspace daemon + LD_PRELOAD library? In this case, apps don't have access to private files by default, but they can contact privileged daemon and ask it to open such files and pass file descriptor. This is doable and will look like old "interactive firewalls" for Windows.

More ideas?
Please tell me you know ready-made solution :)

UPDATE

I started to develop my own LSM (SELinux replacement). It seems like no one here is interested. But, just in case, you can find me here:

https://gitlab.com/mogryph/chariot

or here:

knight@mail.ua

Applications should not have access to data of other applications or to user's private data unless user allows them. Isn't this an obvious need?

No, this is not obvious. Traditionally software installed on the system was considered trusted, i.e. it was not expected that users just go to the internet and download some possible harmful application. It was also not expected that users run insecure software which might interact badly with some remote site and thus give a remote attacker access to local data.

Therefore the security boundary in UNIX (and other OS) is by design the user and not the application. In fact, there is not even a concept of an application as you would like to have - complex applications (like Office) are actually made up of several binaries, libraries, config files etc.

I think that this design is still valid in many use cases, i.e. cases where the systems does not get changed much in the first place or where only trusted software gets installed. But there are also now cases where users actually install software from potentially untrusted sources or install potentially insecure software and expect this software to not do much harm. In these cases the original paradigm of using only the user as a security boundary is not sufficient.

There are OS designed with a different paradigm, i.e. where it is common that users download possible malicious application from the internet and want to restrict access to private data. For example in Android each application is essentially installed as its own user and thus the user boundary is used to restrict access to data generated by another application (this is slightly simplified on how it works).

Thus, if you consider applications untrusted by default you might better run an OS which is designed around this paradigm from start instead of trying to modify an OS which was designed with a different paradigm. As you realized yourself - any attempts to apply the concepts of untrusted applications to a system designed around trusted applications are clumsy and inconvenient to use.


Why doesn't form based authentication use digest instead of plain text In form based authentication the credentials are sent as such within the message, whereas in digest based authentication a digest of credentials, domain name and a random challenge is sent instead. Form based authentication requires a secure channel (https) by nature.

Why doesn't the form based authentication on web browsers use the digest scheme instead? Or is it so the digest challenge wouldn't provide any additional security over the form based authentication which requires TLS anyway?

Plus with the digest based authentication plain text password has to be stored in the server side repository instead of hashes. Is this the reason why (encrypted) plain text credentials are favored over the digest on web browsers? In which context would the digest based scheme actually be more secure than plain text over a secure channel?

is it so the digest challenge wouldn't provide any additional security over the form based authentication?

It's actually the other way around: HTTP digest auth requires the server to store all passwords in it's database in plaintext or weakly hashed (e.g. MD5), because it needs to be able to calculate a digest on them. With Basic auth it's possible to store passwords in strongly hashed form (e.g. scrypt), so Basic auth is more secure (in the presence of TLS of course).

  Why doesn't the form based authentication on web browsers use the digest scheme instead?

Form-based authentication isn't really a standard, it's just an approach in which the user is typically presented with a username and password HTML form fields and a Submit button, which triggers the submission of form data to the server via an HTTP POST. That's how HTML forms normally work.

However, you're free to augment this process any way you want, since it's possible to intercept button clicks in JavaScript and completely bypass the form submission. For example, you can implement digest-based authentication via Ajax (e.g. digest-ajax), as well as client-side PBKDF2, bcrypt, scrypt, or really anything else.

  In which context would the digest based scheme actually be more secure than plain text over a secure channel?

It's more secure when for example using a proxy, because the proxy gets to see a digest instead of a plaintext password, thus making it possible to potentially even use a public proxy.


How could one determine if a web page is vulnerable? Suppose that we have a web page. This page could be vulnerable to any attack such as SQLI. By looking the HTML code of the page, we can find some input elements that could be used by attackers to exploit vulnerabilities.

So we can guess that pages which have more input elements (for example), might be more vulnerable. I mean these pages might be more risky. So I want to conclude that these pages are more important for security scanners, and testing these pages may result in finding more vulnerabilities.

So one of the factors to decide that a web page is more important (in security manner) than the other page, is the number of input elements in the page. Another factor may be number of parameters we could pass to the page URL.

What are the other factors that makes a page important (i.e. make it risky)? How could I find that a web page (include HTML, javascript, css, etc) is vulnerable or not? (note that I can't exploit any vulnerability, and I should decide without exploiting any vulnerability).

The short answer is that I don't believe you can. One input field on one page may be far more important than 100 on another for example. The issue is that you cannot assess risk without access to more information. Risk is calculated by the ease and likelihood of a vulnerability being exploited multiplied by the damage that would be inflicted by its exploitation. You can't know this, or accurately guess this, without knowing more which might be internal code/architecture review or full testing.

That's why the saying we hear very often is so important "the attacker has to be lucky only once, you (the owner) have to be luck all the time" - so there may be one very small and innocent looking issue that once exploited gives the keys to the castle to the attacker.

It's also why all of the promoted pen tests/audit processes never include the advice "have a quick look and guess at what might be vulnerable and try that first"...

I'd advise against setting focus by guessing, you won't be 'lucky' much of the time


Random persistent Gmail password requests from Google I am trying to figure out something for my father in law. This persistent popup keeps interrupting anything anyone is doing on his desktop by requesting he put in his password. I told him not to. It seems odd that Google would be so intrusive and I also can't highlight or click any of the area the arrow points to, also odd.  It seems like it may be a phishing for password thing but I might be wrong. I'm using Teamviewer right now and I can't see the end of the http so that also seems strange.  Any help would be greatly appreciated !  thanks in advance, Claire

Based on what you provided we can see that the Thunderbird icon is active.

If it was configured to synchronise with Gmail account, and the authorisation was never performed or revoked, the connection is refused by Gmail service and Thunderbird requests an OAuth authorisation.

If the above is true, there's no indication this authorisation request is illegitimate.

If Thunderbird is running constantly or checking the emails periodically, the message may appear on each connection attempt.

Because the authorisation is performed within an embedded browser session within Thunderbird, it doesn't behave like a regular browser, where you can check the certificate by clicking on the padlock icon.


Ensure that a file can only be decrypted after a specific date Are there any cryptographic schemes/protocols that would allow me to encrypt a file, make it publicly available, but ensure that it can only be decrypted after specific date?

I assume it would be almost impossible without a trusted authority (notary). Or is there some way?

I was inspired by the idea of "secure triggers", which is a scheme to decrypt data after a specific event has happened. But this "trigger event" is only known to the author.

In contrast, I am interested in a cryptographic scheme that would enable decryption of data at (or after) a specific date which is publicly known.

Time is relative. Cryptography lives in the ethereal world of abstract computing machines: there are machines that can do operations. Bigger machines can do operations faster. There is no clock that you can enforce; physical time has no meaning. In other words, if an attacker wants to get your file earlier, he just has to buy a faster computer.

Now one can still make an effort. You may be interested in time-lock puzzles. The idea is to be able to make a problem instance that is easy to build but expensive to open, where the cost is configurable. The solution found by Rivest, Shamir and Wagner (to my knowledge, this is the only practical time-lock puzzle known so far) works like this:

Generate a random RSA modulus n = pq where p and q are big primes (and also p = 3 mod 4, and q = 3 mod 4).
Generate a random x modulo n.
For some integer w, define e = 2w, and compute y = xe mod n.
Hash y with some hash function, yielding a string K that you use as key to encrypt the file you want to time-lock.
Publish x, n, w and the encrypted file. Discard p, q, y and K.

The tricky point is that computing y, in all generality, has a cost which is proportional to w: it is a succession of w modular squarings. If w is in the billions or more range, then this is going to be expensive. However, when the p and q factors are known, then one can compute e modulo p-1 and q-1, which will be a lot shorter, and the computation of y can be performed within a few milliseconds.

Of course this does not guarantee a release at a specific date; rather, it guarantees a minimum effort to unlock the puzzle. Conversion between effort and date depends on how hard attackers try...

The time-lock puzzle expressed above has some nice characteristics, in particular being impervious to parallelism. If you try to break one such puzzle and you have two computers, you won't get faster than what you could do with a single computer.

In a somewhat similar context, this time-lock puzzle is used in the Makwa password hashing function, candidate to the ongoing PHC. In password hashing, you want a configurable opening effort (albeit within a much shorter time frame, usually less than a second).


How strong is this encryption? Given

Dictionary containing 1000 three-letter words:
dictionary=abc,def,ghi,jkl,mno,pqr...

Randomly chosen words from the dictionary:
10-bits-passwords=abc,def,ghi

Randomly chosen three words from the dictionary:
30-bits-password=jklmnopqr

The 10-bits-passwords are encrypted using the 30-bits-password and the tabula
recta like this:
abc+jkl=jln, jln+mno=vyb, vyb+pqr=kos
def+jkl=moq, moq+mno=ybe, ybe+pqr=nrv
ghi+jkl=prt, prt+mno=beh, beh+pqr=quy

Question (-s):

If kos, nrv and quy are known, is cracking these strings/10-bits-passwords as
difficult/as easy as cracking the 30-bits-password (Assuming the attacker has a
way to test the 10-bit-passwords)? If so, does the strength of the encryption
remains the same if a 10-bit-password is known/cracked directly?

Assuming that this is a homework question, the key here is how difficult it is for the attacker to get confirmation that they have guessed correctly.  For a given number of options that an attacker has to guess and will be given confirmation of being correct, it takes half the total number of possibilities on average to get a hit.

If you have 5000 possible passwords, then it will take an average of 2500 guesses to find it (via brute force).  If the three passwords must all be entered before confirmation is given about any of them being correct, you would need to figure out the number of possible guesses for all three passwords.  If each password is confirmed separately however, you only need to know the number of guesses to get each password and to guess them 3 times.

This is of course assuming that there are no other, more subtle weaknesses in the system.  For example, if the system stored hashes of the passwords that might be compromised, then it wouldn't matter if confirmation was given between the passwords or not since the hashes for each would allow the attacker to verify it for themselves.


Possibility of spyware on a refurbished router? I saw a refurbished router on sale on Amazon for a good price and wanted to buy it.
How likely is it that someone could buy these routers, install a custom firmware with spyware? I know spyware has gotten advanced enough that it can mimic the router's auto updater, over ride the factory reset button with a fake dialog and mimic the "Load firmware from disk" in order to keep the original, spyware version on. Because of this I'm worried there would be no way for me to do a proper factory reset or load a clean firmware from the manufacturer' (netgear) website.
Am I being paranoid? Do these advanced spywares exist for firmware on routers that can mimic/disable/spoof the auto-updater/factory reset/load from disk features?
Edit: For those who linking Buying a "Used" Router I read that question before asking mine. That question's answer simply say to do a factory reset but they don't touch on how more advanced spyware can over ride the factory reset flow thus giving the user the belief a factory reset was performed when in reality the router still has the infected spyware. I've seen spyware that mimics the Windows Update flow and other OS's update/factory reset flows so I was wondering if it could happen with firmware on a router.

How likely is it that someone could buy these routers, install a custom firmware with spyware?

I think no exact answer can be given but there are several factors which might be relevant to decide if one can trust such offer or not.
Given that the potentially untrustworthy seller knows who the recipient of the router is, it is possible that they will install a custom firmware on it to attack this specific recipient. It is less likely that this will be some generic attack which gets installed on many systems, because such attack is much more likely to get publicly known (and thus made unusable for future attacks) since somebody will eventually stumble over suspicious traffic.
Given that creating a custom image specific to a single target is costly the target needs to be worth it. If you are worth it as the victim of a targeted attack you probably know best.
Other factors which might hinder the installation of custom firmware can be the use of signed firmware by the original vendor. If this is done depends on the vendor. And it might not necessarily make it impossible, only significantly harder and thus more costly.
Apart from that it might be easier for a attacker to use a security issue or backdoor in the original firmware of the vendor as a way into your network. It is unfortunately not uncommon that devices are sold with such vulnerabilities - see routersecurity.org for more details.


Best way to secure Telegram Token in program? My program (written in C++) utilizes a telegram bot for sending me status messages. For being able to do that it needs the bot token (a simple string), something which I prefer to keep private.
This program will not only run on my own computer, but also on other (shared) computers, where I have to compile the program on. Thus I was wondering if it is possible to put the token into the code such that it can not be read out by others, but still can be used by the program?
The source code is residing next to the program, due to the need of recompilation, i.e. if the token is in the source code, everyone can read it.
Is that even possible, or is securing the token impossible on the shared computer?

Is it possible to share the token privately

No. If the machine can access the token then the token can be recovered (assuming you can't place it in SGX or a trusted module).

How to workaround

You can set up a server which recieves API calls, and then forwards the body of them to you, the server can hold the token, so your compiled code never needs to handle it. You could host this on a serverless platform if you prefer (AWS Lambda, Google Cloud Functions, Azure Functions etc.).

Possible issues

If anyone can message you, you may receive a lot of spam, depending on how you filter it.


Why does HTTPS not support non-repudiation? I stumbled into this recently for a specific project I had in mind. I thought HTTPS would prove that a given content actually came from the origin, by having its contents always signed before transfer. But actually, after the initial handshake, all communications are only secured through an agreed-upon symmetric encryption key.
This really surprised me, because non-repudiation is really important in communications, and all ingredients are available on the tech stack to make it happen.
Why wasn't it implemented? Is it purely from a performance standpoint? Is there another motivation? Is it planned to be implemented?

I thought HTTPS would prove that a given content actually came from the origin, by having its contents always signed before transfer.

Since "content" is sent in both directions, providing non-repudiation would require some cryptographic identity capable of signing on both sides of the communication. But TLS actually only requires some proof that the server is the expected one (to protect against man in the middle attacks). And this proof does not even need to be backed by a cryptographic identity, but can also be backed by some shared secret (i.e. PSK).
And while in most cases of TLS a certificate is used on the server side, there usually is no certificate on the client side. This means that non-repudiation could not work in both directions. Requiring some client side certificate would make the practical use of TLS much harder, since not only would each browser need to come with its own trust store as is done currently but also each user needs to have a personal certificate.
On top of this it is questionable if users would really want to have non-repudiation for everything they send. This is probably contrary to the quest for more privacy and anonymity. There is a reason protocols like PGP or S/MIME offer both encryption (including integrity) and signing (non-repudiation) separately.
In short: non-repudiation makes the protocol and the necessary infrastructure more complex and might not be even wanted in many cases. TLS therefore sticks with protecting the communication only, which is enough for most use cases of TLS. If non-repudiation is actually wanted or required (and often it is not) it can be added separately.


Are HTML Entities inherently unsafe? When submitting HTML that contains entities to the OWASP HTMLSanitzer, entities are converted.

For example:

BEFORE:
blah blah blah &diams;

The resulting HTML ends up looking like this:

AFTER:
blah blah blah ?

The entity is converted back to it's original unicode character.

Why does OWASP do that? Are entities unsafe?  For me, having the entities solves any issues down the road with unicode text.

Additionally, is there a way to allow the entities to remain untouched in HTMLSanitzer?

They are safe,  but is very good practice escape or convert them

This will allow you avoid being:

script injected
Face a browser text incompatibility ( have you seen    those sites
with unicode like chars? )

And Probably more

See it as a standard way to represent a text as it should be in different languages and codifications,  like some strict  utf8 will show a bad formatted text if you don't escape them, because some special chars with acute or tilde, etc will be not recognizable  to the end user when showed up.


Even with the Shellshock patch, isn't Bash vulnerable to command redefinition? At the risk of adding to the heap of "Shellshock"-related questions...

The Shellshock patch prevents arbitrary code from being executed after function definitions in environment variables. For example, here is what a patched version of Bash does when one tries to exploit the hole:

$ env foo='() { :;}; echo derp' bash -c 'echo herp'
bash: foo: ignoring function definition attempt
bash: error importing function definition for 'foo'
herp

This is still allowed by design:

$ env foo='() { echo derp; }' bash -c foo
derp

But if function definition through the environment is possible, then anyone with the ability to modify the environment can replace commands with arbitrary code (assuming the target script doesn't specify commands by absolute path):

$ env ls='() { echo derp; }' bash -c ls
derp

While the Shellshock patch prevents things like the HTTP User-Agent header attack, where any environment variable can be used to execute code, it does nothing to prevent redefining existing commands.

A similar attack is already possible without function inheritance by modifying PATH to point to a directory containing arbitrary maliciously-named executables, but that scenario requires filesystem access. This one does not.

The question, then: does being able to redefine commands through the environment count as a vulnerability? Is there any common situation in which it could be exploited for nefarious purposes? (For example, Git/Mercurial over SSH, Gitolite...)

In theory, yes. But then you also have problems with

LD_PRELOAD
LD_LIBARAY
BASH_ENV
etc.

The biggest problem with shellshock is that the name of the environment variable does not matter, bash would execute code in it even if you never call e.g. HTTP_COOKIES (who would do that btw?)

The attacker usually can only choose a part of the variable name, and it is unlikely (but not impossible) that a function/program with such a name is called.

E.g. If you restrict your git over SSH so they can only invoke git, then the attacker needs to define a environment variable git - and this shouldn't be possible.

Update: There is an other possible local privilege escalation:

You can hide commands even if they are called with the full path

env /bin/date='() { echo fail; }' bash -c /bin/date

Which can mess with system (and other) calls - and this is a problem for SUID executable which use one of that functions as root.


Can malware hide their network activity from Resource Monitor (perfmon)? Is it possible for malware to hide their network activity from tools like the Resource Monitor that ships with windows?

How much effort is it for a malware developer to implement such functionality? I'm just wondering if there is a point in monitoring network activity, if malware can easily hide from it.

Yes.

A rootkit typically patches the kernel or other software libraries to alter the behavior of the operating system. Once this is happening, you cannot trust anything that the operating system tells you.

For example; a simple change to the dir program could hide the existence of malicious files from a user, but this is easily detectable by many anti-virus packages as the alteration of an executable is something that can be noticed. If however, the malware alters the mechanisms by which userland programs query the file system, by patching the kernel itself, any user-space program can be tricked into thinking that the executable has not been altered.

Once malware has started altering the behavior of the system calls/kernel api, it can hide any activity effectively, including network interactions.

All of this only applies if you are monitoring the infected machine locally. If you have firewall logs or some other remote method of monitoring the infected machine, this information can be trusted (the network connections still have to exist, but they can be hidden from the infected OS).


Which PHP encryption method is most incidentally-secure? just started researching on the latest PHP encryption methods, I've found out my favorite algorithms are compromised. MD5 is no good, SHA-1 has "found flaws", SHA-512 isn't "meant for passwords", these are all from various StackOverflow sites.

HMAC as of 2011 had "no known attacks", and PHP's password_hash is a new addition that uses a "strong one-way algorithm".

I have heard good things about HMAC + MD5, though it has been suggested it would be best to use an algorithm that has yet to be compromised. I see bcrypt is an add-on, there is the native crypt() and now mcrypt? But password_hash handles all of these?

To me, it's all starting to sound like a deadly game of what sounds best. Can someone with adequate knowledge on the subject answer: Which PHP encrpytion method(s) compatible with password authentication are currently most secure and have no known vulnerabilities? In other words which method produces the hash that is least likely to be maliciously generated? Does any native PHP functionality make the list?

The new password_hash introduced in PHP 5.5.0 creates a very strong one way hashing algorithm. All information that's needed to verify the hash is included in it.

I tried running a loop for 5000 times, and every hash for a single password was a unique hash. To create a password hash you can simply use :

$password = '170991';
$hash = password_hash($password, PASSWORD_DEFAULT);

To verify the password, we can simply use:

password_verify($password, $hash);


Using THC Hydra to attack Cisco router I am trying to do successfull attack on my cisco home router using THC Hydra. I already know a username/password(admin/admin).

First with nmap I looked for open ports on router and only opened one is http 80.

> nmap 192.168.0.1

 Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-31 12:54 Central Europe
 Standard Time
 Nmap scan report for 192.168.0.1
 Host is up (0.0082s latency).
 Not shown: 999 closed ports
 PORT   STATE SERVICE
 80/tcp open  http
 MAC Address: ::::: (Cisco Spvtg)

  Nmap done: 1 IP address (1 host up) scanned in 3.66 seconds

After I looked at how router login page handles bad login.

 > REQUEST and RESPONSE details

General:
Request URL: http://192.168.0.1/goform/Docsis_system
Request Method: POST
Status Code: 302 Redirect
Remote Address: 192.168.0.1:80
Referrer Policy: no-referrer-when-downgrade

Response Headers:
Connection: close
Content-type: text/html
Location: http://192.168.0.1/Docsis_system.asp
Server: PS HTTP Server

Request Headers:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,sr;q=0.8
Cache-Control: max-age=0
Connection: keep-alive
Content-Length: 84
Content-Type: application/x-www-form-urlencoded
Cookie: Lang=en; SessionID=3909426640
Host: 192.168.0.1
Origin: http://192.168.0.1
Referer: http://192.168.0.1/Docsis_system.asp
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Form Data:
username_login: bad_password
password_login: bad_password
LanguageSelect: en
Language_Submit: 0
login: Log In

My hydra command looks like this:

hydra -l admin -p admin 192.168.0.1 http-post-form "/Docsis_system.asp:username_login=^USER^&password_login=^PASS^&LanguageSelect=en&Language_Submit=0&login=Log In:Invalid username or password.:H=Cookie: Lang=en; SessionID=3909626650"

Terminal output:

Hydra v8.7-dev (c) 2018 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2019-01-31 13:03:57
[DATA] max 1 task per 1 server, overall 1 task, 1 login try (l:1/p:0), ~1 try pe
r task
[DATA] attacking http-post-form://192.168.0.1:80/Docsis_system.asp:username_logi
n=^USER^&password_login=^PASS^&LanguageSelect=en&Language_Submit=0&login=Log In:
Invalid username or password.:H=Cookie: Lang=en; SessionID=3909626650
1 of 1 target completed, 0 valid passwords found
Hydra (http://www.thc.org/thc-hydra) finished at 2019-01-31 13:04:01

Note that SessionID in command and at REQUEST HEADER section are not the same since in command I used new one after I refreshed page.

Anyway whatever I try output of hydra is: 1 of 1 target completed, 0 valid passwords found.

I tried various combinations where I left out fields like Lang, Language_Submit, LanguageSelect, also I tried to catch successfull password with S:admin but still no success.

Either I am making some stupid mistake or this router have some additional protection against this kind of attacks. Anyone have some suggestions?

I figured it out. Problem was that router checks Referer field in HTTP header. It should be set at http://192.168.0.1/Docsis_system.asp.

Anyway I didn't manage to solve problem with THC Hydra since specifying: :H=Referer:http://192.168.0.1/Docsis_system.asp
 made THC Hydra to do nothing, I checked with Wireshark and not even one request was sent. When I removed this field Hydra worked fine again but router wouldn't approve login without Referer field.

I tried with Medusa but it turns out that Medusa doesn't support redirect as response since router always sends 302 Redirect with selected page depending on if login was successful or not.

At the end I was forced to write dirty Python script that sends crafted HTTP request and everything worked out.


Could QR Code Generators be passing info “over my head”? I am aware of several ways QR code generators could pass "hidden" information "around" the QR spec. For example, if you can use the masking in a spec to ignore an area where you plan to put a logo, then you could just as easily put information there.
However, in any of these schemes, the "hidden" information would only be useful to someone who knows how to read "around" the spec too. For example, humans recognize logos as a visual language that has nothing to do with the QR code spec. But, for the QR code generator to pass info around the spec, something would have to read around the spec, which I'm not really worried about.
I'm more worried about the analog of a cookie or google analytics code or something that passes information about me when I use an online generator to create a QR code, but is never shown to me explicitly. For example, if the generator encoded their address and then my QR code reader (say in chrome on my phone), colluded to pass information back to the code generator about me (or my users of my code) when they scan it without showing that information to me or the user of my QR code. (Obviously, I could QR encode a link with query parameters in it or something that could be used to gather information, but I would see that when I create the link and my user would see that when they use the link (if they stop to actually inspect it)).
My concern is if there is any allowance in the spec for hidden information or if there's any known commercial practice between generators and scanners to collude in passing around information they don't show to me or my users.
[FYI, I originally posted here in Stack Overflow, before I heard of the security StackExchange.]

It is possible to sneak some "steganography-alike" data in QR-code on encoding level. Example - intentionally invert some bits (squares) in data area of QR-code. They will be detected and silently corrected during read, therefore payload won't be affected, but you can identify modified bits and gain hidden knowledge i.e. from their position.
If you are afraid it is happening, simply read QR payload and encode it again - such encoding-level artifacts will disappear.
Do not be worried if you re-encode QR code content and find it completely different - most probably you are just using different error correction level in your encoder.


How to secure test/dev environments from outside world? I would like to set up a security barrier to my test/dev environments. I'm under a more or less typical LAMP on dedicated servers.

Thing is, I have some facebook apps, a widget for other devices, and other apps that need to connect to my site via an API(also, ajax calls!). But I want my test/dev sites not accessible from the outside.
Hence, how could I better set up some protection here?

The first ideas that come to me are:

Remove DNS entries.

You can only access via IP, and set up /etc/hosts entries wherever I want to test. But it would need referring via IP in other external apps like a FB app.

Apache http auth

Pros: you need the u/pw to access, so kind of secure. But: how can you set up automated access? E.g. widgets, FB apps, ajax calls... (I actually don't know)

robots.txt entry to avoid search engine exposure - but not enough to actually block a site.

Ideas please? Thank you!

Put the test server behind a router/firewall, and don't expose it on the outside. As long as everyone who needs to access the test server is behind the same router, everything is fine (provided you trust the local network); the outside world won't even know the machine exists.

If you need access from outside, VPN or SSH-tunnel into the local network.