Can I trust large companies like Google not to store failed password attempts? Let's say, for example, that I accidentally entered my Microsoft account password instead of my Google account password when logging in to some Google web service. After getting an error message, I entered the correct password. Since the connection is HTTPS, only the Google authentication service¹ should have "seen" my Microsoft password.

How badly do I need to change my Microsoft account password after this incident?² Is there maybe some kind of certification that those companies undergo that can give me some confidence that failed password attempts won't be logged?

¹ ...and, obviously, the NSA, but if they want to access my Microsoft account, they can just directly ask Microsoft.

² I am aware that changing passwords regularly is good practice, so let's pretend I'm asking purely out of scientific curiosity.

Nobody can ever tell you to trust or distrust some entity; you, yourself, will need to choose to trust this entity. You already trust Google not to load exploit code in your browser, you already trust Google by actually using their browser (Chrome), you already trust Google with your private conversations (GMail), your embarrassing search terms (yeah, they know what you like).

You see, whenever you have a question like this, simply think "Do I really matter?". The answer is most likely "No". You're nothing, you're a droplet in a sea of information. Every conversation you've ever had with anybody, every memory you have, every SMS you sent, every phone call, every email, every photo, all of them put together are less than 0.000000(a bunch more zeros)001% of the data Google and other big entities have and work with.

So, should you trust that Google will not store your failed password? I don't know. Should you trust that the NSA will not have access to that password? I don't know. But here's something I know for sure: The NSA don't really need your password to access your email, they simply tell Microsoft or Google "This guy... national security threat... send me all of his emails", that's it.

So, worrying about it doesn't matter very much. If you really feel like you should worry, then just change all instances of that password. Otherwise, don't think about it and enjoy your day.


Why did spoof email receive a "pass"? And why didn't it show up in the aggregate report? Good Morning All,  I've been thrown into the deep end with a request from my director.  I know little of DMARC and email spoofing in general, but I'm trying to somehow weed out WHY this spoof email "passed".
It's coming from some "awoofmart@gmail.com" with the display name of one of our VPs.  :(

I'm also concerned because the aggregate report did not include this email... I searched through Jan 31, Feb 1, and 2.  Where did it go?

See below...  I'm actually not 100% what is "Safe" to share from the email header, but the info below seemed safe enough to post (I x'd out the employees name and our domain). Please let me know if I revealed anything I shouldn't have  (locking stable after horse has bolted, I know).

Any help would be appreciated!

Delivered-To: XXXXXX@XXXXXXs.com

Received: by 10.200.57.59 with SMTP id s56csp1949294qtb;
        Tue, 31 Jan 2017 06:53:50 -0800 (PST)

X-Received: by 10.55.72.210 with SMTP id v201mr26460280qka.145.1485874430676;
        Tue, 31 Jan 2017 06:53:50 -0800 (PST)

Return-Path:

Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com. [2607:f8b0:400d:c0d::242])
        by mx.google.com with ESMTPS id g56si12092937qte.273.2017.01.31.06.53.50

for

(version=TLS1_2 cipher=XXXXX-XXX-XXXXX-XXX-XXXXX bits=128/128);
        Tue, 31 Jan 2017 06:53:50 -0800 (PST)
Received-SPF: pass (google.com: domain of awoofmart@gmail.com designates 2607:f8b0:400d:c0d::242 as permitted sender) client-ip=2607:f8b0:400d:c0d::242;
Authentication-Results: mx.google.com;

dkim=pass header.i=@gmail.com;

spf=pass (google.com: domain of awoofmart@gmail.com designates 2607:f8b0:400d:c0d::242 as permitted sender)
 smtp.mailfrom=awoofmart@gmail.com;

dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com
Received: by mail-qt0-x242.google.com with SMTP id s58so19260189qtc.2
        for ; Tue, 31 Jan 2017 06:53:50 -0800 (PST)

While you consider this email as spoofed it is actually not, or at least not really spoofed. It comes from a valid gmail account which has no relation to your company. And the only "spoofing" which was done is that the owner of this account has set the name of your VP as its own name so that it shows up as sender.

Google does not know what the real name of the person setting up the account is. And Google does not know that your VP needs some special protection so that nobody should be able to use its name. And Google does not know that your VP would never setup a gmail account. So nothing is actually wrong with this mail from the perspective of Google and that's why it passed all the checks.

The only one which could consider this mail as suspicious would be your company because you have the name of your VP and you know that the name might be misused to trick users. That's why you should have your own mail filtering system and feed it with such information so that it can protect you with your knowledge.


What types of vulnerabilities just can't be located by a default scanner? If I'm wiling to test a web application.

For what types of vulnerabilities can't a application scanner scan and where can't a application scanner scan (eg. in what property) by its most "forces"?

Scanners such as Vega, Nikto, Burp.

Automated scanners, especially with out-of-the-box configuration, can only identify low hanging fruits at best. What types of attack vectors are covered, depends on the individual tool.
This leaves a broad range of attack vectors that are not covered, which will most likely fall into one of the following categories:

Business Logic Vulnerabilities
Security Scanner do not understand your business logic. A typical example is a web-shop that allows an attacker to manipulate the price during checkout. A scanner cannot know that changing this specific value results in a loss for the company selling the product.

Multi-Stage Vulnerabilities
Some vulnerabilities need several distinct steps before they can actual trigger. If you must perform multiple steps to get the application in the right state to exploit a specific vulnerability, the automated scanner will very likely miss it. Complex authentication and authorization protocols like OAuth and OpenID Connect fall into this category as well. Exploiting those often requires several complex steps.

Compliance Violations
Security problems are not always purely technical in nature but can also be compliance driven. Lets take a vulnerability that allows a user to see PII of other users by circumventing a search filter. An automated scanner cannot identify the nature of the data and also doesn't know that access to this data is a violation to the GDPR.

