In SSL/TLS, what part of a data packet is Encrypted and Authenticated?

SHORT ANSWER

In the case of HTTPS, any data that would have been sent had the connection not been secure, will be sent as encrypted application data. Additionally, for historical reasons, the MAC and Padding will also be encrypted. In SSL 3.0 and TLS 1.0, this means that the layout will be as follows:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02 (encrypted)    GET /index.html HTTP/1.1
03 (encrypted)    Host: helpme.com
04 (encrypted)    |  MAC  |  Padding  |

Note that, strictly speaking, the MAC is only a HMAC in TLS 1.0 and up. In SSL 3.0 it was a special mode used only in this protocol.

SLIGHTLY LONGER ANSWER

Starting with TLS 1.1, if a block cipher in CBC mode has been negotiated, an explicit IV will be inserted at the start of the encrypted data:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02                IV
03 (encrypted)    GET /index.html HTTP/1.1
04 (encrypted)    Host: helpme.com
05 (encrypted)    |  HMAC  |  Padding  |

The IV is there to make the cipher text unpredictable and less susceptible to certain cryptographic attacks. Implementations might treat it differently both at encryption and at decryption. Some implementations might generate it from random, while others might generate it as the cipher text of the last block of the previous fragment XORed with a constant value. Conversely, at decryption, implementations might treat it as either an independent field or as the first block of cipher text (and discard the corresponding decrypted block before outputting the decrypted plain text fragment, just as the HMAC and Padding is discarded).

Starting with TLS 1.2, an AEAD cipher might be negotiated, which means that the MAC mechanism is integrated into the cipher mode and no HMAC will be required. In this case the layout will be as follows:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02 (plain)        Nonce
03 (encrypted)    GET /index.html HTTP/1.1
04 (encrypted)    Host: helpme.com

Note that the length of the cipher text corresponding to field 03 and 04 will be longer than the length of the corresponding plain text. The exact layout will depend on the details of the AEAD cipher mode. Normally, it will just end with a MAC.

Now, to complicate things further,  in all protocol versions and cipher modes the MAC will be calculated over data that differs from both the plain text (optionally compressed) fragment and from the encrypted fragment. In particular, the RecordLength field will have the plain text / compressed value (not the encrypted value) and a Sequence Number will be inserted to prevent replay attacks. The MAC itself is obviously not included in the data the MAC is calculated over, and neither is the padding. The last part, the MAC not being calculated over the padding, is the reason some of the attacks against SSL/TLS are possible.

IMPLICIT SSL / EXPLICIT TLS

HTTPS is an instance of Implicit SSL, which roughly means that SSL/TLS will be the outer most protocol layer of the connection. The first thing to be sent over the connection is a SSL/TLS handshake, and all application data will be sent encrypted. HTTPS will always be Implicit SSL.

By contrast, Explicit TLS means that SSL/TLS will be negotiated explicitly as part of the underlying application protocol. This is common e.g. in the case of application protocols such as SMTP, POP3 and FTP. When Explicit TLS is used, the first data sent over the connection will be the opening protocol messages of the application protocol.

Note that the "SSL" and "TLS" part of Implicit SSL and Explicit TLS is a misnomer, in the sense that it is perfectly possible for a client and server to negotiate TLS 1.0 or higher over an Implicit SSL connection, and conversely to negotiate SSL 3.0 over an Explicit TLS connection.

CAN CLIENT AUTHENTICATION AND SESSION RESUMPTION BE TRUSTED?

To complicate things further, it should be remembered that encrypting something for someone, doesn't guarantee that entity will be the only one reading the encrypted data, because there is never possible to prevent the recipient from simply forwarding the decrypted plain text to a third party. This is in particular important in the case of SSL/TLS, because authentication normally only goes one way (the server authenticates itself to the client) and a special handshake is required to authenticate the client to the server.

This attack demonstrates how this fact can be exploited with current protocols and some cryptographic primitives. There are however a few things that can be done to prevent this from happening. For instance, the following rules will prevent the attack, but might break compatibility with existing implementations:

When the server requires client authentication, either:
a. Send a hello_request first thing after the initial handshake has finished and request client authentication for this second handshake, or
b. implement the application protocol (or the application using the application protocol) in such way that no data sent prior to client authentication will be treated as authenticated by the client, e.g. by internally starting a completely new application session and having the client resend anything it sent prior to the authenticated handshake.
When a connection has been initiated with a resumption (abbreviated handshake) treat any hello_request or client_hello messages over that connection as errors.


How does SHA3 (Keccak & SHAKE) compare to SHA2? Should I use non-SHAKE parameters?

NIST has an excellent document detailing the reasons behind why they wanted to create SHA-3 and shortcomings in SHA-2 which seems to address many of your questions. Specifically this document covers both the design challenges and how Keccak addresses these.

http://csrc.nist.gov/groups/ST/hash/sha-3/documents/burr_dimacs2013_presentation.pdf


A Brief Note On Banner Grabbing
The first, biggest, hurdle one faces when getting into vulnerability assessments or penetration testing is understanding the limitations of whatever detection mechanism you're using. Like Rory said, you didn't really say how you got the presented list of ports, however it looks like an NMAP scan using banner grabbing. This Is Important! Banner grabbing works by asking each scanned port,

"Hello old chap! Anything you might be able to assist me with?"

The results rely on both being able to access the port, and the service responding accurately.
Issues With Banner Grabbing
You will often find that distributions that attempt to provide long term support, RedHat being the classic example, that these banners are not necessarily useful. Typically, when a bug is found in a piece of software (and assuming it is fixed) then a new version will be released that fixes the issue. Often, these long term support distributions do not want to blindly upgrade the software. So, in order to address bugs, the vendor will manually apply the patch to the older version. This is often called "backporting". As a result, the patch gets applied, but the banner still says the old version.
Better Options
While a quick nmap scan with banner grabbing can be useful, it is only a first step that may be useful in identifying low hanging fruit. To really good good information on your system there are a few other things you can do.

Ask - The easiest answer here is to ask your friend for the system configuration information. What distribution is it running, what binaries are listening on each port, what versions of software are installed, what is his patching schedule, when was it last patched, etc. This is all, of course, limited to what he actually tells you, but so long as he is trustworthy and competent, it will result in better information.
Credentialed Scans - This is my personal favorite. The better vulnerability assessment products will, given adequate credentials and a way to log into the system, can perform a laundry list of local checks. This is how one can bypass the backported fixed issue discussed above. Some, such as Tenable's Nessus are free for use in certain situations and are nearly as full featured as their commercial versions.
Exploit It! - Assuming you have permission, you can always try exploiting the service. If you succeed, then you know there's a problem. This can also give you a chance to really start trying out some fun things like finding and using known exploits, or getting to know a framework like Metasploit.


How do the STS token formats compare to each other SAML vs SWT vs JWT?

Better or worse is relative to the usage of the protocol. SAML has it's place and SWT/JWT/et al have their place. The SAML spec is pretty much set in stone, whereas SWT/JWT are really in their infancy and keep changing.

SAML has lots of knobs which makes it fairly complex and that's the enemy of good security, but everyone pretty much implements it the same way. SWT/JWT are fairly simple in design, but nobody can agree on a single bloody implementation standard and a lot of the public libraries used don't undergo security review.

It also depends on how the tokens are signed and how the keys used for signing are protected. Shared secrets tend to be more difficult to protect and PKI is a PITA, but others may disagree.


While you can stuff about everything you can imagine in ad hoc extensions in a certificate, this is rarely a good idea. In particular because the certificate is signed (by the Certification Authority which issued it), so whatever you put in the certificate has to go through the CA first.

Certificates are about authentication and this does not live well with authorization. Certificates are long-lived entities which cannot be altered on a whim; the only way to "modify" a certificate is to revoke it and issue a new one; not only must this be done by the CA, but it is an inherently asynchronous process: it takes at least several hours, more often several days, to propagate revocation information with any kind of reliability (and some clients do not verify revocation at all...). For anything related to permissions, you want a system which reacts quickly, because when you want to remove an access authorization, you want to remove it now, not next week.

If, in your protocol, the server has something to say to the client, then it seems more appropriate to send the data in the SSL tunnel, after the handshake, as part of the inner protocol (in the same way that HTTPS is HTTP within a SSL tunnel).


portscan using nmap fails to return open dhcp-port

You're performing a SYN scan (the default when run as root) which only scans for TCP services.  DHCP, on the other hand, is a UDP service, so will only be found with a UDP scan (-sU).  Even then, it might not be found, as it is up to each application to respond to UDP packets, if it does not, then there will also be no response.  This will lead to nmap giving the response "open|filtered", which means basically "the packet was not rejected".  Alternatively, if an ICMP port unreachable message is received in response, nmap will mark the port "closed".  Only if a response from the application is received (which most DHCP servers will not give to a UDP scan) will you get "open".  See the NMAP documentation for details on port scanning techniques.


Is there any hope of getting my pictures back after an iPhone factory reset some day in the future?

Modern encryption is strong enough that there is no way to retrieve the lost data without the key. Although it's possible that it could be doable in the future in theory, consider that even the cipher 3DES, a trivial modification to a cipher designed nearly half a century ago in the 1970s, cannot be broken in the manner you want, and that was cryptography in its infancy. Modern iPhones use AES which has held up to 20 years of analysis and is showing no signs of meaningfully weakening.
Ciphers are never secure one day and fatally broken the next. There is virtually never a massive breakthrough that renders a cipher useless, as attacks are improved incrementally. If AES ever gets broken badly enough that you would be able to recover the encrypted data without the key, there would have been decades of slow improvements to the attack and we would all have known for years that it's too weak to even consider using. If that were the case now, I'd tell you to wait a few decades and maybe, just maybe, a key recovery attack would be released, but that's not the case.
The data is gone. Plan for keeping backups in the future to avoid a repeat of this issue.


Where to store refresh token if not in local storage?

Storing the refresh and access token is in JavaScript memory is generally considered much better than cookies or other browser storage.

You still don't need to worry about asking the user to login every time. The authorisation server (Auth0 in your case) maintains its own session (SSO Session) behind the scenes which is persistent. So it survives even if the user closes the browser.

This means that even if you have "lost" the refresh token stored in memory (e.g. if the user closes the tab), you just need to re-run the authorisation code flow to get new refresh and access tokens (i.e. redirect the user to the authorisation server). This should be silent to the user (i.e. they won't see the login screen) because of the same SSO session that is maintained by the authorisation server would still be active.


What ways are there to populate web directory wordlists?

You can use word lists in the Kali Linux /usr/share/wordlists.  If you want to create specific word lists, you can use the Crunch.


There isn't a clean answer to this. It depends on the user. Just a handful of immediate considerations (there are many many more) -

How is the physical book stored? I.e. someone keeping a book in a physical safe in a gated home is a lot safer than the guy carrying around the book saying "passwords" on the front of it in his rucksack.
How secure is the machine the password manager is used on? If untrusted code is running on that machine as the same user theoretically there is nothing stopping it reading the passwords.
Not all password managers are internet based. You can either just store them locally or use a hardware device.
What passwords are used? Someone using a password manager is a lot more likely to user longer randomly generated passwords than someone copying them out of a book.
What does the password protect? I.e. your password being written down in the same physical location as an a machine with an unencrypted disk doesn't really reduce the security from a vaguely technical opponent. Writing the password to an encrypted USB stick on the stick makes it pointless.

Both techniques when used properly can be very secure. With a password manager you gain the ability to additionally have a master password which isn't recorded anywhere. With a password book you gain security from cases where you need to enter a single password on an untrusted machine.


Securely storing account credentials/information for critical company services - the bus factor

What you're describing is the intended use case for a password vault. It provides fine-grained access to passwords, and in my experience they also work with private keys and other information (I've used CyberArk in the past). With CyberArk you can manage access by using LDAP groups, which is nice for ensuring that specific groups of people have access to different account types.

But, you should know what you're getting into. For example, CyberArk is intended to be implemented as at least two servers and virtualization isn't recommended for the vault server. It's quite a bit of infrastructure to manage for a small number of secrets. In other words: perhaps a password vault is a good solution for a large enterprise, but maybe not for a smaller organization.

Another potential solution for a small business could be something like Keybase, using their 'teams' functionality. https://keybase.io/blog/introducing-keybase-teams

Also, AWS just created a new service for managing secrets. I don't have experience with this yet but perhaps it's a good fit: https://aws.amazon.com/secrets-manager/


Spamming exploits without user detection

Why do you assume the user would notice? Starting a program takes a bit of CPU, a bit of RAM, causes a few disk accesses, but that's pretty low-key. Even geeks who have a CPU meter or other common system monitor in their task bar will probably assume it's just some Javascript on a timer in an opened web page, or a garbage collector, or a scheduled task in the operating system.