Violations against security design principles
There are security risks that are not immediately exploitable, but leave open the potential for attacks once the stars align. They often stem from neglected security design principles. This could be the violation of the principle of least privilege. Users that have more permissions than required might not be able to compromise the application right away, but under the right circumstances (e.g. a 0-day in an API that shouldn't be accessible with proper defined access restrictions) this negligence leads to an actual security problem. A scanner cannot foresee such scenarios or even identify violated security principles.

Vulnerabilities that need access to the source code or configuration
Many security scanners use a black box approach. They do not know the source code or the configuration of the system. There is a broad range of vulnerabilities that can easily be missed without this internal information and are therefore also easily missed be a security scanner.

This list is not necessarily comprehensive. The main message is that there are a lot of issues that cannot be detected automatically at the moment. Relying on a security scanner to verify application security is therefore not sufficient for most applications.


How to deal with websites with poor encryption? I'm trying to access a website over HTTPS. However, it appears that it uses weak encryption: specifically, RC4.
Is there a way to improve the security of my connection to the website? I've been looking into Tor, but unfortunately all exit nodes appear to be blacklisted on the website I'm trying to access.

Part of the SSL Handshake is to determine the cipher to use during transmission.  The cipher suite order can be set server side.  Is RC4 the only algorithm being used?

You can disable the algorithm on the client side by editing the registry.

See this link.  MS published an update to disable RC4.  I also believe you can use a tool called iis crypto to edit your registry.

For firefox, it seems like you can control the SSL ciphers via the about:config page.  Look for security.ssl3


Ransomware-resilient Linux Samba file server Imagine the following scenario:

Files are kept on a Linux server and clients access them via Samba.
One of the client machines gets infected with ransomware, which encrypts everything within the logged-on user's reach, including files on the server's shares.

I am curious as to whether there are any solutions (apart from regular backups) which would allow for full and easy recovery from such attacks.

A rough design I had in mind would be based on some kind of snapshotting/version management:

Whenever a file is changed or deleted, keep a copy of the old version around somewhere.
These previous versions would be read-only for ordinary users, protecting them against tampering by any kind of ransomware running on client machines.
Previous versions would be available via a special path, e.g. a previous version of /home/john/path/to/file.odt would be in /home/john/path/to/~snapshot/20161120_163242/file.odt.
Some kind of mechanism to revert entire shares to an earlier state.
Optionally, heuristics which detect suspicious activity (e.g. large numbers of files being read, new files of similar size being created and the original files being deleted, or large-scale modification of files) and trigger appropriate actions (alerting the admin, blocking write access).
Protection should not rely solely on particular characteristics of known ransomware – while these might work against those particular trojans, they could easily be totally useless against future ransomware that is implemented in a different way.

Is there any software that does this kind of thing, runs on Linux and is FOSS?

I think backups are your only sure bet. What you suggest as a solution basically consists of making a special backup; I'd suggest you just keep several (at least two) full backups around. The problem is then reduced to detecting ransomware working on your files and recovering from the last good backup. You can use deduplicating backups to save space. The advantage of going the backup route is that

you introduce less complexity (no additional system just for ransomware)
you improve the quality of your backup routine - once you're automating alerts and recovery, you've put in place a lot of stuff to make backup recovery a breeze. That's good for a much broader category of failures than just ransomware.

As for detecting ransomware, that's easy: Encrypted files all look like random data, so you can simply do statistical tests for each file (equal distribution of bytes? not compressable using zip? etc) and count the number of files that look random.


Why an attacker would use a trojan over a spyware? I'm trying to figure out some possible attack scenarios for a project I'm conducting.
I've read plenty of material about malware and, in particular, spyware and trojans. While it's hard to find unique specific definitions for both of them, which however I'm not really interested in, I came to the conclusions that, roughly speaking:

Spyware: log activities and steal information;
Trojans: give remote control of a system to the attacker, to perform a broad variety of malicious actions, possibly including stealing information and logging activities.

Considering this somewhat correct (I hope it is), I'm trying to find some possible motivations, if any, to use RATs instead of spyware. Although I know other common features trojans have, those don't fit well my work.
Are there motivations to prefer a trojan over a spyware if there is no interest in taking control of the infected system ?

See this answer for some musings about the definitions of such terms, and, in particular, how fuzzy and mostly irrelevant they are.

If we really want to make distinctions, then:

A spyware is some software which spies on the user.
A trojan is some malicious software which gets installed by the victim himself, who was deceived into thinking that the software was benign.

So the two terms are not opposite at all ! In fact, they are orthogonal. A given piece of malware (the generic term, meaning "malicious software") can be a trojan or something else (depending on how it enters the victim's computer), and can be a spyware or something else (depending on whether, once there, in engages into spying activities).

In older times, malware was mostly virus (i.e. malware which propagates by grafting itself on executable files exchanged between computers) and worms (automatic exploit of network-based vulnerabilities). Some had no payload, they just replicated for the fun of it; but most tried to be destructive, wiping out files and operating systems, and even breaking the hardware. Nowadays, a lot of malware exploits the gullibility of the human user (that's much easier than relying on some exploitable vulnerability), making up the large "trojan" category. Also, most malware tries to be inconspicuous: typical malware does not try to break your machine; instead, it silently siphons out your secrets (e.g. passwords).

"Taking control" is not a well-defined category. By definition, malware running on a machine is "controlling" it, if only transiently. Most malware will include some backdoor so that the malware author can use an installed malware instance as an entry point for pushing new attack code, whether such an escalation is actually planned or not.


Securing communications in decentralized network of servers Lets consider the following setup:

  One has a decentralized network of servers. A single root certificate has been distributed to all servers which has been positively checked as authentic and untampered by each server owner using checksums distributed all over the internet. Each server connects to a centralized server (secured by the root certificate) over HTTPS and requests the signing of a certificate for itself, which is provided as long as it proves ownership of its domain. From that point on the server uses that certificate to identify itself and communicate over the network. Certificate pinning is used by all servers in the network and a new certificate is only accepted after the green light of the local server owner.

The problems this tries to solve:

Secure the network against MITM attacks and eavesdropping, as my understanding is that the only real alternative consists of a manual exchange of keys between each server pair (or in WoT construction, which I deem similarly weak).
The fact that requesting every server owner to pay for SSL certificates is unrealistic.

What would the main be weaknesses of such a setup in light of the problems it tries to solve? And what I am especially curious about is whether temporary full access to the centralized server infrastructure would theoretically allow long-term eavesdropping on and/or tamperering of communications between servers.

In light of the broad question I will concentrate on answering your more specific one regarding full access to the centralised server. I'll refer to said server as a CA because this is essentially what you are describing.

TL; DR it depends

Let's presume that full access means knowledge of the CA's private key. This may not always be the case if we consider HSMs as against a simple server, but that makes this a boring question. Such access to the private key will then allow an adversary to sign arbitrary certificates which are automatically trusted by all network members regardless of their false claims of ownership.

Eavesdropping implies passive listening on the network. Even with CA compromise only ciphertext is visible to the adversary as individual servers have never published anything beyond their own public keys. They are assured of communications with the true owner (whomever that may be) of a specific public key; being passive implies that there is no such change of end-point keys.

An active involvement as a MITM would allow both eavesdropping and tampering through impersonation.

As a side point; in the case of (EC)DHE usage, even knowledge of individual server private keys would be protected against passive eavesdropping as a MITM would have to intervene to establish shared secrets with each party.


What security features are important when buying a smartphone? I'm looking at replacing my very old android smartphone. Information security is increasingly a feature that I'm looking for. As well as being slow, I don't think I can upgrade my current handset to the latest android versions or even the latest version of the mobile security app I use, so almost anything would likely be an improvement.

Ideally I'm looking for a handset or ROM which has security (ideally encrypting data in communication and at rest) as a priority and will likely still be secure (with updates) in several years' time. I'd prefer an android solution, unless security on other platforms is significantly better/easier to achieve.

Is the choice of handset a significant consideration, or is security mainly down to the way it is used - regular updates, careful checking of apps before installation?

  PLEASE NOTE: I am not looking for a specific recommendation, but
  rather guidance in knowing what to look for. Feel free to pop
  recommendations in the comments - but NOT the answers.

TLDR: There are several categories of security you must consider when looking for a phone. The main advice, though, is to get a newer phone with the latest security features, and from a manufacturer that has a good reputation of providing updates.
Security against other people (peers, police/government)

Look for newer devices with full disk encryption, and at the very least have a code or fingerprint required to unlock your device.

Both Android and iOS have the ability to encrypt the phone. When booting the phone, the password must be provided to finish booting and to view files.

Upside: Your phone is protected from external attempts to read the data
Downside: You must type in your password/PIN every time you boot, and usually every time you unlock your screen.

As this is built-in to more recent versions of Android and iOS, you must slightly narrow your search to exclude older phones that don't have this capability.
Encryption key vs unlock code
As a usability/security tradeoff, I prefer to have a long password required on boot, but have a simpler code to unlock the screen. Apple does this natively, letting you set a PIN or password required on boot, but thereafter letting you unlock the phone with your fingerprint.

Upside: You can use a complex password, while keeping the ease of unlocking your phone quickly.
Upside: A shoulder-surfer can't unlock your phone, since your fingerprint unlocks it. They would have to catch you as you type in the password on boot. (When you type your password, be sure no one is watching!)
Downside: Your fingerprint is not protected by law (in the U.S.). The police can force you to unlock the phone with your fingerprint. Whereas a password or code, something you know, cannot be forced out of you. Even if a court orders you and holds you in contempt for failing to provide the unlock code, they cannot access your data without your cooperation.

On a rooted Android device, you can install a mod that lets you have a complex boot password and a simpler PIN for the screen unlock. If you enter the PIN incorrectly, it requires the strong password to be entered, which prevents brute-force attempts at the much simpler PIN. You are losing some security, however, since anyone shoulder-surfing could see you put in your PIN and later steal the phone for unlocking.

Upside: You can use a complex password, while keeping the ease of unlocking your phone quickly.
Upside: Only your knowledge can unlock the device.
Downside: You must enter a PIN every time you unlock the screen. As this happens frequently, it is much more likely that someone could find out your simple unlock combination.

Security against apps

Check app permissions before installing, and make sure you get a newer phone that has extra permission management.

Apple/iOS
Apple devices (excluding jailbroken ones) can only install apps that have gone through Apple's vetting process. While this isn't 100% successful, it does protect most users from installing a malicious app. On top of that, certain obvious privacy features, such as GPS location and contact info, require an extra user prompt to allow an app to access that information.
Android 6.0+
Android permission settings before 6.0 Marshmallow were all-or-nothing. If an app requested permissions to your GPS, you either allowed it or didn't install the app. Android 6.0 introduces similar features to iOS that let the user deny certain permissions while still installing the app.
If looking at Android devices, this narrows the eligible devices, excluding phones that don't have Android 6.0 or newer.
Android 4.x-5.x with XPrivacy
However, if the Android device has root and can install the Xposed framework, you can install XPrivacy. That app overhauls the permission model on Android so that nearly every possible privacy-related permission can be allowed or denied in real time. If the app tries to use GPS, it prompts you to allow or deny (or provide fake/null information). This is available to most rootable Android devices running any version of Android 4.0 to 5.0.
Look for a phone that can be rooted if you want extreme privacy permission tweaking.
Security against bugs/exploits

Look for phones made by manufacturers with a history of regular updates.

Most iOS and Android updates include bug fixes along with new features. As long as the iOS device is supported, they can all get the update at the same time when it is released.
On Android, Nexus devices are generally the first to receive updates. For other manufacturers, make sure they have a history of providing updates to older phones and within a reasonable timeframe.
Alternatively, find an Android phone with an unlocked bootloader and an active development community. While more technical, this can be the fastest way to get the latest updates, even after a manufacturer has stopped supporting the phone.
Security against the device manufacturer

Buy devices from a trusted manufacturer, and make sure it uses full-disk encryption where the manufacturer does not hold the key. Also, for Android, consider a device with an unlockable bootloader to be able to load custom ROMs with newer security updates and better privacy features built-in.

Apple devices cannot be unlocked even by Apple starting in iOS 8. While it may be possible in theory for Apple to provide an update that subverts this, currently it is impossible for Apple to unlock your phone or gain access to the encrypted partition on your phone. If you have iCloud Backup enabled, however, that data can be accessed by Apple.
Similarly, Android devices with Full Disk Encryption enabled cannot be unlocked by the manufacturer, or even Google.
Unlocked bootloader
With Android devices, an unlocked bootloader lets you install custom ROMs, or even make your own built from scratch using the Android OS source code. If your phone is no longer supported by the manufacturer, you can still update to the latest version of Android, assuming someone has compiled a Rom for your device.
Some Android ROMs have additional security and privacy controls built-in.
Warning: This can be detrimental to security. Make sure to use a Rom that is widely known and trusted.
Security in the cloud

Use a cloud storage provider that encrypts your data and does not have access to the unlock key.

Almost all cloud storage (Dropbox, iCloud, etc) store files in a non-encrypted way, or in a way that the cloud provider could decrypt the files without the user's permission.
The primary way to protect against this is to not use cloud storage. If you need to back up your files, use your own encrypted server or manually copy files onto an encrypted desktop computer.
A few storage providers, such as MEGA and SpiderOak, do encrypt your files. The encryption key is not accessible to them, and a government entity would have to coerce them to write an update to their software in order to acquire the unlock key from a user.
Android and Apple both have apps for MEGA that work similarly to Dropbox, including automatically saving photos taken by the phone.
Security against networks

Make sure your phone can use VPN software, and possibly use TOR to increase privacy. And be sure to browse the web with https when possible.

The internet service provider can view all of your unencrypted network traffic. To help avoid this, use a VPN. Note: the VPN can see your unencrypted data as well. Use a trusted VPN provider.
The ISP can even determine some information from encrypted network traffic, if you aren't using a VPN. If you open a web page that uses https, the ISP can see which domain you are going to. They cannot, however, see the specific page you are requesting, nor the data of the page itself.
If extreme privacy is a need, Tor may be the answer. It has plenty of downsides, the primary being slow speed (compared to normal browsing). But when using Tor, your ISP cannot see your network information, aside from the fact that you're using Tor. And the nodes on Tor are unable to know both the source (you) and destination (the website) due to the way the protocol is designed.


x509 serial number - hex or decimal When I run the openssl command

openssl x509 -noout -text -in certname

on different certs, on some I get a serial number which looks like this.

Serial Number: 256 (0x100)

On others, I get one which looks like this

Serial Number:
        41:d7:4b:97:ae:4f:3e:d2:5b:85:06:99:51:a7:b0:62

The certificates I create using openssl command line always look like the first one.
What do I need to do to create a cert using openssl command line where the serial number looks like the second?

This is just a representation choice for presentation purposes. If it's short enough, it will be displayed both in decimal and in hexadecimal. You just need to use a longer serial number for it to appear in the second format (0x100 would be equivalent to 01:00).

The length threshold to switch to the second representation seems to be size(long)  (usually 4 bytes).


decrypt .asc file from enigmail not work I'm new on PGP and I'm trying to see how It works:

I can encrypt and decrypt files with my keys pair, but If I download an .asc file from thunderbird with enigmail I don't be able to decrypt it. I explain better

I send to my self an email with my (only) public key. Via thunderbird all works, it decrypt automatically the message. There is an .asc attach, too and If I download it and I type
gpg file_name.asc nothing happen.

Why? where I wrong?

EDIT

I made a mistake!
The attached file on my email is the public key. I checked the box to do it

You show the output of a key file. Also the name looks like a key ID. So you did not save the encrypted body but a key attachment.


Is ssdeep FP-prone or FN-prone? A bloom filter can incur FPs (False-positives) but will never incur an FN (False negatives).

If the ssdeep value of two files are pretty close to each other, is it guaranteed that the file contents are pretty close to each other?
Or is it that when ssdeep is completely dissimilar there is no chance that the file contents are similar?

If the ssdeep value of two files are pretty close to each other, is it guaranteed that the file contents are pretty close to each other?

It is not guaranteed but it is very likely. See also the original ssdeep paper where it computes the chance of two random files having the same or similar signature. It is not zero but is close to zero.

  Or is it that when ssdeep is completely dissimilar there is no chance that the file contents are similar?

This depends on what is considered similar. If one for example recodes a UTF-8 file to UTF-16 one might consider the content still similar since it is just differently encoded, but the ssdeep hash will be very different.

If one instead treats the data as octets without any specific semantics and views the similarity as the amount of insertions or deletions, then a very different ssdeep value will mean in most cases a high number of insertions or deletions.

But one can probably create some input where a small change will lead to a large ssdeep difference. This is the case where the small change would lead to a critical change in the length to the signature so that it is considered too small with the original block size in on of the inputs which will cause a recalculation with the block size halved, leading to a very different signature.


How to protect an offline proprietary software from being stolen We are currently developing a software that is supposed to run on every computer of a world wide company which has many domains.
We are thinking about security as we want the software to be used only on a company computer.

A particular remark is that we don't want any online security measure, as the software may be run offline only.

Thinking about serial key is nearly useless as a client who leaves the company may take with him the software (with an already validated serial key) with him and use it in another context.

We thought about checking certificate issuer for a specific certificate in the store each time the software is launched (as for all computers of the company, this specific certificate issuer will be the company name). However, using a fake certificate issuer from a non-company computer will also work...

We know that there is no perfect solution, but we just want the most effective solution.

Thanks !

With hardware, a TPM or hardware security token would be a possible solution, provided that an employee couldn't simply take it with him when he left the company (e.g. a TPM that was part of the processor, or soldered onto the mainboard)

If you want to work only in software and you can't connect to a network, the only way I see is some kind of serial numbers which expire. Let's say that you require the user of the software to enter a serial number. The software then stores the date at which the serial number was entered and works until two weeks later, when the next valid serial number must be entered. If the user deletes the file that stores the date, you require immediate entry of a new serial number. You'll have to consider that a user could reset the date on his computer to avoid having to enter a new serial number, so you'll have to protect your software against that (e.g. make sure that every time you start the application, time has moved forward from the last time you started it, make sure time doesn't move forward in steps that are too small, etc). This is hard and won't ever be foolproof, but should give you some protection, e.g. raise the bar a bit for thiefs.

As Tensibai said in his comment, ultimately this is all pointless, because if there is enough motivation, someone will circumvent all the safeguards you put in place to keep your software from being stolen, and once that's done, it'll probably be downloadable from somewhere on the internet like every other piece of software that does something worthwile.

Maybe a better solution to your problem would be to make it more attractive for the majority of possible thiefs to pay you to legally use the software?


Nmap default scan technique I'm a little bit confused about what is the default scan option for an nmap scan. For example:

nmap -A -p 22

Am I performing a SYN scan or TCP connect scan?

When scanning TCP ports, Nmap will do a SYN scan by default and fall back to a connect scan if the user doesn't have sufficient privileges.

From the docs:

  -sS (TCP SYN scan)

  SYN scan is the default and most popular scan option for good reasons. It can be performed quickly, scanning thousands of ports per second on a fast network not hampered by restrictive firewalls. [...]

  -sT (TCP connect scan)

  TCP connect scan is the default TCP scan type when SYN scan is not an option. This is the case when a user does not have raw packet
  privileges. [...]

You can also use the verbose flag (-v) to find out which exact scan types are being run:

$ nmap -v -p 22 1.2.3.4

Starting Nmap 7.60 ( https://nmap.org ) at 2017-12-11 12:14 CET
Initiating Ping Scan at 12:14
Scanning 1.2.3.4 [2 ports]
Completed Ping Scan at 12:14, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:14
Completed Parallel DNS resolution of 1 host. at 12:14, 0.01s elapsed
Initiating Connect Scan at 12:14
Scanning xxx (1.2.3.4) [1 port]
Completed Connect Scan at 12:14, 0.00s elapsed (1 total ports)
Nmap scan report for xxx (1.2.3.4)
Host is up (0.000070s latency).

PORT   STATE  SERVICE
22/tcp closed ssh

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds

$ sudo nmap -v -p 22 1.2.3.4

Starting Nmap 7.60 ( https://nmap.org ) at 2017-12-11 12:15 CET
Initiating Parallel DNS resolution of 1 host. at 12:15
Completed Parallel DNS resolution of 1 host. at 12:15, 0.01s elapsed
Initiating SYN Stealth Scan at 12:15
Scanning xxx (1.2.3.4) [1 port]
Completed SYN Stealth Scan at 12:15, 0.04s elapsed (1 total ports)
Nmap scan report for xxx (1.2.3.4)
Host is up (0.000045s latency).

PORT   STATE  SERVICE
22/tcp closed ssh

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds
           Raw packets sent: 1 (44B) | Rcvd: 2 (84B)


Burp Suite - Although my configurations are correct, still Chrome doesn't allows me to access HTTPS sites and throws an error! I'm having a hard time accessing sites with HSTS enabled via burp proxy in Chrome. Everything works perfectly fine with Firefox and IE, but Chrome has stopped working since yesterday.

I've followed all the instructions went through all the available documents and have reinstalled the certs and all but no luck.

Screenshots with details about the errors:

As I mentioned, it works fine with Firefox and IE but not with Chrome.

This is probably due to a change in Chrome 58 which now requires SAN:

  Remove support for commonName matching in certificates

  RFC 2818 describes two methods to match a domain name against a
  certificate: using the available names within the
  subjectAlternativeName extension, or, in the absence of a SAN
  extension, falling back to the commonName. The fallback to the
  commonName was deprecated in RFC 2818 (published in 2000), but support
  remains in a number of TLS clients, often incorrectly.

  The use of the subjectAlternativeName fields leaves it unambiguous
  whether a certificate is expressing a binding to an IP address or a
  domain name, and is fully defined in terms of its interaction with
  Name Constraints. However, the commonName is ambiguous, and because of
  this, support for it has been a source of security bugs in Chrome, the
  libraries it uses, and within the TLS ecosystem at large.

  The compatibility risk for removing commonName is low. RFC 2818 has
  deprecated this for nearly two decades, and the baseline requirements
  (which all publicly trusted certificate authorities must abide by) has
  required the presence of a subjectAltName since 2012. Firefox already
  requires the subjectAltName for any newly issued publicly trusted
  certificates since Firefox 48.

The solution to this is to regenerate the certificate on the server showing the error, or as in your case - the Burp cert.


Explanation required on Relationship between "Certificate Type" and "Key Exchange Algorithms" in TLS 1.2 A certificate, in itself, (RFC 5280) does not seem to have any indicator of what algorithm was used (for example the argument to openssl req -newkey) to create the public and private keys ("Certificate Key Type"). That surprised me. A certificate has a "signature algorithm" field but that is the algorithm used by the CA to sign the certificate.
Question 1: Is this observation correct? If so, why is the algo/key type of the certificate itself not in the certificate? After all its type too is required when used.

TLS 1.2 (RFC 5246). The Cipher Suite sent by the Client in the Client Hello has the Cipher Suite in the following form:
TLS_part1_WITH_...
I think only part1 is relevant to the derivation of the pre_master_secret. The part that follows the WITH is for securing the actual data.
Question 2: Is this correct?

part1 is called "key exchange algorithm" (Section 7.4.1.2.  Client Hello)
"The cipher suite... contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first).  Each cipher suite defines a key exchange algorithm..." .
A Client Hello can have a "signature_algorithms" extension. "The client uses the "signature_algorithms" extension to indicate to the server which signature/hash algorithm pairs may be used in digital signatures." (Section 7.4.1.4.1.). For a key exchange, both algos, a signature and hash, are to be negotiated and if there is no signature_extension sent, then the hash is implied from the "key_exchange_algorithm" alone (7.4.1.4.1). So the implied hash algo is not based upon the type of Certificate.

Section 7.4.2. establishes some relations between the negotiated key_exchange_algorithms and the Certificate Type. The RFC lists a table with the two columns. One of the rows from the above mentioned table is:

  DHE_RSA            RSA public key; the certificate MUST allow the
  ECDHE_RSA          key to be used for signing (the
                     digitalSignature bit MUST be set if the key
                     usage extension is present) with the signature
                     scheme and hash algorithm that will be employed
                     in the server key exchange message.
                     Note: ECDHE_RSA is defined in [TLSECC].

Question 3: (Edited: Earlier mis-numbered it as Question 5).
I think understanding this is the biggest hurdle for me. I understand the importance of Ephemerial keys (ECDHE vs. ECDH). The "RSA public key"  refers to the key type in the certificate. Is that correct? Does the RSA in "DHE_RSA"  and "ECDHE_RSA" also refer to the type of the key in the certificate? Is this key only used for authenticating the server? After all, ECDHE by itself, even without a certificate, can generate a common secret known only to the two parties but not to MiM. Can someone explain the role of the Certificate in the various stages of establishing the pre-master-secret?

First, this is a pretty broad question already. Please don't add anymore questions to this and ask for further details in new questions instead.

  Question 1: Is this observation correct?

No. If you do a openssl x509 -text -in cert.pem you can see the public key and also the type of the public key:

    ...
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:be:f2:0e:d5:f5:97:8f:23:e1:89:6d:56:58:97:
    ...

  Question 2: Is this correct?

Depending on the interpretation of what "securing the actual data" means. The part after the WITH in ciphers like TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 describes the method for encryption and integrity protection. It does neither describe the key exchange nor the authentication method. But without proper authentication and key exchange the key used in encryption could be compromised which means that it does not really "secure" the actual data.

  Question 3: ...

You got this mostly right. The RSA/ECDSA in the cipher suite describes the authentication. And in case of ..DHE_RSA_.. or ..ECDHE_RSA.. it also only describes the authentication. There are ciphers like TLS_RSA_WITH_AES_128_CBC_SHA256 though where the key exchange algorithms is RSA and in this case the certificate is also involved in the key exchange.

  Can someone explain the role of the Certificate in the various stages of establishing the pre-master-secret?

The certificate is only directly involved in the key exchange (i.e. establishing the pre-master-secret) in the obsolete RSA key exchange which essentially means that the client encrypts the pre-master-secret with the RSA public key and the server can decrypt it since it has the private key.


Update letsencrypt certificates without changing the private key I want to renew the letsencrypt certificate on my webserver but want to keep the private key same.

I've installed the certificate using certbot 0.35.1

How can I update the certificate (preferably using certbot) without changing the private key?

If possible can I automate this process, for auto renewal?

Create a certificate signing request (CSR) and let certbot renew that, using a command like this:

certbot certonly --csr csr.pem

The CSR contains your public key, so you keep the same key pair with this method.


Could running applets/videos trigger a drive-by download attack? Let us visit a given webpage on which video files and/or java applets are embedded. Could clicking to start on these videos/applets lead to a drive-by download attack ?

Absolutely.

Java applets have been used over and over for drive-by attacks purposes, and although the situation got better since mandatory click-to-play was instated, the applet sandbox isn't a lot more trustworthy than it used to be. By the way, be careful when reading the launch message, because if the applet is signed, no vulnerability has to be used, it will already have full access to your system.

As for videos, Flash also has a terrible track record when it comes to security. A lot of vulnerabilities (CVE-2014-0515 being the latest in date) are used routinely to perform arbitrary code exploitation through this plugin.

Bottom line, the more technologies you cram into a browser, the more vulnerable it gets. The examples you give are perfectly reasonable attack scenarios even if you use a different plugin than Flash to read videos. If you want to reduce your attack surface, don't allow sites that you don't explicitly trust to run code inside your browser (not even JavaScript).


Why does my stack contain the return address to __libc_csu_init after main is initialised? I wrote a simple program in C, compiled it, opened it in gdb, set a breakpoint at line 11 and inspected the stack.

  1 #include<stdio.h>
  2
  3 int main(int argc, char *argv[]){
  4     char arr[4] = "AABB";
  5     int square = foo(2);
  6     exit(0);
  7 }
  8
  9 int foo(int x){
 10     char buff[4] = "CCDD";
 11     printf("Enter a value:"); // set breakpoint for this line
 12     gets(buff);
 13     return x*x;
 14 }
 15
 16 void bar(){
 17     printf("This program was hacked");
 18 }
 19

When I looked at the stack I found that after the main function is initialised but before foo(x) was called it placed 2 addresses for __libc_csu_init on the stack. I understand that every program calls init and fini, but shouldn't those references be placed on the stack before the main function is called?

(gdb) x/16a $esp
0xbffff110:    0x8000    0x44444343    0xbffff148    0x8048442 <main+48>
0xbffff120:    0x2    0xb7fbe000    0x804a000    0x80484c1 <__libc_csu_init+33>
0xbffff130:    0xb7fbe3bc    0x8048218    0x80484a9 <__libc_csu_init+9>    0x0
0xbffff140:    0x1    0x42424141    0x0    0xb7e0c5a6

Why is 0x42424141 at a higher address than __libc_csu_init?

Your main function contains pointer to __libc_csu_init just before its return pointer, because that's how stack frame works;
before entering a function, caller pushes a stack frame pointer and a return pointer.

Return pointer contains an address, to which function will return on
function finish.

Frame pointer contains the address of the previous top of the stack, so it would know to where it should rewind the stack.

Unlike return pointer, stack frame pointer doesn't neccesarily need to be pushed on stack (its address can be stored in registers), but can be helpful for optimization, since accessing some address from current stack would be a matter of substracting from its value.

On the image below, that is example function call stack, stack frame pointer would be pushed where the "Frame pointer" arrow points - author assumed, that it would be stored in register only. If it was your program, it would contain address to __libc_csu_init.

For more information on frame pointers reffer to the Wikipedia article:
https://en.wikipedia.org/wiki/Call_stack

And now, for a proof, let's compile a simple program with -fomit-frame-pointer flag (forces behaviour as in the image above), and without (pushes the frame pointer on the stack, like in your program):

int main(int argc, char *argv[])
{
// placing nop instruction just for readibility of disassembled code
asm("nop");
}

Compiled with no-pie, so PIC would not prevent me from breakpointing:

g++ answer.cpp -o answer -fno-pie -fomit-frame-pointer

Disassembled in gdb, breakpointed on the line with 'nop' instruction and printed first 12 words after stack pointer:

(gdb) disassemble main
Dump of assembler code for function main:
   0x00000000004004b2 <+0>: mov    %edi,-0x4(%rsp)
   0x00000000004004b6 <+4>: mov    %rsi,-0x10(%rsp)
   0x00000000004004bb <+9>: nop
   0x00000000004004bc <+10>:    mov    $0x0,%eax
   0x00000000004004c1 <+15>:    retq
End of assembler dump.
(gdb) break *0x00000000004004bb
Breakpoint 1 at 0x4004bb
(gdb) r
Starting program: /home/xdbeef/answer

Breakpoint 1, 0x00000000004004bb in main ()
(gdb) info registers ebp esp
ebp            0x4004d0            4195536
esp            0xffffdae8          -9496
(gdb) x/12xw 0x7fffffffdae8
0x7fffffffdae8: 0xf7a2d830  0x00007fff  0x00000000  0x00000000
0x7fffffffdaf8: 0xffffdbc8  0x00007fff  0xf7ffcca0  0x00000001
0x7fffffffdb08: 0x004004b2  0x00000000  0x00000000  0x00000000
(gdb) x/12xa 0x7fffffffdae8
0x7fffffffdae8: 0x7ffff7a2d830 <__libc_start_main+240>  0x0
0x7fffffffdaf8: 0x7fffffffdbc8  0x1f7ffcca0
0x7fffffffdb08: 0x4004b2 <main> 0x0
0x7fffffffdb18: 0x161e93edeaec9201  0x4003e0 <_start>
0x7fffffffdb28: 0x7fffffffdbc0  0x0
0x7fffffffdb38: 0x0 0xe9e16c9256ac9201
(gdb)

As you see, the first and only address on main's stack frame was the return pointer.

And now with frame pointer:

g++ answer.cpp -o answer -fno-pie

(gdb) disassemble main
Dump of assembler code for function main:
   0x00000000004004b2 <+0>: push   %rbp
   0x00000000004004b3 <+1>: mov    %rsp,%rbp
   0x00000000004004b6 <+4>: mov    %edi,-0x4(%rbp)
   0x00000000004004b9 <+7>: mov    %rsi,-0x10(%rbp)
   0x00000000004004bd <+11>:    nop
   0x00000000004004be <+12>:    mov    $0x0,%eax
   0x00000000004004c3 <+17>:    pop    %rbp
   0x00000000004004c4 <+18>:    retq
End of assembler dump.
(gdb) break *0x00000000004004bd
Breakpoint 1 at 0x4004bd
(gdb) r
Starting program: /home/xdbeef/answer

Breakpoint 1, 0x00000000004004bd in main ()
(gdb) info registers ebp esp
ebp            0xffffdae0          -9504
esp            0xffffdae0          -9504
(gdb) x/12xw 0x7fffffffdae0
0x7fffffffdae0: 0x004004d0  0x00000000  0xf7a2d830  0x00007fff
0x7fffffffdaf0: 0x00000000  0x00000000  0xffffdbc8  0x00007fff
0x7fffffffdb00: 0xf7ffcca0  0x00000001  0x004004b2  0x00000000
(gdb) x/12xa 0x7fffffffdae0
0x7fffffffdae0: 0x4004d0 <__libc_csu_init>  0x7ffff7a2d830 <__libc_start_main+240>
0x7fffffffdaf0: 0x0 0x7fffffffdbc8
0x7fffffffdb00: 0x1f7ffcca0 0x4004b2 <main>
0x7fffffffdb10: 0x0 0x716825b9b97d27b5
0x7fffffffdb20: 0x4003e0 <_start>   0x7fffffffdbc0
0x7fffffffdb30: 0x0 0x0

Now, the first address on main's stack (frame pointer) was to __libc_csu_init, and the latter (return pointer) to some place in __libc_start_main, from which the 'main' function was called.

Btw, don't have enough reputation to comment on other's answers, but user189437 posted (and not credited the original author, eh) a snippet from very good post on Patrick Horgan's blog, that explains how C applications are bootstrapped:

http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html

My another remark is: by invoking
info proc map
in gdb, when breakpointed at nop instruction, you'll probably see that __libc_csu_init isn't on the stack, but in the section where program instruction lies. That makes no sense, since we can't rewind stack there! Well, that's probably some part of program-startup magic, that sets initial frame pointer.

There's a book on that very specific topic, though I didn't read it, from the few pages I've seen it covers program startup (calling _start & libc_start_main ):

https://books.google.pl/books?redir_esc=y&hl=pl&id=YZIoDQAAQBAJ&q=libc+hlt#v=snippet&q=libc%20hlt&f=false

Hope that cleared things out!

Regards,
Daniel


Can a MitM attack occur on an ISP's local exchange or street wiring cabinet? If an attacker were to dig up the 'outgoing feed' from my local exchange or the street cabinet, could they sniff my entire neighborhood's network traffic? Or is this infrastructure secured against this sort of attack?

Absolutely.

In practice, though, this is a complex and very risky attack - probably going to be easier to do something else.


Fail2Ban keeps sending me logs of user banned, is someone trying to hack me? I installed and configured fail2ban on my VPS a couple days ago, since installed, it keeps sending me emails saying that an IP was banned after failed login attempts. Firewall is on and fail2ban is running, ban time is 1 hour, but apparently the ip is trying many times, and in different ports than SSH.

Here is part of the log:

Sep 27 08:33:55 hero2 sshd[18529]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.67  user=root
Sep 27 08:33:57 hero2 sshd[18529]: Failed password for root from 43.229.53.67 port 22961 ssh2
Sep 27 08:34:01 hero2 sshd[18529]: message repeated 2 times: [ Failed password for root from 43.229.53.67 port 22961 ssh2]
Sep 27 08:34:02 hero2 sshd[18529]: Received disconnect from 43.229.53.67: 11:  [preauth]
Sep 27 08:34:02 hero2 sshd[18529]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.67  user=root
Sep 27 08:34:02 hero2 sshd[18531]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.67  user=root
Sep 27 08:34:04 hero2 sshd[18531]: Failed password for root from 43.229.53.67 port 43817 ssh2
Sep 27 08:34:08 hero2 sshd[18531]: message repeated 2 times: [ Failed password for root from 43.229.53.67 port 43817 ssh2]
Sep 27 08:34:08 hero2 sshd[18531]: Received disconnect from 43.229.53.67: 11:  [preauth]
Sep 27 08:34:08 hero2 sshd[18531]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.67  user=root
Sep 27 08:34:09 hero2 sshd[18533]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.67  user=root
Sep 27 08:34:11 hero2 sshd[18533]: Failed password for root from 43.229.53.67 port 62808 ssh2
Sep 27 08:34:15 hero2 sshd[18533]: message repeated 2 times: [ Failed password for root from 43.229.53.67 port 62808 ssh2]
Sep 27 08:34:15 hero2 sshd[18533]: Received disconnect from 43.229.53.67: 11:  [preauth]
Sep 27 08:34:15 hero2 sshd[18533]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.67  user=root
Sep 27 08:34:16 hero2 sshd[18535]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.67  user=root
Sep 27 08:34:18 hero2 sshd[18535]: Failed password for root from 43.229.53.67 port 26821 ssh2
Sep 27 08:34:22 hero2 sshd[18535]: message repeated 2 times: [ Failed password for root from 43.229.53.67 port 26821 ssh2]
Sep 27 08:34:22 hero2 sshd[18535]: Received disconnect from 43.229.53.67: 11:  [preauth]
Sep 27 08:34:22 hero2 sshd[18535]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.67  user=root
Sep 27 08:34:23 hero2 sshd[18537]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=43.229.53.67  user=root
Sep 27 08:34:25 hero2 sshd[18537]: Failed password for root from 43.229.53.67 port 46038 ssh2
Sep 27 08:34:29 hero2 sshd[18537]: message repeated 2 times: [ Failed password for root from 43

From what I see, it's all coming from the same IP, it's attempting many times and on different ports (shoudn't my firewall block all ports except ssh?). Also, root is disabled.

Is someone trying to brute force my VPS? What can I do to stop it?

Get used to it.

If you've disabled root logins and are running fail2ban, you've already taken some sensible precautions. Personally, I always restrict access to a specific group of users and disable password authentication.

Manually adding blocks to the firewall for every host which tries to brute force your sshd is not a viable strategy.


Feedback for Study Plan (Kali Linux & Penetration Testing) I started to study pentesting for two months with the book named Penetration Testing - A Hands on Introduction to Hacking by Georgia Weidmann, and now I am really hungry to learn more :) . I think I found the right area to study for years (IT&Network&System Security). When finished my book I think that I must have a plan for my learning process to go deeper and to be master. I made a plan in which there are books, video tuts and certifications, and now I need some feedback about it (masters and profs can help me to improve it but any feedback from anyone are welcome).

And here my plan:

Information Gathering

Kali Linux Network Scanning Book (Book)
INE- Wireshark Advanced Technologies (Video Tut)

Threat Modelling

Kali Linux Cook Book(Book)

Vulnerability Analysis

Gray Hat Hacking - The Ethical Hacker's Handbook(Book)
Kali- Assuring Security by Penetration Test(Book)

Exploitation

Gray Hat Hacking - The Ethical Hacker's Handbook(Book)
Udemy - Certified Metasploit Framework Professional (Video Tut)
Kali Linux - Social Engineering(Book)
Web Penetration Testing with Kali(Book)
Udemy - Website Hacking in Practice(Book)

Post-exploitation

Gray Hat Hacking - The Ethical Hacker's Handbook(Book)
Mastering Kali Linux for Advanced Pen testing(Book)
Cybrary - Pen Test and Ethical Hack (Video Tut)
Kali Linux CTF Blueprints(Book)
Infiniteskills - Reverse Engineering and Exploit Development (Video Tut)

Mobile Hacking

Penetration Testing -Georgia Weidmann Chapter 20(Book)

Study through learning process:

Programming

Black Hat Python - Python Programming for Hackers and Pentesters(Book)
Penetration Testing with Bash Shell(Book)

Tactics and Techniques

Ninja Hacking - Unconventional Pen Test Tactics and Techniques(Book)

Prerequisites(also my b.g.):

Linux & Microsoft Operating Systems Knowledge
Networking (Reference models-OSI & TCP/IP, Protocols, Subnetting ex.)
Programming (Functional and OOP knowledge; PHP, C/C++, Java)
And, labour and patience :)

If one wants to work as pentester or IT/System Administrator, you should have some certifications, I think (especially in this area). Thus, there is a list for certifications:

CISSP (Certified Information Systems Security Professional):

Official Link: https://www.isc2.org/cissp/
Study Sources:

Official (ISC)² Guide to the CISSP CBK Textbook
All-in-One CISSP Certification by Shon Harris

OSCP (Offensive Security Certified Profesional):

Official Link: https://www.offensive-security.com/
Study Sources:

PWK by Offensive Security

CEH (Certified Ethical Hacking)

Official Link:
Study Sources:

EC-Council Online Training
Ethical Hacking & Countermeasures (All of them)

And, there are resources for free times:

The Tech Active Series - The Hacker's Manual 2015
Kevin Mitnick's books
Mikko Hypponen - Security Presentations (TED Talks)

It looks good to me but I can recommend you also to learn at least one or two programming languages (Definetely Python, JavaScript and maybe C/C++ at least you sholud know basic knowledge).

You can also download vulnerable application like DVWS http://www.dvwa.co.uk and test in your local environment. You can also download metasploitable linux vulnerable operating system.

I recommend also to download BurpSuite and learn as much as you can about HTTP protocol.

Obviously if you have some spare money you can go for practical certificates like OSCP or at least subscription to SecurityTube.

You can add to the list also some books about cryptography (I recommend B.Schneier books).

I suggest also to use this forum because you can learn a lot from here.


Deleting credit card information after every transaction There have been many reports of hackers compromising credit card information in the databases of online shopping websites. Will deleting my credit card information from my account after every transaction be effective in securing it from this kind of theft?

effective in securing it from this kind of theft?

Threats against credit card information while shopping online are diverse. I would say that your proposal is effective (as oppose to having no effect whatsoever), but the overall threat reduction is small.

This technique might be effective in partially mitigating some of the following threats:

Companies who store your credit card details at rest in either plain text or with weak encryption
Threats from malicious employees who might have access to the database
An attacker who compromises your account and places orders while logged in as you

However, this technique would make little difference in the following circumstances:

Man-in-the-middle attacks where the attacker can observe your credit card details during transmission (SSL/TLS is effective at controlling this threat but that's another story)
Compromised software or malware on systems that interact with your credit card details, such as web servers, databased servers, payment terminals
Attackers who have access to database backups which might contain your credit card details even after they've been removed from your account
Software which does not actually function in the way you'd expect. For example, you can't be sure the system doesn't just mark your credit card record as inactive as oppose to physically deleting it. You also can't be certain the record is securely deleted and not recoverable by someone who has access to the hardware.
If your credit card details are included in any logs which might remain even after you've removed the credit card from your account
Dodgy merchants and phishing

  There have been many reports of hackers compromising credit card
  information

If we look at a few recent case studies:

Target

  At the critical moment — [...] — the malware would step in,
  capture the shopper’s credit card number, and store it on a Target
  server commandeered by the hackers.

It wouldn't have been effective in that case as the attack was executed while the payment was being processed rather than while the credit card details are at rest.

Staples

  Staples says as many as 1.16 million customer credit cards may have
  been compromised as part of a malware attack

Home Depot

  the malware in this attack was embedded in the company's in-store
  payment systems

So it would seems that malware is a common thread in several of the most publicised attacks. Having said that all these examples are big-box retailers rather than strictly online stores.

TLDR; It would have some effect, but overall probably not enough to be worth doing and it depends on the merchant whether it would be effective at all.


Is there any way to authenticate a HTTP client only once? I'm working on an application that acts as a back end (REST API) for a Google Chrome extension. Data is supposed to be sent from and to the client.

The way it works is:

The data that comes from the client is encrypted by the application using AES-256 (using the master key, look below) and stored in a SQLite3 database.
The data that is sent by the application to the client is decrypted in the back end and then sent over an HTTP protocol.

Note, the application and the extension reside in the same local environment, thus other computers on the network can't access it. That's why the data is transferred in plain text in both cases.

There are a few constraints:

There can be a number of clients sending requests to the back end. They are all controlled by the same person.
There is a sign in form in the client and it only requires a master key. Once the form is submitted, the key is supposed to be sent to the back end and the client is authenticated, i.e. by comparing it to the one (encrypted using PBKDF2) in the database.

The Problem
The problem is that I don't want to store the master key persistently in the client (Javascript), as it can easily be looked up by anyone else who can access the computer. If it was possible to authenticate only once, by sending the master key via the protocol to the application and then remove the key from the client.

So the question is what would be the optimal solution?

Is there any way to authenticate a HTTP client only once?

No, because HTTP is stateless.

  data that comes from the client is encrypted...using the master key

Both the content in the browser, and the stuff on the server is the application. Where is encryption happening?

  The data that is sent by the application to the client is decrypted in the back end and then sent over an HTTP protocol

OK, so when you say application you really mean the server-side?

It would appear there is never any requirement to store the "master-key" on the client.

  sign in form in the client and it only requires a master key

You use the encryption key as an authentication token as well? Really? You expect users to type in something like

c48bb691eb5e2f609192ed5a981c6f8745896aa968604c1cdf70cb57ebc0d421

every time they log in? I'll bet you're either allowing them to pick really simple passwords/keys or they are storing them somewhere.

You could simply store the master key server-side in a HTTP session variable. But if this really is a "master" key, then the clients/users should have no visibility of it. You need to separate the authentication from the encryption.

There are various things you could do with local storage, a second server, encrypting the master key with the user's password to protect it, but without knowing a lot more about the platform it is impossible to advise (and becomes too complex for a discussion here).


What are the security issues of open ports? What could be the threats of having the ports open, after performing a nmap scan and identifying the open ports?

I already searched for some answers for this question, but couldn't find anything specific. Is there any particular issue with each and every port or are those threats common for all of them?

An open port is an attack surface.  The daemon that is listing on a port,  could be vulnerable to a buffer overflow,  or another remotely exploitable vulnerability.

An important principle in security is reducing your attack surface, and ensure that servers have the minimum number of exposed services.


Can someone without the WiFi login and no physical access to a router still access it with the admin login? If you have a router with default login and password for the admin page, can a potential hacker gain access to it without first connecting to the LAN via the WiFi login?

This may be possible using cross-site request forgery. In this attack, the attacker triggers a request to your router, for example by including an image on his site:

<img src="http://192.168.1.1/reboot_the_router?force=true">

When a user visits his site, this triggers a request to the router.

The attacker's site can trigger requests, but not view responses. Not all routers are vulnerable to this. Setting a non-default password certainly protects against CSRF1.

There are plans to block such requests in the browser, but these haven't been implemented yet.

Edit 1: Setting a non-default password protects against CSRF in some cases. The attacker can no longer forge a request to login using the default credentials. However, if you are already logged in to the router he can use your current session.


Is there any chance PHP developers themselves implement backdoors in PHP core? This is not a concern that I personally have,no! In my job environment I've heard from programmers and non programmers that PHP developers always put secret backdoors in PHP that no one has access to but themselves, so if a project goes live and become a big project they can do whatever they want with it, like stealing company assets and etc.
Although I do respect to all the PHP developers in php.net and others, I'd just like to know about your opinions.

P.S: Like some viruses including Starex that were enabled by a specific action.

Backdoor are uncovered on a fairly regular basis.   This is by no means something unique to PHP, and can happen for a verity of reasons.  Open source projects are not totally immune as code can be quite underhanded, however this is not something that just affects open source projects

For example,  Horde (php) was hacked and the attacker introduced a backdoor,  but the same thing happened to VSFTP (C/C++).  Sometimes the software vendor will intentionally place a backdoor in their own code.  This is believed to have happened to RuggedCom's SCADA Systems,  which is closed source.

Worms can contain a backdoor.  For example MyDoom was an email worm that spread and opened a port which allowed code execution.  Later a worm called DoomJuice spread using MyDoom's backdoor.  Also verities of the PhatBot/AgoBot family of IRC bots spread piggy backing on MyDoom's backdoor allowing any teenager with a C++ compiler to take advantage of it.

It is easy to carelessly leave out a sanitation routine,  who's to say its a backdoor?


We can read the ssh private key with less id_rsa I created an ssh key with the command ssh-keygen -t rsa -b 4096 -C "myname@myemail.com".

I put a passphrase.

It created two files : id_rsa and id_rsa.pub .

I am surprised because, when I do less id_rsa , I can read the key without there being a request for my passphrase. There is no word "encrypted" in the text.

I thought it was possible because the passphrase was not requested for me and only me but, if I copy the id_rsa file in the /home of another user, the result is the same: this user can see the key and the word "encrypted" does not appear.

I specify that I had to give reading rights with chmod but I don't understand: why the passphrase is not requested?

Thank you a lot!

You don't need the passphrase to read the file, just use it. If you created it with a passphrase then it is encrypted. However, the difference between a private key and an encrypted private key are invisible to the naked eye - both are effectively random bytes/strings.

As a result, you can't necessarily tell that it is encrypted just by looking at the file. You can't use it without the password though, which is the important part.

With older file formats, the presence of a key was visible as you say.  The new OpenSSH encrypted private key format does not indicate in a human-readable way whether or not there is a passphrase.  Therefore, the easiest way to verify if the file has a passphrase or not is by trying to actually do something with it.  As a simple test just run:

ssh-keygen -yf /path/to/private/key

If it asks you for a passphrase then the private key has one. If it doesn't then there is no passphrase.


Can Cipher Suites defined in TLSv1.2 be negotiated by clients that only support TLSv1.0? If my server has only the cipher suites enabled which are defined by TLSv1.2 does that force a client to also use TLSv1.2 or else not be able to connect or can the connection fallback to TLSv1.1 or 1.0 and still negotiate the TLSv1.2 cipher? I do understand that the GCM block modes are TLSv1.2 only but unsure about the others.

It forces clients who report that they support TLSv1.2 to use it, and causes all other client connections, those who only support a maxium of TLSv1.0 or TLSv1.1, to fail.

At this point, unless you know exactly who your clients are and that they do, in fact, support TLSv1.2, (if this is in any enterprise Intranet environment, for instance) I would not recommend this configuration.  There is a large portion of the Internet that does not yet have the level of support required for this to not turn out to be a disaster.


Does knowing encrypted information make it easier to find an unknown key? I'm curious if knowing the exact content of an encrypted message or several messages makes it theoretically any easier to discover the encryption key. Does this speed up a brute force attack in any way? Or provide some other means of discovering the key?

How would this concept apply to both symmetric encryption and asymmetric encryption?

As always, it depends on the algorithm. The attack technique you are asking about is called a "known plaintext attack", but it only works for certain types of encryption.  Modern cryptanalysis is all about pattern detection. A brute force attack is the last thing done because it means that all other avenues of attacking the cipher have failed.

Imagine a simple shift cipher such as rot-13 (a weak form of encryption no better than obfuscation). You and I know that the shift factor is 13, but our fictitious cryptanalysis does not.  However, because they have various samples of both the plaintext and the cipher text available to them, they can sit down and determine quite quickly that each 'a' has consistently shifted to 'n'. Noticing this, they will quickly detect that the shift key is 13 and "break" this rudimentary encryption scheme. If they did not have this ability to easily check their work, the act of breaking the code would take much longer and possibly require them to start "brute-forcing" their way to solving it by trying each shift factor.

It is my understanding that although encryption algorithms are usually susceptible to known-plaintext attacks, modern algorithms are usually constructed such that they cannot be attacked in any meaningful way. That is, you might have a symmetric 256 bit key, and after much analysis, shave off 10 bits from a pure brute-force attack. The algorithm now has 246 bits of complexity.  It will still take a while to brute-force that key.  AES is not supposed to have any meaningful attacks on it.

Asymmetric encryption is an interesting case in that you can produce as many cipher texts as you want to compare to your plaintext (you have free access to public keys after all).  You can use this time to find and exploit weaknesses in the algorithm or specific implementation.


Can I safely and securely store hash(sessionId) in application logs? I'm considering storing a hash of a user's session ID in our applications logs on each request. This would allow users sessions to be easily tracked back to actions in our logs.

I understand that storing this is a potential security risk, which i may be willing to consider if the risk is very low. Why is it a risk? If anyone that has access to the logs can figure out how to get a session ID, then they can essentially steal that users session and login as them without credentials.

To that end, if I was going to do this, what's the best way to do this?

Here are some things I'd like considered:

Which hashing algorithm should I use ? It needs to be fast.
What should I hash ? Session ID + Salt?
How risky is this? Should I just not do this?

EDIT: I'm considering just generating a GUID and adding it to a users session on session creation. Then logging this instead. That way it'd always be unique for the sessions lifetime. The problem with this is that it would add more session data and require more session memory for each user. With this approach no hashing would be required, and the user's session could still be uniquely tracked.

If session identifier is randomly chosen from sufficiently big space (something like 12 bytes should be more then enough) then any non-invertible hash function (even md5) will be secure, and there will be no need for salt (rainbow tables of this size are infeasible).

To expand, problem when storing password hash is that passwords usually have very low entropy (unlike tokens, like session id for example). Besides, you do not care for other hash function properties in which md5 considered weak - attacker cannot influence his session id to collide with any user, and even if he does it will only (at best) confuse you studying the logs).


Facebook login on HTTP? Possible Duplicate:
  Is the Facebook login form using SSL without https in the URL?

If you access http://www.facebook.com/, in the top right side there is the login section. You can enter your credentials there and click "Log In".

My URL is on http:// though (!?). Is the login safe?

the details of the form is:

<form method="POST" action="https://www.facebook.com/login.php?login_attempt=1" id="login_form" onsubmit="return Event.__inlineSubmit(this,event)"><input name="charset_test" value="€,´,€,´,水,Д,Є" type="hidden">

note the https in the action this means that the submit will happen over https regardless if the current page is http or https

however this does not mean that the original page wasn't modified in transit to add a script that might hijack the credentials and send it to a attacker


How easily could this method of cryptography be cracked? Background

A couple of years back, in my naivety I dreamt up a method of encrypting information, the result can be seen on my website, I evidentially thought it was pretty neat and I decided to mix it with steganographyto further confuse the issue.

Reality check, I know jack all about cryptography, most information on my page is probably wrong or at the very least misleading.

Ignoring the steganography, how easily could my method be cracked? (I'm guessing between easy and very easy, I just don't have the know how to be exact).

Brief recap on how my method works

Assuming we are encoding characters,

Choose a number of bits to represent each encoded character
Choose a list of characters we will be able to encode
Generate a neural network which has 1 input for each bit (see 1) and one output for each character (see 2).
Make sure you use more bits (see 1) than characters (see 2).

The network takes a binary input and you take not the output as a whole but the strongest output, which maps directly to a character in your supported character list. Any set input will always map to the same output but, importantly, multiple inputs will map to each output.

If I am using 16 bits to encode 26 characters, I'll have 65,535 unique inputs mapping to just 26 outputs, or 2,520 ways to represent each character.

This means the letter 'z' 2,520 times could be encoded as a non-repeating set of 16-bit integers.

Flaws I can see

If you can recreate the neural network, you can decode the information, this involves keeping a secret, the algorithm and inputs used to generate the network (or the exact network used if crafted manually). Is this any worse than other encryption methods?
There are likely to be similarities between the groups of inputs which result in the same character.
Having no repeating patterns, is probably a weak point, no pattern is probably as revealing as an obvious pattern.

The question

How easily could this method of cryptography be cracked? Feel free to rip it apart, it is an amateur attempt after all.

The point of this Q&A site is not to assess people's algorithm strength, so technically this question is off-topic. However, there are points in here that requires explanation and do point to the algorithm weakness without having to look at it.

As per Kerckhoff's principle, a cryptographic system must still be secure if everything about the system is known, except the key. "What is the key" in your case? And "what is it's length?" are two question you need to ask yourself before even thinking of strength of the scheme.

The network seems to be the real key here. It is based on a pseudo-random generator. So the key is the seed. Which is an int. So 32 bits. That is a poor key.

In addition, having both plain text and it's encrypted form makes it possible to make a known plaintext attack (as mentioned in the comments).

So it's a bad cryptography scheme.

Furthermore, steganography and cryptography rarely goes well together, since they have objectives that are opposed. Cryptography is all about confidentiality (and authenticity in the case of signature), while steganography wants to stay undetected in the mass of information. Steganography does not care about strong resistance to decryption, in fact the algorithm can be published and not use any key at all. The "security" behind steganography is resumed by the following elements:

You have a flow of data (images, ...) that is important
The attacker cannot plausibly try to decrypt each and every data to check for hidden message
The steganography scheme does modifications that are not easily identified in the data

The goal of the attacker of a steganography scheme is to be able to process an image and say : "yes there is a message here", or "no there is no message here".

Typically, cryptography is used to transmit large amount of data. But large amount of data cannot be successfully hidden with steganography in only one media without impairing invisibility.

Furthermore, your scheme increases the number of bits needed to be embedded.

So it's a bad steganography algorithm.


Is BitTorrent Sync a spyware? Source: http://www.infoworld.com/t/development-tools/bittorrent-sync-gaining-major-traction-peer-peer-alternative-dropbox-232144

  and the average usage has hit 20GB per person.

How can they know that without using some sort of spyware to monitor and keep track on a central server somewhere?  If it's P2P, they would never be able to figure out that average usage is 20GB per person. Am I right?

The BitTorrent Sync Android and iOS apps seem to follow the BitTorrent.com privacy policy which states explicitly that they gather data such as total traffic and performance metrics.

  We also aggregate some data from the BitTorrent Client regarding total
  traffic flows and content delivery performance.

I don't see any problem with that; it's completely understandable. This data can be useful to them when further developing the protocol, helps them understand P2P performance in the big picture, and, perhaps, to measure their own value as a service.


LastPass Grid Authentication vs Google Authenticator which one is more secure? [Being a LastPass user] recently I moved to Google Authenticator instead of using Grid Authentication as a 2-factor security. For me, finding and filling letters from such a dense matrix is a rather clumsy task.

I have basic understanding how Grid, Google Auth some some other LastPass 2 factor-authentication work (Yubikey/Sesame, ...) In general Yubikey is considered slightly more secure than GoogleAuth, so I'm just wondering the comparision between the Grid and Google Authentication App.

Sample of a 6-digit random number generated by Google Authenticator App:

For example: the phone can be lost (it can be stolen or something). In that case, isn't it true that all the pseudo-random numbers being constantly generated by the app are easily exposed to the thief? (If one use the GoogleAuth app extensively, and if he does not protect his phone very seriously - well, doing so slows down our process to open the phone, so normally people just apply some simple pattern)

This is what a LastPass Grid looks like:

For Grid, the normal choice is to print it out and put it in a wallet. Of course, your wallet can also be lost, but if you do not need the grid very frequently, you can keep it at a safe place at home. Not carrying the grid around reduces the chance someone might get it. This is different from the phone: you always have to carry your phone around.

So paper-based grid may be clumsy, but from some certain perspective (as the example above), it seems better.
Now consider the "security" aspect, which one can be considered better secure (theoretically/practically) than the other, and why? Or they are just the same level?

It's not very easy to quickly find the corresponding content of the coordinates:

Edit: This guy has made a really good slide about Google authenticator. Well, the case of phone lost is somehow "trivial" but the seed to feed to TOTP is stored in plain-text.

http://www.slideshare.net/zerocool51/google-authenticator-possible-attacks-and-prevention?qid=1a8842ba-45bd-40c4-be0a-dedc19e0a85f&v=qf1&b=&from_search=1

I personally prefer Google Authenticator which is basically an elegant implementation of Time-Based One-Time Password Algorithm but I would not feel comfortable saying it “is more secure”.

To use one of my favourite buzzwords… it all comes down to Threat Modelling. What exactly are you trying to protect against? Is it a technical attacker who might be able to get malware on your phone? Or one of your mates trying to post dirty things on your Facebook page? I think the most important difference between the two methods is: is the attacker someone who might have physical access?

There are also a huge number of variables, do you encrypt your phone? Does your phone automatically lock? Do you leave your wallet un-attended? It’s impossible to give a finite answer but each has its pro’s and con’s and fairs better in some areas than others. Some interesting points are:

Physical Access

When an attacker has physical access you have lost, but some things hold up better than others.

Grid: Someone can take a photo. Takes about 2 seconds.
Authenticator:  As far as I’m aware you need root access to receive the keys. Without some serous planning you are unlikely to be able to get them in under a few minutes. Many phones  have GPS trackers so you can find them if they are stolen.

Remote Access / Malware

Grid: I do not know of any malware that infects paper. Enough said.
Authenticator:  There have been several malicious apps in the play store, genraly they are pulled pretty quickly but it happens. Some can even get root. There are many ways to keep your phone up-to-date and clean it really depends on your practices if you install untrusted apps or you read the manifest for each one etc...

Compromised host

This is an interesting one where I feel Authenticator has a slight edge. There have been several banking trojans that use Man in the Browser attacks.  Neither of these will stop that but:

Grid: If you’re on a compromised host that’s got a key logger installed after a while it could build up a copy of your grid and then be used by an attacker at a later date. (e.g. work out what U7, M8, I5, and so on are and make your own copy of the grid)
Authenticator : Each code should be computationally indistinguishable from random so even if you have the last 5,000 codes that were used, you can’t work out what the next one will be.

Convenience

This is a massive factor that often gets overlooked in security. Even if one was far more secure than the other what is important is making it usable and seamless enough that people will actually use it.

Grid: If lots of different sites used this you would need one for each site with two factor. I just don’t think it scales.
Authenticator: I always have my phone with me and I have a few sites that use two factor, you just keep adding them, it scales pretty well. Also like you say it's easier to type the 6 digits than searching a grid for the  corresponding content. This is very subjective but I find that more convenient.


Why Google Chrome complains about mozilla.org identity? On a "brand new" (but fully updated) Windows XP installation (an Asus EeePC that I restored to factory setting and than updated with all Microsoft's upgrades) I installed a few days ago Google Chrome.

Today I opened Chrome and browsed https://www.mozilla.org to download Firefox.
I was suprised to see Chrome alerting that, while the ssl certificate was fine, "the identity of the site cannot be verified" and thus the certificate could have been revoked.
I checked it twice, googled a bit looking for issues in the DigiCert certificates and or in the Mozilla's one, found nothing and turned back to my main task.

I downloaded the Firefox installer (Firefox Setup Stub 33.1.1, signed by Mozilla Corporation on 14/11/2014 at 04:36:30AM), and despite the warning, I installed the browser to test a few web pages.

After a few minutes I closed Firefox and Chrome. Than I opened Chrome and browsed to https://www.mozilla.org again, and know what? No warning anymore!

Out of curiosity I uninstalled Firefox entirelly (suspecting than the installer had installed a new, potentially broken, certificate), but the Chrome warning about the Mozilla certificate was still missing.

Can anybody explain what's happened? Why Chrome changed his own opinion after the Firefox's installation?

Note that I know that windows XP isn't supported anymore by Microsoft, but I can't see how this relates to Chrome's opinion on the Mozilla's certificates!

Check if you're running Chrome 39, there are major changes to the way some certificates are treated - e.g. Chrome 39 starts to penalize sites with long-lived SHA1 certificates
This release warns about SHA1 certificates that expire in 2017. Versions 40 and 41 will increase the scope of the warnings to include certificates that expire in 2016.

More info can be found here:
http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html


Is the PGP Web of Trust / Keyserver infrastructure permanently broken? I love the idea of decentralized trust, the web of trust, and the fact that anyone can run their own keyserver and isn't beholden to a centralized point of failure. But does the decentralized "feature" of the web of trust and the keyserver network make it effectively broken as a method of trusting others? Take for example this criticism:

  What bothers me about existing keyservers? I used the phrase
  "fundamentally broken" not to be all trashy, but because I think
  there's something broken in the fundamentals. The fundamentals involve
  PGP itself, and are perpetuated by the keyservers:

  The web of trust is really dangerous. I love the idea in theory, but
  I've been to a key signing party with a whole bunch of smart
  programmers and it was a mess. It was confusing enough that I don't
  think I feel comfortable generally trusting most edges in the graph.
  Anyone can claim to be any email address and push it to a keyserver.
  This produces pretty dangerous behavior, if you just choose to look up
  someone by email address (or get contacted by the impostor and look up
  by fingerprint.) A counterargument to this is of course that the web
  of trust will isolate this fake account, but I have sub-problems with
  this: (a) people may ignore the WoT, and (b) it's very easy for an
  impostor to get into the web of trust. As an example, it's easy for
  someone to show up at a key signing party with a fake ID. Not all
  keysigning parties are among people who know each other, and in fact,
  many happen at meetup type events.

This bothers me very much, because there is a lot of truth to this. The fact that anyone can post a key to a keyserver and it's automatically published (i.e. without verifying that they can receive email at all addresses associated with the key, and decrypt messages with that public key that is pushed to the keyserver) is a big problem. And the entire "web of trust" is based on our assumption that others who have signed keys within the web of trust are themselves trustworthy.

Are these elements of the PGP infrastructure inherently broken? Does the decentralized nature of trust and the keyserver network inherently allow for the infiltration of untrustworthy characters?

Yes, it is broken, if you're

confusing the different kinds of trust (nice article, sadly the page is offline, but archive.org has it),
using it wrong (eg., just fetching any keys as described in your question) or
want to make others use it without educating them.

The basic idea is totally fine, but you have to be somewhat picky whom to trust (a.k.a. the Vouch, see link above). The concepts behind OpenPGP are rather complicated, and have to be applied with care.

Trusting others is a difficult job, and other trust systems aren't any better - the problem is just a little bit different.

Being specific to a single point:

  As an example, it's easy for someone to show up at a key signing party with a fake ID.

This is only a problem, if you arbitrarily trust anybody. Also: There might (and probably always will) be some people who wouldn't realize when somebody brings tampered documents. But with the amount of people joining the party, chances increase somebody will realize. And if someone does, he will be very clear on that. Brining a fake ID card to a key signing event is brave, I'd probably rather go for individual key signings to do so.


TLS Finished message I'm implementing a TLS-like system, and I'd like to set up a Finished message, to prevent the replay attacks.

As far as I understand TLS, it contains a hash on the previous handshake messages. This hash is then encrypted and signed with the negociated algorithm.

My question is about what to hash in this message. It isn't specified in the chapter about the Finished message, in the RFC...

Is it the messages (non-ciphered), or rather what was sent through the network (and which have been encrypted/signed) ?

In SSL/TLS, what is hashed is the handshake messages, i.e. the unencrypted contents. The hash input includes the 4-byte headers for each handshake message (one byte for the message type, three bytes for the message length); however, it does not contain the record headers, or anything related to the record processing (so no padding or MAC). The "ChangeCipherSpec" message (a single byte of value 1) is not a "handshake message" so it is not included in the hash input.

Each handshake message may be split over several records; similarly, a single record may contain several handshake messages. This splitting and merging has no impact on the hashing process.

This is actually specified in the RFC:

  handshake_messages
     All of the data from all messages in this handshake (not
     including any HelloRequest messages) up to, but not including,
     this message.  This is only data visible at the handshake layer
     and does not include record layer headers.  This is the
     concatenation of all the Handshake structures as defined in
     Section 7.4, exchanged thus far.

Mandatory note: it must be stated that designing a protocol such as SSL/TLS is very hard; a lot of some details can be wrong and jeopardize security. The actual TLS got it wrong in several points, and this triggered a lot of trouble (see this answer). Defining your own protocol, and making your own implementation, are OK for purposes of learning or simply having fun, but I urge you to reconsider any velleity at deploying such things for production use.


Securing hashes of short enumerated values The system manages and stores sensitive data of short strings.

Because the sensitive data is of an enumerated type with limited set of well known values, the attacker could easily iterate all the possible values to generate a rainbow table and utilize dictionary based attack.

Thus the data must be salted before hashing to countermeasure these threats. Of course the "salt" must also stay secret and be cryptographically secure. The salt must be common for all the records, as the application will do hash lookup on the input, i.e. the hash must be deterministic.

What are best practices to deal with hashing of enumerated data type, including the key management of the "secret salt" and forward secrecy aspects? We have planned to utilize HSM in the hashing to store the secret.

The salt must be common for all the records.

This is known as a "pepper", not a salt.

  the attacker could easily iterate all the possible values

If the search space is small enough that it could be brute-forced even with a high cost hash like bcrypt, then you're relying entirely on the secrecy of the "pepper" to prevent brute-forcing. In this case, you might as well use an HMAC with a secret key instead. Using an HSM to store a random key and handle the HMAC is about as good as you can get.

Just be aware that because you require the ability to look up the hash, the same data will always have the same hash value. As Kevin's answer goes into more detail about, duplicated hash values may be correlated with other data to leak information.

While it would be ideal for the hashes to be irreversible, that's simply not possible with a small message space. The best you can do is to make sure only the HSM can be used to reverse the hashes. This will help against data leaks, but you must still take care to make sure the application layer can't be brute-forced.


Any value in a web-server closing connections on bad requests (or bad pages)? At least one web-server, nginx, has the ability to "close the connection without sending any headers", by configuring it to return a (nonstandard) 444 to various malformed HTTP requests.

Is there any actual security value in this, or is it just security theater? How are attackers likely to respond to getting no response from an IP address? If there is any value, what's the cost-benefit ratio? Is it worth the effort to configure nginx to do this?

Update - after thinking about it, there's really two situations where I might want to close the connection. Not just bad HTTP requests, but also well-formed requests for non-existent pages.

For instance, a get /bank-files/index.htm request. There's no such page on my website. However, currently I'm passing all requests through to a Django process, and it obviously returns a 404 on any not-found pages. Given that my site will have a small number of sub-pages known in advance ("/", "/users", "/orders", etc) - I could configure nginx to pass through only those pages, and return 444 (close connection) on anything else. Assuming it's worth it. :)

So is there any value in closing the connection to all the requests that are valid HTTP, but for non-existent pages?

The value is in avoiding having higher-level application software (php, wordpress, whatever) work with and possibly mishandle malformed requests.  Since the nginx layer is evaluating for protocol correctness, and not attempting to actually do anything with the request, it's providing a pre-filter.

Terminating the connection abruptly doesn't win you much.  It tells the attacker what defensive system you're using, and the same means would be achieved with a generic 404 response with less usefulness to the attacker.  But it's the sort of dramatic security theater that crops up now and again, and it doesn't do any real harm to anyone.


Veracrypt - Encrypted USB Partition - Does it Pass the Key Over USB? Looking in to Veracrypt to use it in some spaces, but more for encrypting an entire USB partition. I was curious as to how the key would be passed though. I don't want someone to be able to intercept it if it gets passed via the USB port. Any clue as to how Veracrypt handles this? Curious to learn how Veracrypt handles this.

I'm not quite sure what you mean with "does the key it get passed over USB". I'm assuming that you're asking whether the volume encryption key gets passed from your external USB storage device to your CPU, or vice versa.

The answer to that question is yes.

The reason for this is that your passphrase which you use to unlock the volume is not actually the encryption key for the data. The encryption key is stored on the volume, but it is encrypted with your passphrase (after it undergoes key stretching etc).

This is why you can change your passphrase without re-encrypting the whole volume - you basically just re-encrypt the encryption key with your new passphrase.

So, if you think about it, since the actual encryption key is stored in the VeraCrypt volume header, and the volume header is sitting on the USB storage device, obviously there must be a moment when the encryption key - in encrypted form - is moved from the USB storage device to the CPU.

I don't see a security problem with this, though.

OTOH, if you were asking whether your passphrase to unlock the volume gets passed to the USB storage device, then I'd agree with Thomas that no, it isn't passed.


Mechanisms to detect service abuse in the cloud I want to ask if it is possible to detect the abuse of a service in the cloud. How can the SaaS provider be sure that the client does not use the service for criminal acts? For example how can Google be sure that someone does not store pedophile pictures in Google Drive?

It is possible to programmatically discover known pedophile images by hashing the user's files and checking for matches.  Governments request data from Google for criminal investigations so such efforts are conducted in a legal context. Google provides details on the quantity of those requests and references to the legal aspects here.


How Can You Define a Custom Path to Nmap Resources? I am working on creating an application that utilizes Nmap, and my goal is to allow the user to run the application without any dependencies.  The issue I've run into is that the Nmap command fails to detect the OS or vendor of any host once I uninstall Nmap from my development machine.  How can I bundle the resources Nmap requires and specify their location to Nmap? Ideally, I would like to execute a command from the Terminal with information on the location of these resources.  Thanks!

I have since found the answer to this question.  In any Nmap command, you can add the --datadir argument in order to supply a custom location for the Nmap data.  You can find the required files here: https://svn.nmap.org/nmap/

ex: nmap --datadir ~/nmapdatafolder localhost

https://nmap.org/book/data-files-replacing-data-files.html


How can I scan open ports without being traced back I would like to scan open ports of a server. But as far as I know, when I try to scan the open ports with something like nmap in shell they would be able to trace me. Is there a way to secure this scanning to make sure they would not be able to trace back?

Depending on the environment of your scan and where the server is located etc. You may be able to accomplish this using a TCP Idle Scan - http://nmap.org/book/idlescan.html

You could also do your scanning via a proxy http://funoverip.net/2010/11/socks-proxy-servers-scanning-with-nmap/

Both the above methods are more covert but neither is completely untraceable so do consider this.

Also you should consider legality of port scanning a system unless you have permission to do so - http://nmap.org/book/legal-issues.html