Maybe you were expecting the program to display a window? The exploit would take care to hide the window, or run the program without displaying its output in a visible window. A very simple way to do that (but not very discreet) is to start the program minimized (for example, under Windows, you can start a program from the cmd command line with programname /min). There are more sophisticated ways that would hide the program more − under Linux, for example, start the program in a virtual display such as Xvfb; there are ways to do this on Windows as well. And even that assumes the program has a GUI; many exploitable system components can be embedded inside another GUI application (and the exploit would then take care of providing a wrapper application that doesn't actually display anything) or just don't have a GUI.

In a web context, an exploit in the form of some resource (image, document displayed in a plug-in) on a web page could be styled to show as a single pixel in some remote corner, even stacked under some other element for good measure. Who checks all the media used by all the frames of every web page?


What can I do about the Intel Management Engine?

Don't use the onboard NIC, which is how ME accesses the Internet.  Instead, use a USB LAN device, or even one plugged into a PCI slot -- ME doesn't know how to use them!


What purpose is served by repeated connection resets?

You should use grep 'Connection Reset' /var/log/auth.log -A 2 (do not use cat since it's not useful, and use -A to get the context above the matched lines).

My guess is that your server is being bruteforced, you should be able to see the attempts with the above command. The attacker is closing the connections as soon as it knows it won't be successful, and retries again and again.

This is something very common, see this question to know how to block them.


COMMUNITY SIP TCP/IP message flooding directed to SIP proxy

Is it possible that you are using an old snort version?
Please see here: http://ubuntuforums.org/archive/index.php/t-1469108.html

Otherwise it would be great if you refine your question with some Firewallrules (Inbound) or some PCAP Files from wireshark.


Does information security justifies Iphone 6's "error 53"?

There are two questions here I think.

The first, is it so serious that the best course of action would be to block the device altogether?

Well, let me start by asking a question. How much do you value your fingerprint data? What about your Apple Pay data? As you are a non-Apple user, Apple uses this "secure enclave" to store this data. When you enroll in Apple Pay, your information is stored in the secure enclave. When you enroll in the fingerprint sensor, your information is stored in the secure enclave. By allowing an untrusted device to access this information, it can be leaked and stolen to unknown parties. To mitigate that, Apple has elected to block untrusted sensors altogether, which is how this secure enclave is accessed.

This covers the basic tenants of security: Don't trust user input and default to fail closed.

The second question, does the means justify the ends? That's a question you, as a user, need to ask yourself. Consider the risk of having very sensitive information stolen, versus saving some money on repairs. I can't answer that question for you, but I can hardly blame a company for taking a hard line on protecting very sensitive information.


Practical implications of using a service like ProtonMail

It's a little misleading to say that Gmail emails are not encrypted during transfer, because they only are not encrypted when the receiver doesn't have TLS enabled (see this link). Gmail and all of the other major email services have TLS enabled, meaning that your email is encrypted during transfer. This does not mean that the emails are always encrypted on the mail server or client, or when transferring between you and the mail server. Gmail does not do the encryption on the client before sending to their mail servers, all encryption for them is done on the mail server.

This is where services like ProtonMail and Tutanota come in. They do the encryption on the user's machine, before the packet leaves the host. This means that someone cannot successfully complete a man-in-the-middle attack by sniffing out that packet with your email in it.

These services offer end-to-end encryption if sending to someone also on that service by default. Also offered is the option to send a link to the service's website to someone not on that platform, and they type in a password to decrypt the email once there. They assume that you give this password to a person in advanced, preferably in person.

Yet another benefit of using one of these two services is that they are not based in the United States, making them less likely to cooperate with the US Government for whatever reason. Even then, because the emails are encrypted by the user and not the server, it is nearly impossible for even the service owners to read your emails.

Some real-world scenarios of where this might be useful is sending business related emails with unannounced IP, sending credit card information (still not a good idea even with these service), sending personal information, or if you're trying to not allow your country's government access to your email.


GnuTLS ServerHello exploit (CVE-2014-3466) - how to verify?

Typically you verify a vulnerability in three ways:

Run exploit code. Did it blow up?
Check your package manager's documentation. Do you have their version?
Check the code. Do you have the affected lines?

Since #3 is not effective for binaries, and you do not want to run exploit code, your other option is updating. I'd imagine by now that every distro has released new versions or backported patches for the GnuTLS packages, so a simple update command should identify and patch affected machines.


Why Qualys SSL Server Test is giving me 80 and not 100 in Key Exchange?

My guess is that the DH parameters used for your DHE cipher suites use a 1024-bit modulus.

(I must say that this "scoring" is completely arbitrary and not very rational; awarding 128-bit symmetric keys a grade lower than the one for 256-bit symmetric keys makes sense only if 128-bit keys can be considered somehow "breakable" in the foreseeable future, which is a rather preposterous assertion.)


Are there / have there ever been viruses that completely evade virus scanners for very long?

Yes. Stuxnet was being used to attack the Iranian nuclear facilities in 2007, but wasn't detected by AV or the public until June 2010. Part of its construction was designed to resist analysis by encrypting the payload against a value that could only be derived by a valid target system - it didn't appear to do anything particularly malicious outside of that payload.

It's not just malware, either. Bugs like Heartbleed and Shellshock are thought to have been exploited months or years in advance of disclosure. It was only once the exploit packets were known about that people were able to go back through their packet captures and identify cases where they may have been breached.


Encrypting salted password hash before storing in the database

Encrypting a hashed password is not better than adding pepper, despite what you read in your cited answer. It is functionally equivalent, but more computationally intensive (wasteful) and it increases the chances to introduce bugs.

You do not need a special library to add pepper. Since you have a library that handles salt, you just have to replace the code hashPassword(thePassword, theSalt) by hashPassword(thePassword, the128bitRandomPepper + theSalt). With + being the string concatenation operator in Java.

RSA is an asymmetric encryption algorithm. This is not at all suited in this context. Just do not encrypt. But if you really need to, use AES-GCM (for those wondering why GCM: it's mainly to force the OP to correctly handle the IV). Then post your full scheme here to have it reviewed, because you might still do mistakes.

Just do not encrypt, instead use your library as described in point 1.

To answer the claims made in the two links you cite:

From stackoverflow and from security.SE: One can rotate the encryption keys. However, once the database is breached, that is useless: either the encryption is good, and changing the passwords or rotating the key is useless; or the encryption is weak and the passwords need to be changed.
From stackoverflow: Encryption is more secure than hashing. That's wrong.
From stackoverflow "since he knows the salt and the output, he can brute force the pepper" The same applies with encryption. This is not an issue with a pepper handled as a key.


Two servers talk over HTTPS - do I need more security?

If both servers talk to each other with HTTPS, use strong ciphers with HTTPS and properly check the certificate of the peer than the connection between those servers can be considered properly protected. If you need more security for the transport protection you might use certificate pinning to.

But, protecting the connections means only this. It does not mean that the data are protected against modification outside the connection, i.e. before encryption or after decryption. It also does not mean that only innocent data gets served.


How to view last run shell command via cmd.exe through a HKEY_CURRENT_USER.reg file?

Not possible. cmd.exe does not save history on the registry or a log file.

Open cmd.exe and press Up. What shows up? Nothing. That's because there's no history...


Are ARP attacks possible on OpenVPN and Wireguard connections?

ARP is a link layer 2 ethernet protocol, it does not exist at IP layer 3.

So no.

EDIT

Normally VPNs use TUN, which is layer 3. There is a TAP layer 2 which will carry ARP, but outside of businesses BRIDGING two remote networks together this is seldom used. In a TAP bridge, you probably could ARP spoof.


The connection between the client and the server does not use public key encryption (that is only used for the initial key exchange). A different algorithm is used for encryption (usually a symmetric encryption), such as AES-256-CBC on a TLS 1.2 connection. So unless you intercepted it, no one but the intended browser and the original server can decrypt the message. So interception is not as easy as having the public key information from the server.

The cookie is not sent as a GET request. It is added to the headers as Cookie:[Token]; [Other cookies];. The underlying request type is irrelevant for this. (The default request type is GET, however.)

I would suggest that you look at the network traffic from your browser to a website to which you are logged in, and see what is being used where. (This is easy to do in Chrome.)


Remove malicious rootkits and spyware from HDDs and SSDs

No, the HPA and the DCO simply limit the size that the apparent drive size.  The DCO could be used to standardize drive size in a company wide deployment where the drives are source from multiple vendors.  A HPA is accessible by software which is "HPA Aware".  Neither of these are where firmware malware would exist.

The firmware is is a completely different storage, a different chip entirely from the main block storage that you see on a normal Hard Disk or SSD.  The firmware is able to be read, and flashed (not edited, but completely overwritten) using a special utility completely unique to the specific manufacturer, chipset (vendor and version).

The firmware of a SSD (and USBs for that mater) acts as it's own computer, with a processor, memory, and storage for the firmware.  The firmware handles wearleveling, reading, and storing data.  A malicious firmware could simply lie and say it was overwritten and you would be none the wiser.  A more complicated firmware would also need to dump a fake 'untampered' firmware if it was read using the special utility.

In summary, no.  You're not correct, there's no 100% way to prove a devices firmware isn't compromised, without taking the chip off the device and forensically dumping the firmware directly from the chip.


When a company asks to test physical security, what are some techniques one could use to gain entry?

The art of social engineering is all built around trust, so first you need to plan out how you can gain the trust of the target. This is different in every organisation, so unfortunately no-one can really tell you what you should do, but knowing some war stories may help inspire you. I recommend the book 'The Art Of Deception' by Kevin Mitnick as a brilliant source of war stories.

Some common social engineering tactics I personally like are:

Dropping USB sticks infront of the lobby to try and entice an
employee to use them internally.
Creating fake parking tickets, and sticking them on an employees windows with a URL to 'view further information regarding the offence'.
Just asking - you will be amazed how many times just asking the right person for information will work.

Regarding physical security, again it is difficult to know what will work best without first having information on the target, sometimes it's possible to just walk right up to the rack and start plugging in cables, other times it takes more planning to explain why you need access to a server room.

One thing that you should be doing when planning your physical security test is researching the environment, do you know anyone in the company? Are you likely to be identified by anyone as a penetration tester? Is there a security desk between you and the server room? How many employees work in the building? Are you likely to be spotted should you sit down next to an employee that you have never met? These kinds of questions should be considered before walking into the building.

Lastly, always be confident in what you are doing, there is nothing more of a giveaway than someone who is stumbling over their words when being questioned about what it is they are doing. Remember that you only get 1 shot at this, so being able to think on your feet will be a huge benefit.


How does the recent discovered PowerPoint exploit work?

If the cache length lets say is 10.1kb well then the memory block will look something like this (Lets say the whole block is 30kb [Notice the middle block is our PP cache]):

|~~~~~9.95kb~~~~~|~~~~~~10.1kb~~~~~|~~~~~~9.95kb~~~~~~|

Now lets use the exploit, our data will look like this (Notice we just ran over 9kb of the next segment!):

|~~~~~9.95kb~~~~~|~~~~~~10.1kb~~~~~|~~|~~~~9.95kb~~~~~~|

This just ran over the next block causing us to inject data the data segment that is not part of the PP cache which is a buffer overflow.


Could free VPNs with public credentials be decrypted by ISP?

The username and password are only used for authentication of the client against the server and have no function in the encryption process itself. They are only used to restrict who can use the service but not for protecting the data transfer. This means that everybody knowing these credentials can use the VPN service for themselves but not that they can decrypt the connections of others which use the same credentials. This is not only true for this VPN service but for example also for HTTPS connections.


Force connected devices to use http rather than https

If you aren't concerned about the user being prompted, then you intercept most HTTPS connections by proxying them.  Instead of allowing the user to directly connect to the site they've requested, you connect them to a intermediary you control, and then use it to connect out to the to site that they've requested.  This way the client's HTTPS session is terminating on your box, with your SSL cert that you own the private key for, and thus you decrypt the client-side traffic, and since it's your proxy that is then making the connection out to the server they actually wanted to talk to, your proxy is now the client for that SSL connection, and you have full access to the traffic from that side as well.

This will prompt the user because of course your SSL cert, the one on their server the users are connecting to, will not be a valid cert for the sites they're actually trying to access, so client apps will (or should at least) view this as an attack and warn the users not to trust the connection.  As P4cK3tHunt3R mentioned, you can avoid the warning by installing your cert as a trusted root on the client devices, in which case they will no longer be able to discern (generally speaking) that the cert is not in fact valid and trusted for the site they're trying to connect to.

Aside from proxying, there are other ways to downgrade connections as an active MitM, such as SSLStrip, which will work in some cases, and not in others.

In some cases, proxying works even better than advertised, with mobile apps particularly, which are notorious for ignoring certificate warnings and happily accepting untrusted certs without bothering to inform the user than anything is amiss.   In other cases, it won't work at all, due to practices like certificate pinning where a browser or other application only trusts specific certificates, and will refuse to accept your certificate, even if it would otherwise be valid and trusted.


Can someone use IP spoofing to access your facebook profile as an administrator?

We don't know what security measures Facebook exactly provides but spoofing the source IP of a TCP connection (which is used when accessing a web site) and still doing something useful with the connection is impossible in practice.

This means that it is more likely that the site was really accessed from the shown IP address (no spoofing), that the database records tracking the IP address were tampered with or that you've interpreted the information wrong. If any of these happened or something else can not be inferred from the provided information, but I'm pretty sure that no IP address spoofing was done by an attacker when connecting to Facebook.


It sounds like you want public-key cryptography similar to what SSH supports.  The basic idea is that the user provides their public key to the server during the account creation process, then proves their ownership of the corresponding private key during the login process.

The public key, as the name implies, isn't even remotely secret, so it meets requirement 1, it can't be used to construct the private key, so it meets 2, it's computed at account-creation time, so it meets 3, and yes, you can use a password to protect the private key.


Can I trust my antivirus' assessment of my computer as clean, if it previously found threats?

You can't, best option would be to reinstall the os and avoid downloading suspicious files. if you cant do that run a virus scan that doesn't run on the current os such as http://support.kaspersky.com/us/viruses/rescuedisk or something similar. Some virus can and will hide from regular virus scanners or outright prevent them from running.
If you use your computer for anything important you need to reinstall the os. You dont want to leave a risk of leaving any malware behind.


Safest way to keep an offline bitcoin wallet

A way to secure online storage

One thing that could very much help with securing any data file of interest from access is to make use of Mandatory Access Control (SELinux in this example) and an second machine, possibly airgapped. You'll need a small program running on the wallet machine (I'll call it banker for this post) whose job it is to generate challenges and release coins only to properly authenticated requests.

We rely on SELinux to do the following: prevent read, write, and permission changing access to the bitcoin and authentication seed files to every application except for banker and whatever it spawns. We also rely on SELinux to prevent itself from being taken out of enforcing mode without a system reboot.

The banker authenticates any withdrawal by printing a random seed value and the corresponding HMAC output generated by combining the seed value with your authentication seed. This authentication seed is kept somewhere else, perhaps on your phone. You can use any method you'd like for exchanging the signed request such as email, scp, web interface, or taking a picture of a QR code and running it through your own app on the phone, then taking a picture of that code with your computer's camera. Go wild! You could also make use of an incrementing counter that never lets an equal or lower-numbered request succeed in order to make one-way authentications, or if you're feeling very fancy, you can use GnuPG and an OpenPGP smartcard to authenticate with a pinpad.

Expire any requests after a certain period of time: five minutes to an hour depending on how speedy you feel. Expire any requests that work immediately so they can't be replayed. Not that I recommend it (defense-in-depth is always wise), but in theory this should permit you to allow somebody to login to your machine as root and still be unable to steal your coins.

The security of your offline storage

I realized I didn't actually answer your initial question, so here's the followup: you're trying to defend against losing your money in one of two ways:

Somebody steals your wallet
You lose your wallet

In both cases of offline storage, you're protected if you weren't compromised before the data was printed out and erased from the computer's memory. That second part is a big caveat: if you're printing files they may be left as temporary files somewhere on the disk.

Both systems are roughly equal for risk of loss. Your password should be very long and complex. If you forget or lose the paper where your password is written, your wallet becomes lost, in essence to a fire. If you lose the paper your printed individual values on, the same happens.


Directory listing for icons and image folders

This totally depends on what the owner of the server wishes to use the directory listing for - there may be a need to have it on.

That said, in many cases directory listing should be turned off if there is no need for it to be on, this is because its a potential vulnerability that could be easily mitigated


I don't know what you're aiming for with your question but filtering outgoing traffic through computer software suffers from the same deficiencies like virus scanners and the like. You need a pattern matching software that is able to distinguish what is good and what is bad. If malware records keystrokes, passwords, whatever, it is sufficient to encrypt it and every filter will let it pass because the risk to break business processes by stopping legitimate traffic is too big.
So there is no "yesterday" and "today", all this stuff can be easily tricked with average knowledge available for free on the internet.


How secure is online banking with smart card? How could it be hacked?

MITM is going to be unlikely - the bank should have a SSL connection with a signed cert from a CA, which would alert you with a big red screen and scare you away. It is also possible that you were re-directed to a non-secured version of the site (and a fake/look-a-like site exists), and proceeded to enter your info there, but this should quickly raise red flags with the bank (and while it may not being up the red screen, there should still be some signs, like the missing padlock, to alert you).

What is more likely is some sort of virus on your end that can either install it's own bogus CA and then proceed as above, or hijack the session by stealing the authentication cookies or similar.

It's also possible that the bank itself had another vulnerability elsewhere - this would probably affect multiple accounts, but you may be oblivious to the fact that others had similar issues (but hopefully the bank becomes aware).

You also assume that a MITM attack could only happen when he was logged on - but this may be a false assumption - would a MITM attacker pass on the "logoff" request? I don't see why they would - what if they extended the banking session each time (going to a new page/etc.) instead of allowing it to time out? - unless the bank at some point asks for the password/code again (unlikely from a UI perspective), then chances are you could be unaware that you are still "logged in" (although the bank should have logs as far as when you logged in/out and can check for this kind of stuff).


how to test on which TLS Version has https connection established between server and a mobile application ( Android and iOS )?

Sniffing the packets with some application like Wireshark would reveal the information; the protocol version used in a connection is in the ServerHello message (take care to look at the server_version field, not the "version" in the record headers, which may not match).

If you don't want to use a packet sniffer, you may try to modify the DNS so that the connection request from the application does not go to the intended server, but to another computer that you control. On that computer, you can then run a small server software that binds to port 443 and receives the ClientHello message from the client. Looking at the message contents, you could see the maximum version supported by the client. By sending yourself the message to the intended server, you could also obtain the corresponding ServerHello and see for yourself. Using a packet sniffer would still be simpler, though.

(Altering the DNS should be doable on the WiFi access point, if the mobile connects through WiFi.)

You cannot obtain the information without connecting at some point to the true server, either from the mobile application or on your own; the reason is that the protocol version is the result of a negotiation between client and server. The client suggests, but the server chooses.

An additional issue is protocol downgrade attacks. It is improbable that your client and server using SSL 3.0 by default; it would require that either or both implementation are unaware of TLS 1.0 (published in January 1999 !). However, it is conceivable that SSL 3.0 could be forced upon them. The method is simple: the attacker simply breaks (with RST packets) any connection where the client announces anything newer than SSL 3.0 in its ClientHello. Some clients will then try again, voluntarily restricting themselves to SSL 3.0. If your application is such a client, then the protocol downgrade attack succeeds and the connections will use SSL 3.0. The problem here is that you cannot know whether a protocol downgrade attack applies without trying it: it hinges on the client behaviour under abnormal circumstances, so you have to force the abnormal circumstances. You are then back to the sniffer plan, with a vengeance.

On the other hand, you might get the information you seek by simply connecting to the server. From a computer with OpenSSL (e.g. any Linux or MacOS X system), try this:

openssl s_client -ssl3 -connect theservername:443

replacing "theservername" with the actual server name (and possibly replacing the port if the connection does not use the standard 443 port). OpenSSL will try to connect using only SSL 3.0 as supported protocol. If the server rejects the connection right away with a "protocol_version" alert message, then you know that the server does not accept to use SSL 3.0, and thus the connection between app and server will never use SSL 3.0, regardless of protocol downgrade attacks.

But if the server accepts a SSL 3.0 connection, then all options are still open, and you are back to trying the downgrade attack.


Would changing my DNS get through i-Boss?

From iBoss Knowledgebase on HTTPS Filtering:

The iBoss blocks DNS outgoing requests which would block secure sites users are trying to connect to that fall under the iBoss filtering policies.
If you are experiencing iBoss not filtering secure sites, try to flush the DNS cache by re-booting the computer and the iBoss unit.

So yes, it sounds like changing your DNS servers will bypass it.
Assuming you have sufficient control over the computer to change the DNS settings, such as your own personal device, that is.


Sniff wireless (Wi-Fi) trafic with Wireshark

Be sure to have disabled on AP the "client isolation" option. That could be the problem. If you are pretty sure that everything is good set up.

To check this you can do a test without sniffing... just connect two clients to the network using the WEP key you already have and try to communicate between them. A ping is a good test if you have no icmp filter on both devices/pcs . If you can't ping between them, I guess you have that "client isolation" option that is crashing your sniffing tests. If you can ping, then there is no "client isolation" and you must dig into wireshark config to try to setup correctly the WEP key, the channel or whatever.


What is the difference between ASA 5505 Security Appliance and without Security Appliance

What are the differences between having security appliance and without security appliance?

Bad listing information by a seller on Amazon. Seriously, there is no ASA (Adaptive Security Appliance) without a security appliance.

You can find the datasheet for the ASA-5505 on Cisco's website here. On "Table 2" you will find the ordering information which includes both the part numbers referenced on the Amazon website that indicates what is included.

This product line has already had it's EoS/EoL announcement and has already passed the last ship date from Cisco (i.e. Cisco is no longer manufacturing these or providing them to distributors). What you will find now is the stock that individual sellers had on hand before this point...some will raise the price to take advantage of the limited availability, others will drop the price to get them out of inventory faster. You will also see more of these appearing on the used market.


TLS protocol, session key for secure connection

is the public key sent by server encrypted or clear? I assume it is clear since it is public

The public key of the server is contained in clear in the server certificate which is send in clear by the server, which means that the public key is implicitly send in clear too. Note that this is only the case with certificate based server authentication which is the most common way to authenticate the server in TLS but not the only one. Other ways to authenticate the server are for example pre-shared keys (PSK) where no public keys are involved at all.

  How are the session key and public key related?

The result of the key exchange is a pre-master secret which then gets used to derive a master secret which then gets used to derive the session keys, i.e. the keys to encrypt and protect (HMAC) the application data.

If Diffie-Hellman key exchange is used as you state then there is no relation between the public key and the pre-master secret and thus not between the public key and the session keys. The only use of the certificate in this case is to authenticate the server and it plays no role in the key exchange. Diffie-Hellman key exchange can also be used for TLS handshakes where no public key is involved at all, for example with PSK authentication.

  Does the client sends session key to the server? session key sent: f(Random_gen_number, Public_key) where f is an encryption function?

With Diffie-Hellman key exchange there is nothing even similar to this. With RSA key exchange the client instead creates the pre-master secret fully on the client side (i.e. it is not a result of a key exchange where both parties are involved, like in DH key exchange) and sends it to the server encrypted with the public key of the server. The server then decrypts this with its (secret) private key and thus can extract the pre-master secret. The process of deriving the master secret and the session keys from this is then the same as with DH key exchange.

This process of sending the pre-master secret to the server also means that knowledge of the servers private key allows to retrieve the pre-master secret, derive the session keys and decrypt all traffic. This is true even for older traffic if the traffic was captured at some time and the attacker or secret service got access to the private key only later. Contrary to this with DH key exchange no actual exchange of the pre-master secret happens but instead it is derived on both sides. Having access to the private key of the server will not allow an attacker to decrypt the sniffed traffic, i.e. an active and real-time man-in-the-middle attack is instead needed. That's why DH key exchange is the preferred one today and the only one support starting with TLS 1.3.


Is it possible to safely watch a specific folder with virus scan on Windows Server?

Is there any type of virus or malicious file that can execute on its own
  without being manually executed?

As long as something is done with a file the content could trigger a bug (or backdoor)
in the processing software. This means "Yes", eg. the upload to the server could be
enough without you manually clicking on a file.

  Is it possible or would it be sufficient enough to use a Virus
  Scan that "watches"
  just this one folder and scans files immediately?

If it is possible depends on the AV software. But sufficient [to prevent any malicious
actions on the server] ?  Not at all. There is no AV software with 100% percent
correct recognition.

...the only "sufficient" security against malware is to turn the server off and melt it.


Should I chunk or not for AES-GCM file encryption

If you are dealing with text files of size 64 GB or even smaller I believe you should chunk the file and start encrypting portions immediately. This was the former option you mentioned above.

The reason to use GCM vs something like CBC is because GCM can be run in parallel while CBC which is equally secure cannot. If you 'waste' the cpu's ability to start encrypting while it is waiting on the file to load into memory it will be less efficient. GCM is an algorithm meant to be run with " instruction-level parallelism" to refer to the wikipedia page.

You should have the program start loading the file, start encrypting the first 128-bit portion and continue till the whole doc is encrypted.

 Python cryptography docs  and  Pycryptodome docs


How resistant is the iPhone encryption against brute-force attacks?

Apple has quite a comprehensive whitepaper on iOS security.

According to the whitepaper:

  Every time a file on the data partition is created, Data Protection creates a new 256-bit
  key (the “per-file” key) and gives it to the hardware AES engine

Assuming an attacker had a file and nothing else then this would be quite secure.

According to wikipedia:

  50 supercomputers that could check a billion billion (1018) AES keys
  per second (if such a device could ever be made) would, in theory,
  require about 3×1051 years to exhaust the 256-bit key space.

However:

  The per-file key is wrapped with one of several class keys [...] The
  class key is protected with the hardware UID and, for some classes, the user’s passcode.

And

  To obtain the actual key, an attacker would have to mount a highly sophisticated
  and expensive physical attack against the processor’s silicon.

So if you could extract the hardware UID you may be able to then brute force it on the passcode alone. I suspect this would be a significant challenge even for the NSA though and they're probably resort to a wrench instead.

An attacker would also have to be careful if trying any form of online (as in entering the password while the device is powered on) attack because it's possible to set a policy whereby the phone is erased after 10 failed attempts.

  The "Erase all content and settings" option in Settings obliterates
  all the keys in Effaceable  Storage, rendering all user data on the
  device cryptographically inaccessible.

Basically it erases the encryption key for all the files, so then you'd be back to trying to brute force a 256 bit AES key.

Overall I'd say the iPhone is pretty secure considering how difficult it is to secure a device when an attacker can physically access it. Having said that, an iPhone is basically a black box so caveat emptor. There's still the possibility for bugs and vulnerabilities (such as say a weak RNG) or back doors.

When your adversary is someone such as the NSA you also can't discount the possibility of them compelling Apple to sign compromised firmware then physically intercepting the device before it's delivered.


Why isn't Google oauth2 giving a refresh token for Client-side applications?

The OAuth 2.0 specification prohibits the issuing of a refresh token to non-confidential clients. A client-side application is not considered a confidential client.


I see that there are some APIs which exchange some sort public keys to
  secure the content of https connection using asymmetric encryption. Is
  there any added benefit to this? As far as I know, it should be
  impossible to man in the middle a tls connection which have
  certificate pinning.

Have a read of how the whole TLS protocol works, it's a great article available here: How does SSL/TLS work?

In a nutshell public keys are used to allow content that has been encrypted using symmetric keys (keys derived as part of the protocol handshake) to be authenticated.

Man in the middle attacks are not always mitigated due to certificate pinning. For example if the browser has never visited the site before a man in the middle attacker could return their certificate that mentions nothing about pinning.

  The benefit of end to end encryption is clear when the content is sent
  from an end user to another end user, making the backend server unable
  to read it.

No. It only protects the data in transit, when it arrives at the server anything on that server could in theory see the data.

  But I have seen some example where it's just sending data to the
  backend (end client to end backend), but some kind of asymmetric
  encryption was applied.

  For example AWS S3 allows client to encrypt data before sending it. I
  read somewhere that Akamai might also encrypt the content. I have also
  seen some institutions which needs to use their card/keys to encrypt
  the content.

S3 allows client side asymmetric encryption. Which means your local machine is encrypting the data before sending it on to AWS. This only means you, not even AWS, can see the contents of the files. This is for protection of data at rest, not data in transit.

  So back to my question, is there actually any benefit of encrypting
  content using some means (either RSA, or some device), and sending it
  over TLS with certificate pinning?

It depends on your risk acceptance and compliance requirements. But yes encrypting data does not authenticate the data on its own. If you send someone an encrypted file, how do they know it actually came from you? Someone could have used your key. SSL/TLS encrypts but also authenticates the connection, so you know you really are 'talking' to the end point in which you started the communication. The certificate pinning adds assurance that you are indeed getting the same certificate that you did last time, and therefore less likely to be involved in a man in the middle attack.


You can't see the padding in ciphertext because ciphertext is encrypted.

For commandline openssl enc, -nopad has effectively mirror meanings for encrypt and decrypt.

-nopad on encrypt means no padding is added (and the plaintext must be an exact multiple of the blocksize). You obviously did not specify -nopad on encrypt so PKCS5 padding was added by default (before encrypting).

On decrypt, by default PKCS5 padding is expected to be present and is removed; if the padding is not valid an error occurs. -nopad means no attempt is made to remove padding; if padding is present, as in your ciphertext, it is left in the data as you saw. If encrypt was done (successfully) with -nopad you need -nopad on decrypt so you don't try to remove padding that isn't there and fail.

PS- You are aware that single-DES has been broken and obsolete for years now, and ECB mode frequently allows system breaks unless used with great care?

Lessons learned and misconceptions regarding encryption and cryptology

Block chaining modes to avoid

How are chosen plaintext attacks against ECB implemented in the real world?

https://crypto.stackexchange.com/questions/12510/ecb-weakness-and-its-exploitation

https://crypto.stackexchange.com/questions/11451/can-ecb-mode-really-leak-some-characters


Does overlaying the mouse on a virtual numeric keyboard really protect against keyloggers?

These kinds of password entry systems are only good as long as the attackers do not adapt. It is a play in several acts:

Bank Web sites use passwords which are entered the traditional way, with a keyboard.
Key loggers appear, and harvest key strokes.
After some cases of actual bank password theft, banks adapt. They implement "visual keyboards" in which the user clicks on some buttons which are labeled with letters or digits.
After some time, attackers adapt. New-generation key loggers also record mouse click coordinates. These coordinates are sufficient to recompute the password.
After some time, banks adapt. They now "shuffle" the labeled buttons so that they do not always show up on the same emplacement on the screen. Mouse click coordinates are no longer sufficient to recompute the password.
After some time, attackers adapt. Next generation key loggers now take local screen shots, recording the pixels which are around the point where the user clicked. The screen shots are sufficient to recompute the password.
After some time, banks adapt. Instead of clicks, the bank's Web site will react to some "hovering" without an actual click. The current key logger generation does not record "hovering", only clicks, so they are defeated.

As you observe, we are currently at that point. Can you guess what is going to happen ?

This is an arms race. The attackers force the banks to apply more convoluted password entry methods. The banks train attackers into defeating increasingly "secure" password entry methods. Simultaneously, banks try to train their customers into dealing with more complex password entry methods. In the long term, my bet is that attackers will evolve faster than customers; the banks fight a losing battle.


Can a malicious actor lock the real user out by deliberately trying incorrect passwords every X minutes?

Login brute-force protection can be enforced in three ways:

Temporary Lockout
Permanent Lockout
CAPTCHA

In my perspective, CAPTCHA is the most reasonable solution to avoid the risk of bruteforce as well as denial of service due to account lockout. You might have seen a CAPTCHA appearing on the login pages of Facebook and Gmail in case you enter wrong password more than three or four times. That's a decent way of restricting bots from bruteforcing and at the same time avoiding locking users out.

Permanent lockout is not a novel solution, and it adds a lot of operational overhead to customer support team if they have to manually unlock the account for the user. Temporary lockout on the other hand deter bruteforcing, but like the scenario you mentioned, it can lock out a genuine user.


Threat modeling a network monitoring software

Many NMS systems work better when deployed using simple network management protocol (SNMP). SNMP allows for greater detail in data versus inference. E.g. without SNMP, the NMS tool relies on aggregating bandwidth and connections it sees, versus using SNMP where it can access the router and query an interface. So what is at risk here:

Routes: In segregated environments, there are VLANs, multiple routes sometimes to different providers, destinations, and so forth. As an attacker, I would always be interested in those routes, it helps me discover more of an attack surface.

Systems: Where I would have to manually discover what is on the network, the NMS makes is simple for me because it is a single source of discovery versus me having to fire off say NMAP to discover everything on my own. This keeps my network noise minimal.

Versions: Along with systems, and routes, the NMS makes my life simpler as an attacker since most NMS systems contain versions of software and systems. Rather than performing system fingerprints, I can just query the NMS system for specifics. E.g.: "Which of these 1000 systems are Windows 2003 systems, and what is their patch level? (To be used for isolating exploits).

Credential Reuse: Many organizations forget about credential re-use. The more accounts on the NMS the higher the likelihood someone is re-using their credentials. E.g. username (on NMS): jsmith password: Passw0rd1 in this situation a junior admin has an account on the NMS. His password was cracked, and now I as an attacker can use that password to pivot around the organization. Depending on how you have your NMS configured, it may be possible to access an NMS, and get all the data I need without accessing say an Active Directory server.

There are plenty of issues with NMS systems regarding what, and how an attacker can leverage that data. I love targeting NMS based systems, and often find that organizations who deploy them, do not address these issues. (Segregation, isolation, monitoring)


Do you know any .xry reader for MacOS/*BSD or Linux?

Xry only works on XP sp3, and 32 bit Vista or Win7. It doesn't like 64bit OS.


media uploads and social sites group privacy etc

This question dives deep into the AAA stack of identity and access management so we can start there.

Authentication
Authorization
Accounting

In a well defined AAA system you have to determine a method to evaluate the status and sensitive of many objects and entities. Users, computers, pictures, and other forms of data within a AAA system need to be properly protected through these methods. There are many ways to do this including the use of databases, file meta data, ACLs and more.

To make this example float, I'll use google drive as my main focus. On google drive, every document you create is given a specific URL which can be shared around the globe. However, as the file creator you get to determine who has what type of access. For example, you can state that the user must be logged into google through a specific account. You can further state that some individuals who are logged in only have read permissions while others have write permission. How this is stored is not the biggest concern, but I imagine they use some form of a database engine to track this ACL.

Continuing this example, I've now created a file with a specific AAA policy. I have created a policy that requires people to log into google (Authentication), and I've created a specific set of people that are allowed to view or edit the file (Authorization). Google, will then enforce this policy such that even a user with the correct URL cannot have access without first Authenticating and being authorized. Assuming there are no breaches of security, this file is now secure to the people I have authorized.

This is where security becomes a major factor. If google doesn't apply the AAA framework appropriately, my files can be exposed. In fact, Google actually had a recent data leak because they failed to enforce AAA properly. It's not that they couldn't have secured the data, it's that something was missed and users were able to see data they should not have because the Authorization mechanism was not responding properly.

So, in summation, AAA security is a lot more complex than having a GUID or URL when applied properly. Through various means, files and users are given attributes which can be used to evaluate who has access, what access they should have, and even why. It is then up to individuals, companies, and governments to hold the AAA system owners accountable for security and remediation of failures to prevent the implementation of poorly designed systems.


Not enough information to ascertain the likelihood of it being malicious or signs of a breach. It wouldn't be uncommon to find a bash script that is coded to backup a directory but not be regularly invoked. Where was the backup going to? If it is the local system, it probably is just an incomplete  sys admin attempt at implementing a backup. If it is backing up to a local file system, then I'd be concerned.

Regarding the links in /var/www/ to files in the etc. directory, sounds like someone did not install apache httpd from the package repo of their distribution, and instead manually installed. Then they probably were perplexed the config files are not in /etc (which is where they would have been located and referenced if installed as a package). So then they moved the files to /etc and put links in place.

It wouldn't be a bad idea to verify the integrity of the httpd install, and make sure it is running  an un-tampered version. Probably not malicious but simply signs of an inexperienced sys admin.


How do I log everything a certain program is doing?

In case you are using Windows, you can use Process Monitor to find out which files and registry entries the software is accessing. And for the sites it is visiting (request and responses) you can use some proxy, I personally prefer Fiddler. You can also use the TCPView to check the active connections opened by the SW.

You also can use Wireshark to monitor network activity and set a filter to show you just the communication with the server you want. Or you can use Microsoft Network Monitor, which can display communication for specific process.


How can LetsEncrypt and other similar services verify ownership of a domain over insecure http?

couldn't somebody do an MITM attack to give letsencrypt the response it wants without actually owning the domain?

Yes, someone who knows the response Let's Encrypt expects could provide it. But, the response is created by using a private key only known to the owner of the server where the matching public key is known by Let's Encrypt. Thus it is practically  impossible for some man in the middle to guess the correct response.

For more details see How It Works from Let's Encrypt which includes the following description:

  Along with the challenges, the Let’s Encrypt CA also provides a nonce that the agent must sign with its private key pair to prove that it controls the key pair.

Of course, if the attacker fully controls access to the domain he can create a new account with Let's Encrypt and get a certificate for this domain. But in this case the attacker is essentially owning the domain not only from the perspective of Let's Encrypt but also other third parties.


To identify its client the ISP normally needs its full IP address. But... they may have their own logs. In fact, depending on the country, they may have to keep logs for some month in case of legal investigation.
In that use case, knowing the dates, and the destination site should be enough by comparing that information with what they have in their own logs (exact IP, date and destination). Once the exact IP is identified, they know which client is responsable, and can (must) give that for the legal action.


Your ISP will not see the /FOOBAR. This is because you will request facebook.com or www.facebook.com, which is a feature of DNS. This part is not encrypted and only serves recovering the IP of the webserver for the given domain name. When your browser requests this domain name it will not include /FOOBAR as this is not part of the fully qualified domain name.


What does the "period" of a random number generator measure?

As others have explained, the "period" measures the number of output bits (or "words", depending on terminology) after which the PRNG begins to repeat itself. For some PRNG this is relatively ill-defined. A PRNG is a deterministic algorithm with a state (the contents of its internal buffers and counters and variables). The sequence of subsequently emitted bits entirely depends on that state. If the PRNG uses a finite state (i.e. it fits in a fixed amount of RAM, without unbounded dynamic memory allocation) then it will mathematically begin repeat itself at some point, because there are only finitely many possible values for the complete state.

Not all PRNG are reversible. The PRNG is deterministic, meaning that from a given state value S, the next output bit and subsequent state S' can be unambiguously computed. A reversible PRNG is such that given state S, there is a unique previous state S'' for which S is the successor. LFSR are traditional reversible PRNG.

An example of non-reversible PRNG is the following hash-based PRNG:

We use a hash function h, with a n-bit output.
State S is a buffer of n bits.
To produce the next bit, we compute h(0||S) (hash of the concatenation of a bit of value 0, then S); the first bit of the output is the next bit; then we compute the new state S' = h(1||S).

Please note that this is just an example; I do not claim cryptographic security of that PRNG. Since there are only 2n possible values for S, we must necessarily encounter an already-seen state value after at most 2n+1 steps, so the "period" will be no more than 2n. However, the function which computes h(1||x) from x is not a permutation; it is expected to have collisions. This implies that when the PRNG "loops", it is rather improbable that it loops back to our initial state value. Instead, we expect (on average, depending on the hash function h) that such a PRNG will loop on a cycle of length about 2n/2; and we will reach that cycle after again an average 2n/2 steps. This implies that the first 2n/2 produced bits will (probably) not be repeated.

In that sense, the "period" does not measure all that is to be known about a PRNG. In fact, it is mostly impractical: in the hash-based example above, the "period" cannot be readily measured, and describes behaviour of the PRNG in conditions that will not actually be reachable in practice.

The important point here is that period is not a measure of security. Cryptographers do not care about the period. Period says anything about the security only in the special case that it is so short that it can be realistically explored. However, any period beyond 264 or so is "large enough" and becomes irrelevant.

In fact, if the description of a PRNG talks about the period, then it is a very definite indication that the PRNG was not designed or analysed by a cryptographer, and does not aim at cryptographic security (and usually won't provide it either). Indeed, the Mersenne Twister is meant for big physics simulation jobs, where there is no attacker to defeat except a mindless Nature. Cryptographers are more demanding, since they want to thwart an intelligent enemy who tries real hard to guess the next bits.


Mitigating the risk for a successful ransomware infection

There are different ways to approach this, including:

Mitigation of the infection
Filtering emails better
Educating users

As your question regards the mitigation of a infection, I will keep the other parts short.
Filtering emails
The problem are not only attachments but also html emails that could directly attack the email client - or contain fraudulent links.
Depending on the business, this method may or may not be applicable:
Deploy greylisting in conjunction with an attachment check and SPF and/or DKIM. E.g.

That sender is new to me - it has an attachment. If the DKIM signature cannot be verified, I'm not letting this through.

Mitigating the risks
Again, this depends on your business. If there isn't loads of data being used (and written to), this might be a possibility:
Have a "staging area" for each login session - e.g. the "Documents" directory being the only directory with write access for users.
Then, they may write new files (or open read-only old files and edit them) there - the sandbox get's then migrated to permanent storage with a logout script, changing permissions to read only.
The problem with this is: if the malware uses priviledge escalation, there is a chance it changes permissions and encrypts anyhow.
There is also another question (by me) here that has higher demands on the write access, maybe that helps you.
The key point is to rescrict write access as much as possible - maybe introducing some organizational overhead with manually requesting rights from the sysadmin, but minimizing the damage that can be done.
As FerryBig pointed out in the comments: of course all software should be kept up-to-date at all time (with verified updates) and no software should be used that is discontinued or known to have unfixed vulnerabilities (looking at you, flash!).
User education
Basically, even not-suspicous looking file attachments are a bad idea.
The general rule of thumb would be to not open attachments that are not expected. Cross reference this answer on malware infection, also - unfortunately, also by me.


Are sessions enough to protect a web app

If I understand you right... Imagine I spy on your Javascript inner-workings for a while. Imagine I am able to look for the following:

DeleteUserRecord()
UpdateUserRecord()

And in each, you're matching these IDs to the primary key in the database. For example, your code excutes this: DELETE [record] FROM [table] WHERE [id] = '1234', and your Javascript looks like this: DeleteUser(1234). What if I change it to 1? What if I delete every single user? What if I delete the first user, who could presumably be the admin?

Or what if I were allowed to update a single user's record, but I change the ID to 1 and make myself the admin? UpdateUser(1) instead of UpdateUser(1234)

Sounds like your code might be vulnerable to a direct object reference exploit.

All I need to do is tamper with your javascript request and you're TeH PwNz0rEd. Try reading this thread for a better explanation.


Creating accounts on sites with no security?

Technically, they don't have "no security" - they are just lacking in encryption for connections. It's entirely possible that once the data reaches the server, it is stored in bcrypt hashed password fields, with full protection against XSS, CSRF and any other attack you can think of.

A lack of HTTPS connection just means that the connection between your browser and the server is not encrypted - as @Blub says, this could potentially allow someone with access to intercept or monitor your traffic to steal your password, or to change what you see (by intercepting the traffic from the server to your browser). This isn't ideal, especially nowadays, but for some systems has been considered an acceptable risk - there are probably limited uses for intercepting sites which don't have login areas, for example.

For sites with login pages, though, it's considered a more serious risk, since it can be trivial to intercept some kinds of traffic, especially when using open wifi points.

For StackExchange sites, you should be able to access them over HTTPS by adding the https:// protocol string to the start of the URL - this isn't default due to various issues with subdomains (Meta sites).

And, yes, if you use the same password on multiple sites, a hacker capturing your credentials would allow access to all of them. Don't use the same password everywhere!


What makes this cellphone (and the weird instructions) so privacy-friendly?

Nothing. The phone simply has an option to not your send caller ID (i.e. your phone number) to the person you are calling. Nothing too special about it. In fact a lot of telephone network providers already provide a way to do this, so you don't need a special phone for it. Note that this will not prevent law enforcement from tracing your calls if they want to. All it does is not send your number to the person you are calling.


At what point does adding more iterations to PBKDF2 provide no extra security?

There's no exact answer, and here's why:

Brute Force

We start with a 128-bit symmetric key. Assuming the algorithm (e.g. AES) isn't yet broken, we have to look at power consumption. Assuming 100% efficient computation devices whose technology far exceeds any computer, ASIC, graphics card, or other key-cracking device you can dream up, there's a minimum energy requirement for just flipping the bits to count that high. Wikipedia has done the math for us, and it comes out to, for a 128-bit key, the minimum energy requirement demanded by physics is approximately 1018 joules, or 30 Gigawatts for one year. Obviously with "real" hardware, the requirement would be several hundred thousand times that; more than the energy production of the entire world. So that's well outside the capability of any existing terrestrial body.

But if we move to a 256-bit key, the math gets more serious. Schneier did the math on this one in Applied Cryptography, and it's been discussed here before. To avoid boring you with repeated details, I'll simply cut to the conclusion: our sun does not produce enough power to accomplish this task.

Theoretically reversible computing (which may be possible with quantum computers) could cut the effective bit length by half, making such a project merely beyond the reach of any existing power, rather than beyond the reach of physics entirely. But that's all academic.

The take-away is this: brute-forcing a reasonably-sized symmetric key cannot be done. Not by you, not by anyone.

Equivalent Rounds

So, how many rounds of PBKDF2? If the attacker has to choose between waiting 10 years for the key derivation complete versus building a Dyson sphere around the sun, the PBKDF2 route is still faster. By any practical metric, adding more time to your key derivation means adding more time to the attack, and at no point  does trying to brute-force the key ever become an option (unless the PBKDF2 route also requires an extraterrestrial construction project).

So, where's the equivalence point? When does brute-forcing PBKDF2 require the whole Dyson Sphere setup? The answer is: it depends. See, the whole point to using the hash process in your attack instead of guessing the key itself is so that you try fewer password. If you know the password is either "monkey" or "123456", then you'd rather guess only twice, instead of trying to by luck hit the correct hash in a sequential scan.

So the answer depends on the size of the dictionary your attacker will use in his attack. If he knows the password exact, then he only guesses once. And therefore, the brute-force attack will take exactly as long as the correct login. However long you make that out to be. If he expects to get it in two guesses, then the his brute force will take exactly twice as long as your correct login. If he has a dictionary of 100 words to try, then exactly 100 times as long as your correct login, and if your password isn't on his dictionary, then he cannot ever succeed, ever.

Some Practical Math

So to guarantee that his brute-force attack will be impossible, you also have to guarantee that your successful login will be impossible, because you have to account for the possibility that your password is the only candidate on his list.

If on the other hand, you want to go for a reasonable average, just do some simple division. Lets say you want the brute-force attack to take 1 trillion years. And let's say our password is 14 characters alphanumeric (so 1 out of 1025). Assuming his dictionary is all alphanumeric passwords, that's 1025 password guesses in 1012 years (short-scale trillion), or 1013 guesses per year, or about 316900 guesses per second. That's for a fully-exhaustive pass through the list. Some password will be guessed first and some will be guessed last, we probably care about the average, not the max, so lets drop our guess rate in half. About 150000 guesses per second gets us half way through the list in the same amount of time.

So as long as we tune PBKDF2 such that it takes more than 1/150,000th of a second to guess each password, and we can guarantee that the smallest dictionary our password will appear in is the list of all 14-letter possibilities, then 1 trillion years it is.

Longer Passwords

Of course, 14 character random passwords are hard to come by. With 13 characters that shrinks our password list from from 1025 entries down to 1023, requiring about a 100x slowdown in cracking speed (1500 passwords per second) to keep our 1 trillion year average (technically that 100x is actually a 62x, because that's how many alphanumeric characters there are, but I'm rounding to powers of 10). Dropping another character off your length changes your numbers by another 62x each time.

The moral of the story is that what you're hashing matters so much more than how you're hashing. For example, a 22-character alphanumeric password is a 131-bit key, which even without using PBKDF2 at all is well beyond reason for trying to crack.

Caveat

Bear in mind that if the underlying crypto is ever broken, such that it can be attacked without guessing the key, then that will probably become the attack method of choice. But we know of no such attack in AES, nor do we expect one to ever exist.


Can email be encrypted before it reaches the mail server? If not, is there something that would allow something like this that's being worked on?

Before you go down the road of hosting your own email, why do you want to get rid of gmail?  Is it because of the contextual advertisements,... etc?

Is there another provider that can deliver the privacy and safety you need?  (Microsoft Hosted Exchange, Google Hosted mail, or Hushmail)

When it comes to email, there are two general approaches to protecting the data: encryption-in-transport and encryption-at-rest.  It sounds like you want encryption at rest, so that even if someone were to compromise your server, they wouldn't have access to your information.

S/MIME, PGP, and Microsoft RMS are commonly used to address this need, but it also seems like you also want to store your MTA in what you consider a non-trusted (or vulnerable) location.

  I'm not aware of any standard or RFC that coordinates with external clients that data-at-rest encryption (S/MIME PGP, etc) is required by your MTA.

It may be possible to have your MTA (postfix, IIS SMTP, Exchange Hub Transport, etc) to run an encryption command on every inbound message, and discard the original; but this is a flawed system that can also be attacked by a local compromise.

You should keep in mind what kind of devices you want to read your email on.  Do you want to read your mail on a iPhone, desktop, or have messages processed by a system agent?  Know that custom solutions outside of S/MIME may make it difficult for you to read and respond to your email.

  Is it safe to assume inbound email will reach your MTA, and outbound email will go through Google's servers?

Finally before you decide to switch to your own MTA, make sure all aspects of email security is taken care of. Namely

Is your registrar password sufficiently complex?  (where you purchased the domain)
Is your DNS password sufficiently complex?  (may be different from where you purchased the domain)
Is the inbound MTA able to protect you from directory harvest attacks?
Is the MTA up to date and patched?  (MTA exploits are rarer these days but worth mentioning)
Does the MTA support opportunistic TLS?
Are there antispam/antivirus provisions on the server?
Does it do BATV and DKIM verification on inbound messages?

Look here for some more aspects to be considered when securing email https://security.stackexchange.com/a/982/396


Is disabling sudo password prompt a security risk?

Yes, it's a risk.  Anyone who touches your keyboard can get root access by running sudo and not worrying about your password. Anyone who has an exploit that gets them userland access can instantly get root access using the sudo command. This reduces isolation and increases the effort to recover from an attack or intrusion.


Authenticated Sessions on a Desktop Application

When the desktop application logs in at the server, at the server create a guid/token/authorization key and store it in the database together with the associated account. Then return the token to the desktop application. The desktop application stores the token (maybe even permanently in a file or registry). With every request it sends the token to the server. The server looks up/checks in the database the associated account (and if the token is deleted) and checks the funds and processes the request. If the session should be closed/ended mark the token deleted in the database.

You can also use the tokens in cookies for authentification.

Btw. binding sessions to an IP-address is a bad idea like mentioned many times on this site like when the user switches between mobile internet and landline internet or for many other different reasons.


The new CCMP attack against WPA/WPA2 PSK

To be precise, the "new attack" is an optimization of brute-force, by using a slightly faster way to check whether a key is correct or not, mainly through the knowledge of the first few bytes of plaintext. This offers a speed increase of 50% -- in other words, attacks which took 6 days can now be done in 4 days. To put things in perspective, using a PC from next years will offer the same kind of speedup (but it is cumulative, of course).

The main issue with WPA2-PSK has not changed: the conversion from the password to the cryptographic keys is too fast. It should use the same tricks than for password storage, namely iterating hundreds or thousands of hash function invocations. It would not induce any noticeable slowdown in normal usage, but it would makes things much harder for the attacker.


Tor and Orbot, possibility to add in dynamic AES encryption structure before data is send out?

That cannot be done in any way, because the data leaves the Tor-network on the exit node!
The Data is already encrypted until the exit node where it is sent in plain to the public Internet.
Any encryption added between your Orbot and the exit node doesn't change anything, because it is already there.

If you want to encrypt the data between the client app and the target server, that cannot happen in Orbot/Tor because the client and the server don't know anything about Tor!
There is a widely used standard for transport encryption called TLS. It is used in HTTPS.
Nothing is 100% sure and there are always bugs. But TLS is so widely used that bugs are regularly found and fixed.

For Tor hidden services, the "exit node" usually is your target server, so if you access an .onion URL using Tor, usually all the data is encrypted.

Maybe this graphic from Wikipedia helps you understand (CC BY 3.0 licensed)

Once the data is between the last Tor node and Bob (red arrow) it is outside the Tor network and so you can't encrypt this using Tor!


At this stage there is only known DoS exploits available for it. There is no public exploit what will lead to remote code execution.


How is "security word" safe from man in the middle attack?

Long answer:
This type of security mechanism is not meant to protect against MitM: it's meant to protect against URL mimicry/spoofing/phishing. Example:

Users receive a spam message which looks like it's from "Legit Bank"
Spam message contains a link to "Update your information", hosted on a criminally-controlled server
Users enter their information, fooled by the convincing website

This security mechanism is meant to help end users verify that the site they're visiting is legitimate, without having to teach them the logic mechanisms behind how to identify phishing emails or spoofed/mimic URLs.

Additionally, the sophistication required for this kind of MitM would exceed the return from ordinary bank fraud. Simply put, if you're that good, it's not worth your time or risk to go after end-users.

Short answer: No, it doesn't protect against MitM.

Edited for brevity.


Choosing an authenticated encryption cipher mode without associated data

I came across the beginning and the end of this question:

Basic comparison of Modes for Authenticated-Encryption
(IAPM, XCBC, OCB, CCM, EAX, CWC, GCM, PCFB, CS)

This document was perfect for this question and many others, and I'd mark it as the answer if that didn't seem megalomaniacal.  But it's exactly the type of information I was asking for and I hope it helps.


LFI php://input returning initial argument?

Maybe the your syntax isn't correct inside the system function, and the error output isn't printed. Try your request in the web browser buy using the source mode view with CTR+U.
Inside the system function should be called like this:
<?php system(\"echo 'does this work'\");?>


Is it possible to "close" a port by dos'ing it?

You could make the program behind the port unusable. If the given program handles the DoS so badly that it actually fully crashes and thus dies, the program will give up the port, and the OS will reclaim it after a moment or two. After that, it's available for use for any application running on the machine. Assuming it has the right priviledge to use that port and so forth.


Risk of eavesdropping when using private and encrypted WiFi network but no TLS

Assuming Eve is not on the same WiFi network and the key is as you say very long + complex and Eve would happen to sniff the WPA2 handshake/sends deauths till she can sniff the handshake. Even then she would have to brute force the WPA2 key before being able to decrypt the packets that she has sniffed as well.

So if she is not connected Eve will need a lot of computer power to pull it off and that would still be impossible at this moment.


Why don't browser DNS caches mitigate DDOS attacks on DNS providers?

You are correct that the DNS cache would mitigate against a nameserver being unavailable.  It is extremely common to have a TTL of 5 minutes or lower.  Hence, 5 minutes after the DDOS attack brought down Dyn, your cache would've been invalid and you wouldn't have been able to hit github, etc.


How to prevent browser from rendering malicious content if request or response is hacked?

If the request to your domain is HTTPS (e.g. https://example.com) this is effectively immune to a MITM attacker (corporate proxy issues aside). If an attacker redirected example.com to the IP of their own site then their own site would not have a trusted certificate installed for example.com so the user would get browser warnings and would be strongly discouraged from accepting the ceritificate and browsing to the site.

The only way round this for the attacker would be to gain a copy of your certificate with the private key, or somehow have their own trusted certificate for the domain which would be very difficult to do. And if they can do this by breaking into your server, then they win anyway. Bottom line - have trust in the Public Key Infrastructure of X.509. Read up there for more information on how this works.


Why are my gpg public key on my machine and on the key server different?

There are lots of reasons for this.

Keyservers can modify the order of your keys, signatures, ... occuring without changing the meaning of the data
Lots of keyservers ommit picture UIDs
The keyserver could know more signatures on your key than your local keyring does

You may not compare the contents of the (binary|ascii armored) version of your exported key by comparing them directly, only reimport them and compare the output of eg. gnupg. Remember sorting is irrelevant.


My favorite RESTful client is httpie (from Python sources). Easily get it via easy_install httpie or pip install httpie. There are a few REST clients/debuggers as Firefox add-ons (search via addons.mozilla.org).

While at a certain company, I recall using a WebInspect feature called "custom parameters" against RESTful Web Services, such as the REST-WS demo in the Maven Security Web Security Dojo virtual machine or the OWASP GoatDroid Project's use of JAX-RS. If you also have access to the Fortify SecurityScope product, you can use use it to automatically create a WADL which in turn can be consumed by WebInspect RT. When testing large apps (e.g., greater than two million lines of code), this can be especially useful -- voice of experience here.

When you look at the SecToolMarket report, most of the tools that have under 9 input vectors cannot handle RESTful Web Services very well, and even the best ones (Burp Suite Professional, NTOSpider, IBM Appscan, etc) don't have a clear path to testing these interfaces/APIs. This is often why you'd want to use a tool like httpie (or curl) through them as an intercepting proxy, along with the appropriate API documentation (probably preferably in WADL format).


Possible ways for hackers to alter kernel behaviour without root

There's not supposed to be any way for unprivileged users to modify the running kernel. The two ways that such an attack could happen are either to first exploit a bug in a privileged service or setuid binary to give them root (such as CVE-2010-1646, the secure path vulnerability in sudo), or to exploit a bug in the kernel itself (such as CVE-2017-6074, the DCCP double-free vulnerability).


Limit web-browsing to list of known well-known websites (whitelist)

Assuming you are using windows machines (I think there is a way to it in Linux too), the old school way to do it is to point blacklisted sites to a dead IP address in your lmhosts file.

This article explains it better than I can and includes some links to sites that publish blacklists.

blacklist LMHOSTS site


what does 0day vulnerability specifically mean?

There is pretty good explanation on Wikipedia (bold mine):

  A zero-day (also known as zero-hour or 0-day or day zero) vulnerability is an undisclosed computer-software vulnerability that hackers can exploit to adversely affect computer programs, data, additional computers or a network. It is known as a "zero-day" because it is not publicly reported or announced before becoming active, leaving the software's author with zero days in which to create patches or advise workarounds to mitigate its actions.

A real-world example dates back to three quarter centuries ago.


How to change the default/preferred SSL cipher in Linux?

There are various SSL stacks used in Linux: NSS for the Firefox and Chrome and usually OpenSSL for the rest. While OpenSSL has its DEFAULT ciphers which are compiled into the library several users of OpenSSL use their own cipher sets. Notably languages like Python, Perl, Ruby have all their own preferred cipher sets coded into their various libraries.

Which means, that there is no central place where you could change the ciphers used by all application. You have to do it mostly for each application separately.


Sending Encryption/Decryption keys over HTTPS

HTTPS (or TLS in general) can be used to send the secret to the clients in a secure way, i.e. protected against sniffing and modification. But, it needs to have some form of authentication in order to protect against man in the middle attacks (which might sniff or modify the secret). Authentication is usually done with a certificate which the client must either know up-front or where the client can derive the trust because it was signed by a trusted issuer.

Diffie-Hellman alone is not enough to exchange the key since it is missing the authentication part. In fact, TLS commonly (but not always) uses Diffie-Hellman as key exchange itself but also does server authentication.


Is apache mod_spamhaus still being maintained?

I've been in the hosting industry for years now and I've never even heard of these 2 ever being brought up in the industry by other professionals. Honestly, I would consider them "dead". Not too mention that the idea of blocking at Apache's level is not the best. You can better block IPs at the firewall and prevent them from hitting the server all together.


How to enable a http post form penetration test?

it looks like you've put the port option (-s) after the HTTP Post form URL and as a result Hydra is ignoring that option.

If you look at the error message you can see it's trying to connect to port 80 (the default)

[ERROR] Too many connect errors to target, disabling http-get://localhost:80

I'd try moving that -s option to earlier in the command line, that'll probably sort it.


Hiding the salt for key derivations functions

What you are doing is a building a key derivation function and you seem to understand the basics. However with any KDF there's some "secret". Salts are as what you mentioned, used to prevent rainbow table attacks, they are not considered "secret".

Rather than making it so difficult for yourself, you should look into multi-party or group encryption.  Group encryption algorithms strive to achieve the following: a given message is encrypted, and may be decrypted only if sufficiently many group members collaborate.

Have a look at this post on crypto stackexchange as well


Is there a strong protection against CSRF executed from the sames server via stored XSS?

Due to the Same-Origin-Policy(SoP), CSRF and XSS have a kind of rock-paper-scissors relationship.  All CSRF prevention methods rely upon the SoP, and XSS in a fundamental bypass of the SoP.   In the case of reflected XSS, you need a "cross-site request" in order to deliver the JavaScript payload,  so in this cases a CSRF token can make reflective XSS unexploitable.

With XSS you can read any page with an XHR, which can be used to obtain CSRF synchronization tokens. Captchas are not safe either, because they can be solved remotely using XSS (a beef tunnel will do the trick).  With XSS you can also obtain passwords with phishing, or trick the user into authorizing actions on the attacker's behalf.

Let me be clear,  There is no method of CSRF prevention that can protect against an SoP bypass.  A persistent-XSS vulnerability is one of the best SoP bypasses available to the modern attacker.