Does using a VPN completely stop MITM (man in the middle) attacks? If not, what other defences should I consider? Just for added context, I am curious about connecting to a remote desktop using a VPN but if there are any major differences that can be highlighted for other services I would be interested in that too.

Assuming that you have a properly configured and behaving VPN client, using a VPN will prevent MiTM attacks from occurring between your computer and the VPN server. There is still a chance of a MiTM attack occurring between the VPN server and the desktop you are connecting to.

Assuming that the both the VPN and desktop are inside your company's private network, connecting to the desktop via VPN is as secure as connecting via any other network connection inside your company's network. Likewise, if the VPN and desktop are not within a private network, then the connection is open to MiTM attacks on the public internet.


Are Matrix messages encrypted using perfect forward secrecy? I can not find it in the FAQ.

I know, that TLS has PFS. But I am not interested in transport security but the message encryption of Matrix. Are the messages of Matrix encrypted with PFS?

Yes, they are (if you enable encryption, which has to be done manually).

End-to-End encryption in Matrix is done using the OLM protocol which is heavily based on the Signal/Double Ratchet protocol and provides forward secrecy.

When you enable encryption for a matrix room for the first time, you can choose the degree to which new members of the room will be able to read messages written before they joined.


Must all ssl certificates for a domain be trusted? I've read that it's possible to have multiple certificates on one domain. My question is whether all these certificates should be trusted and valid or whether one valid trusted certificate is enough for browsers to trust it.

The context is, I have a WebSocket chat server which provides a trusted certificate from Let's Encrypt through a proxy. However this server also provides an internally managed certificate for identifying it's part of a trusted network. This second certificate is meaningless towards browsers but required for connecting other chat servers to build up a network because the network all trust the root network ca and don't rely on domain names but identities instead.

So in essence, would browsers accept the server since the Let's Encrypt certificate is valid, even though the second certificate is untrusted (since the root ca is not part of the standard trust store).

Only a single site certificate is transferred during a TLS handshake (i.e. at setup of the HTTPS connection). This certificate must be trustable by the browser, i.e. be valid, not expired, signed by a trusted CA and match the domain from the URL. For this specific connection and client it does not matter what kind of certificates the same server might provide to other clients.

Other clients will probably have similar requirements (at least they should). But they might have a different set of trusted CA so that they might accept a certificate which is issued by an internal CA since they trust this internal CA. Or they might trust a specific self-signed certificate.


Is it insecure to use a single antivirus exclusion list? I work in an organisation that struggles to manage and maintain services.

We're rolling out an AV solution and I want to configure a single exclusion list across our entire estate to cover SQL, AD, Exchange, etc. I realise that this may lead to exclusions on a subset of servers which are irrelevant or shouldn't be excluded.

Our AV solution isn't flexible enough to have inheritable exclusion lists, so we'd need separate exclusion lists for each server type with the management overhead of updating multiple lists each time a single exclusion changes.

Is there any official (NIST, GCHQ, Microsoft, etc.) guidance on this? Theoretically it's safer to use multiple exclusion lists, however given my organisation, the effort in maintaining separate exclusion lists is likely to lead to incorrect and inconsistent configurations, which is a risk in itself.

Any thoughts?

Excluding in each server only what may be excluded is more secure than excluding the same resources in every server because the less you exclude, the better. In the other hand you won't increase the risk too much by applying the same exclusions to every server if the exclusions are reasonable.

Imagine for a moment that one server requieres you to exclude everything and that should be propagated to all systems...that wouldn't be reasonable.


Testing non‐browser‐based https clients for Poodle I have a command line tool that can download any URLs likewget (only for vcs systems) but not it’s source code, how can I test if it is vulnerable to POODLE?

There are lot of online automated tools for testing if a web server or a web browser is vulnerable to POODLE.

But as my program is command line only, how to check if it supports SSLv3 over http?

I would start by finding out which SSL library it is using. I wouldn't be surprised if it used (maybe embedded) an old openssl version, in which case there would be a number of vulnerabilities to take into account that could be easily extracted, not just poodle.

As pointed out by  schroeder, you could launch a webserver that doesn't speak anything newer with:

openssl s_server -no_tls1 -no_tls1_1 -no_tls1_2

But it is much easier to attempt retrieving
https://sslv3.dshield.org/vulnpoodle.png which is part of the https://www.poodletest.com/ test

sslv3.dshield.org is a server which only speaks ssl3. Thus, if your tool is able to retrieve it, it supports SSL3 in the configuration you are using.


Are there any known hacks using caller ID protocols? I have gotten a number of calls where after I answer (I rarely answer but occasionally a number pops up that could be from a customer) the caller hangs up. I'm assuming it was a robo call (the calls are not just ones from my local area code and exchange.)

I got one of those calls a short time ago and began wondering what information is being sent by my phone to the caller. Almost immediately I got a little freaked out when I wondered if the caller could send spoofed caller ID messages that took advantage of a vulnerability in how my phone handles caller ID data.

I looked into the SDMF and MDMF formats and while they seem straightforward there are always potential holes waiting to be discovered.

I was thinking of malformed packets that could cause a buffer overrun or such like we see on IP links.

So the question is, are there any known hacks where people use a computer to send caller ID messages that open up the phone to attack or causes it to leak information apart from the normal name, address, etc.?

I don't know of any bugs that specifically exploit caller ID handlers, but there have been a handful of very severe vulnerabilities that could be triggered simply by sending an SMS. An example was Stagefright, which exploited SMS messages with MMS attachments. It required no user interaction. Yes, more exist that are unpatched (that's true of all software), but it's not something you need to worry about coming from mere robocallers. If they are discovered publicly, they will likely be patched quickly.


I want to encrypt my SSD, should I still use TrueCrypt or Is there a better open source alternative? Before anything I have say that I have no experience with cryptography, at all. Anyway, I have a laptop with Windows 10 and an SSD. I don't want to use BitLocker since I don't trust Microsoft in this matter.

I've read that TrueCrypt 7.1a is still safe despite being abandoned by the developers, but everything I've read was from about 2 years ago, so I don't know if it still is a good alternative.

I'm also considering VeraCrypt, but some people say isn't safe because it wasn't audited yet. So, what are some good and reliable open source alternatives to encrypt my system?

TrueCrypt is still very reliable encryption software. Of course, the key that set is, well the "key" (pun somewhat intended). There are multiple reliable encryption tools for your operating system, most people here won't list them off because of course they may be the creators of said software. I can tell you from personal experience that TrueCrypt, Bitlocker and VeraCrypt are very reliable encryption softwares. Read blogs regarding the matter, and make the decision based upon that. Of course, ever crappy encryption software can be a pain to crack if your encryption key is very secure.

Best of luck in your search, and if you have questions about others, add a comment I will gladly give my 2 cents, as I'm sure others on here will as well.


why application/json content type have csrf token? If Json Applications are properly verifying the content type and have well configured crossdomain.xml, then why they still used csrf token?

Could anybody tell me , why they use csrf token ?

AFAIK, there is no way to execute csrf attack , if both above things are configured properly.

I assume that by Json Applications you mean a web service (HTTP API) which only accepts the JSON content type for incoming requests. Basically it is correct that if you check for JSON content type in all of your requests CSRF would not be possible since HTML forms only send url encoded / form data / plaintext content types and AJAX requests are blocked by the browser thanks to the same origin policy.

My understanding is that this is an extra security measure, applied as an automatic framework that adds the CSRF protection to all incoming requests, hence covering for some API call implementations which forgot to validate the content type such as GET requests that don't accept any content at all, or for allowing the usage of different content types in the API.

By the way - the crossdomain.xml file which you referred to is platform specific to Flash and Silverlight. The corresponding technology in HTTP terminology is called CORS (cross origin resource sharing) and one must make sure that CORS is not enabled by the server in order for your assumption to be correct.


safe methods of generating session keys So I have this web app where I'm supposed to generate my own session key to use in the session manager. I just have few questions about safe approaches to this.

I believe to make this safe it should be a randomly generated key and is unique in every instance of my web app processes. Is my assumption correct?
I'm using Go 1.2 for my web app and the way I'm generating this random string is by using the following function:

func generateRandomSessionKey() string {
  rand.Seed(time.Now().UnixNano())
  alpha := "abcdefghijkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789~!@#$%^&{}[]:,.*()_+-/?><."
  buf := make([]byte, KEYLENGTH)

    for i := 0; i < KEYLENGTH; i++ {
        buf[i] = alpha[rand.Intn(len(alpha))]
    }

 return string(buf)
}

This function produces strings like: Hu@$pMaNZd.2)%Lpeet{6hYmKAxn:yYt

Now I know that some might argue why not use "crypto/rand" instead of "math/rand" which is proven to be more secure, I have tried that and apparently the crypto/rand generated invalid strings e.g. \x16 that cannot be used by the web framework I'm using ( Beego). So is what I'm doing here a sensible and secure approach to generate this key?

crypto/rand generates binary strings. Of course, binary strings cannot be used directly as plain text. You have to encode them into an appropriate text representation first (e.g. base64). Similar to your provided code you could use crypto/rand as follows:

import ("crypto/rand")

func rndString(n int) string {
    const alpha = "abcdefghijkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789~!@#$%^&{}[]:,.*()_+-/?><."
    var bytes = make([]byte, n)
    rand.Read(bytes)
    for i := 0; i < n; i++ {
        bytes[i] = alpha[bytes[i] % byte(len(alpha))]
    }
    return string(bytes)
}

You should never seed the random number generator with the unix time. For any time an attacker could generate valid sessions very easily. If you are on a Linux system and if you really want to seed a PRNG you should read the seed from /dev/urandom which can be treated as a regular file on Linux systems.


Nmap filtered or closed When I scan one host(A) on my local network with nmap from another computer(B) on the same subnet it shows all 1000 ports closed.  When I scan the other computer(B) with nmap from computer(A) it shows 999 ports filtered and one closed port. Both of the computers are running the same operating system and are connected by Lan cables to a wireless router.  Why would one show mostly filtered ports and the other mostly closed ports and which would be the worse case of the two?

I used the command "nmap 192.168.1.X" on both machines to scan the other machine. Why the differing behaviour?

Why would one show mostly filtered ports and the other mostly closed
  ports and which would be the worse case of the two?

Assuming that you are describing a TCP (full or SYN) scan, then the difference has to do with the way the different hosts deal with unwanted packets.  Closed vs. Filtered does not represent much difference in security terms; in both cases, traffic is not permitted.  It's how it's not permitted that makes the difference.

A quick primer - to set up a TCP connection, the Client and Server exchange three packets, the so-called "TCP 3-way Handshake":

Client -> Server: SYN       ("Can you hear me?")
Server -> Client: SYN/ACK   ("Yes, I can hear you.  Can you hear me?")
Client -> Server: ACK       ("Yes!  Let's get talkin'!")

Nmap uses this exchange in two basic ways:

In an nmap SYN scan (-sS), nmap sends a SYN and waits for a SYN/ACK back.  If it gets one, instead of sending ACK it sends a RST to reset the connection instead of sending an ACK to finish nailing it up.  This has the advantage that the scan only touches the OS, not the application level; since the OS won't tell applications about a connection until it's up and running, the applications won't be logging the connections made by the scanner.

In an nmap TCP scan (-sT), nmap sends a SYN, waits for a SYN/ACK, and then sends an ACK to finish the connection.  This is a "surer" scan in that it proves full connectivity is possible, but it is noisier in the logs.

The thing in common, here, is that nmap waits for the SYN/ACK to determine if the port is open.  But there are three possible "responses", depending on how the target is configured:

Server -> Client: SYN/ACK   ("Port is open, application is listening")

or

Server -> Client: RST       ("Port is closed, server told the client so")

or

Server -> Client: (nothing) ("Port doesn't seem to respond, but not sure why")

Now, the latter two states represent different firewall configurations.  A firewall that is configured to block traffic will respond with a RST, giving nmap a clear signal that the port is unavailable.  On the other hand, a firewall that is configured to silently drop traffic will not respond at all.  Nmap draws a negative inference here and assumes access to the port is being filtered by a firewall.

And that's why you see closed on one system and filtered on the other.  In the first case, the host or firewall is returning RST in order to block unwanted packets, which gives nmap an unequivocal signal that the port is closed.  In the other, the firewall is silently dropping packets rather than noisily rejecting them, and nmap can only infer that the ports are closed.

In Security terms, there's no real difference.  In both cases your packets are not reaching the server.  In some cases an attacker can make inferences about your security posture and concerns from the way and the places you apply blocking or filtering, but that's a subtle aspect of reconnaissance, and much less important than actually blocking traffic you don't want.

There is one important caution that you need to have when scanning.  If a target is configured to block connections, and send you a RST for each attempt, then scanners may interpret non-response as an open port, rather than a filtered port.  The scanner says "Hmm, 65534 ports responded with a RST, but 1 port did not.  That port must be open!"  But if there's any packet loss - which can happen when scanning over the Internet, or even scanning locally with an aggressive enough (fast packets) scan profile - then that missing RST might be a lost packet rather than any indication of what filtering is or is not in place.  It's good practice to verify open ports manually after the scan, especially if you see open ports that don't make any sense (e.g., very high ports).

  When I scan the other computer(B) with nmap from computer(A) it shows
  999 ports filtered and one closed port.

Understanding how scans work - as above - may allow us to interpret their results more clearly.  What I would infer from these results is that 999 ports are being silently dropped by the firewall, but that one port is being permitted through to the computer(B) by the firewall, and that that port is actually closed (not listening) on the host.  So where the firewall is configured to silently drop, the actual host will respond with a RST like it's supposed to.


Are firewalls required if using a VPN If you are using a VPN to transmit data from router to router, do you still need a firewall?

I am using a VPN Server to encapsulate data from one cisco router to another. Do I need to have a firewall in front of each of the routers?

If I do, do I still need a firewall if I am using a Cisco VPN Server with inbuilt firewall functionality?

While reading around this topic found two intresting answers :

From cisco Forums :

  An IPSec VPN only provides protection for the traffic that is being
  transmitted through the VPN. It provides no protection about any other
  traffic that might be received. I have deployed many VPN routers where
  we provide protection against other traffic. I am surprised some times
  at the amount of other traffic, which includes probes of the network
  and things that are likely attack attempts, which we detect and
  discard at the edge of the remote network.

  Depending on how the VPN is terminated (on an Internet facing router,
  or a concentrator or other device behind the edge of the remote
  network) the firewall might be positioned between the VPN termination
  and the remote network in which case it will see the all of the
  traffic and be able to evaluate it. Or the firewall might be between
  the VPN termination and the remote network edge in which case it will
  see the IPSec traffic but not be able to evaluate it while it can
  evaluate all other traffic.

And also view this :

VPN Behind firewall :

VPN Server Behind the Firewall on the Internet

Image credit : Technet forums


How secure is the phone dial? A renown online bank uses a phone dial login system (input your login and password via the phone dial pad). How secure is this communication against MitM and similar attacks?

Considering I recently read how many major telecommunication networks had backdoors in them I am considering this to be bad news.

With either rotary or touch tone dialing, if you can hear it then you know what was entered. The ticks/tones are designed to be unambiguous to the recipient.

So, any listener can recover the digits easily. Modern attackers will capture and analyze the audio, and the tones were designed to be distinctive to equipment from the 1970s/80s. Some old school phreakers can do it by ear.

All of the phone networks---POTS (landline), VoIP (internet), and SS7 (cellular)---networks have serious vulnerabilities. (Note there is a category link on that summary page.)

These security issues are on top of the fact that law enforcement, spy agencies, and corrupt employees/officials can tap the phone lines.

There is little security, and a lot of it is broken. Properly encrypted email is far more secure than standard phone calls.

As a general rule, phone- and SMS-based security processes are inadequate. They provide the appearance of security, but they will stop only low-effort or unskilled attackers (which, honestly, is the largest group of would-be attackers).

If someone targets you, they can get those credentials relatively easily. In this case, the biggest risk factor is the likelihood that you will be targeted. For most people, that risk is quite low.


What to do with the shared secret? I've been using Diffie-Hellman (although, now looking into SRP) for sending data encrypted between two hosts. After the initial handshake, both the end hosts have generated the same shared secret. So, I immediately made the assumption that the shared secret can be used as a "password" in a cipher, since, I can safely assume that only the hosts will know about the secrets, and no one else. But that was purely out of my own assumption, that is without consulting anyone who is actually seasoned in information security.

I was hoping some of you can give me an idea about what to do once the shared secret has been generated. Is it a password for a cipher? Or must I take an additional step?

It's "secret" enough to be used as the key to a cipher, but it might not be long enough. The concept of key stretching was invented to bridge that gap. Basically you run the small secret through a cryptographic function to create a big secret.

An algorithm specifically designed for this function is PBKDF2 ("password-based key derivation function version 2"). It does very much precisely what you're looking for. You can use this same algorithm with slightly varied inputs to create multiple independent keys.


What was the real reason for dropping reflected-xss directive from CSP? There were two response headers which could be set by servers to instruct browsers to enable heuristics based reflected XSS detection and prevention in the past.

X-XSS Protection: 1; mode=block
Content-Security-Policy: reflected-xss

X-XSS Protection
This header according to MDN;

Chrome has an "Intent to Deprecate and Remove the XSS Auditor"
Firefox have not, and will not implement X-XSS-Protection
Edge have retired their XSS filter

Content Security Policy
The CSP 2.0 nor 3.0 specifies a directive reflected-xss. It was in the drafts of CSP 2.0 and most modern browsers does not support it (Chrome) or have no mention of the directive.

Is if it a fair assumption that modern browsers do not have any heuristics based XSS protection that could be controlled by a server header?
Are there any other XSS protection headers which are widely adopted?

I think the Mozilla link you provide has enough in it to answer your question (quotes taken out of order from the thread so I can tell a better story):

  Firefox could do better using a (probably more expensive) algorithm such as the one described here (http://seclab.cs.sunysb.edu/seclab/pubs/ndss09.pdf). Interposing on script execution instead of HTTP traffic (as this paper does) makes for smaller strings to match which probably do not cause a big slowdown with this algorithm.

So this heuristic XSS Protection algorithm relies on a pile of string compares between the URL and the page content, and therefore will be frowned upon by people who want to keep the browser's CPU footprint down.

  While we wait for browsers and websites to adopt CSP, a protection against reflected XSS attacks could be a useful addition to Mozilla. In fact, it could be implemented as a default CSP for websites which do not provide a CSP.

The implication here is that a generic heuristic running in the browser is strictly less effective than the devs of a given website providing a properly-implemented CSP saying what content should be allowed to run on their page.

  There have been numerous discussions, the latest one in late 2016 and we
  had come to the conclusion that it is currently not worth the effort for
  Firefox to provide a built-in feature:

  An XSS filter can not protect against stored (aka persistent) XSS or DOM
  XSS, which has become more and more prevalent recently.

  An XSS filter is prone to security holes if not maintained very
  diligently and actively. It is hard to justify security engineering time
  on a feature that provides limited value.

  Lastly, there is an XSS filter in NoScript that people can use.

This one kinda speaks for itself that the XSS Filter is, at the end of the day, not that effective.


Could mint.com be more secure, and if so, how? After reading a bit about mint.com on the money stack exchange, I wanted to give it a try. But frankly, it scares me a little bit.

The site has a bunch of links explaining how they're so secure. I bet it's all true and I believe them that they take a lot of security measures. But one thing is misleading. They act like the site is safer because it is "read only". From their security page

Mint is a "read-only" service. You can organize and analyze your finances,
but you can't move funds between–or out of–any account using Mint.
And neither can anyone else.

That's not what I'm worried about. The thing I'm worried about is if somehow someone steals my passwords to my banking sites. Then they can go and do stuff with my accounts.

This got me thinking, is there something better we could push for to make this kind of service more secure? A few things I can think of off the top of my head that might be on the right track:

one-time passwords / two factor authentication. I think the main problem with this is that all the services mint is accessing would need to work off the same one-time passwords so that the user would not have to enter each one for n services. This means you need a third party to handle this.
Push instead of pull. Other sites would have to add a mechanism to export data to mint. Obviously tough for mint because it requires cooperation -- but seems great for the consumer.
Getting special auth tokens to give to mint instead of my passwords. Potentially support a mechanism for mint to be able to prove its identity so you only someone who proves they are mint.com can use the token (so stealing the token is not useful unless you can prove you are mint.com)... I guess I'm in OAuth territory here?

I suppose other things that would make me feel better but aren't truly more secure: if all these money/banking sites could send access notifications. Then I might be able to know when mint is accessing vs someone who stole my data and I might have a fighting chance at reacting.

So I suppose I'm asking: what are your ideas on how this could be better? What would the perfect system look like if all these companies would cooperate? Is there a standard protocol for this kind of thing that could become more widespread so that more specialized services could sprout up like this and people could rest easy knowing their data is safe?

(FWIW, I might try it out anyways. If I do, I'm changing all my passwords just for this experiment, then changing them all again once I'm done trying it out.)

From what I can see this appears to be an aggregator for financial services. For it to have any useful function, that implies it must, at least temporarily, store your account details and authentication credentials - in which case it is far from "read-only". That the providers then state the exact opposite in the security statement makes me think these are not people to be trusted with my account details regardless of how sophisticated their controls are.

Ramhound suggests that mint.com uses an oath like system - but that still uses a temporary surrogate token for authentication. Ramhound also states You never give Mint your banking information yet the first question in the FAQ is Why does Mint need my bank login information (username and password)?. The FAQ goes on to explain how mint stores this data.

Such aggregation does have an intrinsic value, and one way to add value to such a service would be to provide better authentication security than that enabled on most financial service providers websites - but obviously this is not the case for mint.com. There's also a question of whether such a provider is subject to the same legislative constraints as a source provider.

But unless you're the guy who writes the mint.com software, isn't a question of what it should be like pure speculation?


Why is FF in Kali making requests to ocsp.digicert.com? Warning -> n00b here!

For some time now I am learning the tools for pen-testing but I am still complete n00b. I have installed Metasplitable2 in another computer on local network and I am running Kali as VM on my computer. So I have started BurpSuite to capture traffic to :8180/admin/ on Metaspoitable2. But to my surprise I saw (apart from the expected traffic) POST requests to ocsp.digicert.com. My Kali installation is default (no new SW installed). So my question is: why is Kali browser making POST requests to ocsp.digicert.com. Is this normal?

This is perfectly normal. ocsp.digicert.com is the server used to verify if an SSL certificate issued by DigiCert got revoked. This is done using the OCSP protocol.

For example the certificates for mozilla.org or addons.mozilla.org are currently issued by DigiCert. This means it will likely check at startup for extension updates and/or browser updates by using HTTPS and will in this context check that the certificates for these domains were not revoked.


Extracting features from PE files. Machine learning and malware Are the features which can be extracted from a PE file (some information from headers, section names, strings, import, export sections etc) enough to use them to train particular machine learning algorithms to detect whether the suspicious file is malicious or not?

I have met with two different opinions:

The first option states that these features are enough to create a basic detection system. Additionally, to increase in efficiency and accuracy, the behavioral attributes (e.g. API calls) may be included.

But the second opinion states that these attributes are useless in many cases because a lot of these features are redundant and redundant features can hurt the quality of a model.

I'm also wondering if it is possible to detect if a malware sample is similar to another sample and imply that one is a variant of the other? Is this kind of information useful in malware detection?

If you encounter a packed malware the features extractable from the PE file and its imported library functions probably won't get you anywhere. That is because there will only be little imported function calls and the header information can be modified to misguide your learned model of a malware.

Note that the fact that an executable is packed is not sufficient to determine it as malware as also normal programs can do that.


Would I create a WiFi honeypot by setting up a fake network with a generic name like "linksys"? On this page Apple says the following:

  SSID (Service Set Identifier—Wi-Fi network name)

  The SSID, or network name, identifies your Wi-Fi network to users and
  other Wi-Fi devices. It is case sensitive.

  Set to: Any unique name.

  Details: Choose a name that's unique to your network and isn't shared
  by other nearby networks or other networks you are likely to
  encounter. If your router came with a default SSID (network name),
  it's especially important that you change it to a different, unique
  name. Some common default SSID names to avoid are "linksys",
  "netgear", "NETGEAR", "dlink", "wireless", "2wire", and "default".

  If your SSID isn't unique, Wi-Fi devices will have trouble identifying
  your network. This could cause them to fail to automatically connect
  to your network, or to connect to other networks sharing the same
  SSID. Also, it might prevent Wi-Fi devices from using all routers in
  your network (if you have more than one Wi-Fi router), or prevent them
  from using all available bands (if you have a dual-band Wi-Fi router).

(emphasis mine).

I've been always wondering if this could be the case in real life?

Are WiFi devices connecting to the remembered access points using their SSID, or BSSID?

To avoid the security hole that is pointed out by Apple, where someone puts  WiFi honeypots named netgear, linksys to mass-grab the passwords, (taking advantage of devices whose owners have devices that will try to auto-connect to such a network), I'd imagine the devices should connect to a BSSID, and the SSID would be only displayed to the user to have friendly UX.

But maybe I'm wrong and the devices really do connect by SSID?

Devices connect to a Wifi network through SSID. It's because that each BSSID can have multiple SSIDs(for example, one for home users, another one for guests, and so on...) and had they been connecting through BSSID, they wouldn't know which SSID to choose.

Also, in large Wifi networks, where more than one BSSIDs are required to cover a large area, a single SSID is chosen(with the same credentials), i.e, multiple BSSIDs broadcast a single SSID, so that you can roam through the large area without fearing disconnection. Your device will simply hop onto another BSSID(with the same SSID, of course), without any intervention required from user's side.


Malicious Software alert from US Department of Health and Human Services I have received a mail from a certain Security Incident Response Team on behalf of a US Department and it says,

  The below URL is currently being used to deliver a payload of malicious software to a visiting victim’s computer. The current malicious payload appears to be on a server under your control and we are working on behalf of US Department of Health and Human Services (HHS) to remove the infectious content.

  The above URL has been compromised, code containing a malicious iframe that points to the RIG exploit kit has been added to the website. A sample of the iframe pointing to the RIG exploit kit is below.

  3) On a Linux or Mac system, open the Terminal and execute the following command after removing all bracket characters – these: [] – and changing all instances of "hXXp" to "http":

  curl -H
  "Referer:hXXp://www[.]ourhostedweb[.]com/index[.]php/url-name/"
  -H "User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" "hXXp://www.victimweb[.]com/"

  Search for the term "iframe" in the returned source code. There will be an iframe on line 105 whose source URL is the exploit kit content. Currently this content is being sourced from www[.]ourhostedweb[.]com – this may change at any time as long as the site remains compromised.

and the line number 105 contains the following iframe code:

<iframe src="http://gone.MDVEND.COM/?oq=m3WpvAoLeZRbFLhhUPULVAwn45aBlIX_qmnhkjUyRDK1sWA-xOKUTp1u9CWUbI&es_sm=147&q=wXjQMvXcJwDQD4bGMvrESLtNNknQA0KK2Iv2_dqyEoH9fmnihNzUSkr26B2aC&ie=Windows-1252&sourceid=yandex&aqs=yandex.114e103.406b1a7" width="258" height="266"></iframe>

  Edit
  given contact in the mail Email: alert@internetidentity.com
  Office: +1.253.590.4100 x0 | Fax: +1.888.239.6932 x0

The site is developed by using Wordpress.

What are the necessary actions I can take for this?

Just by reading the first paragraph, I'm now 99.9% sure that this is a phishing mail.

tl;dr: Ignore it.


If your OS has up-to-date security, what does a virus scan accomplish on Linux I am talking about AV scanners that are meant to scan for Linux Desktop systems, such as rkhunter. These scan for known Linux rootkits/worms/malware. But if they are known, shouldn't your system already be patched to defend them?

And another question that is due to my ignorance on antivirus. How do viruses work on Windows? Since the scanner is scanning known malware signatures, shouldn't Windows already have security that defeats the malware? Obviously I am missing something.

The misconception here is that exploitation isn't always a part of an infection. When an os is being patched it is being protected against a bug that might allow an attacker to infect a computer. But an attacker doesn't need to use a bug to gain access, and if he does use a bug it isn't necessarily part of the os (might be in an installed service, browser, app). Think about using social engineering, using a password you obtained somehow, or even using a browser exploit which is agnostic to the os version as you only exploit the browser's process.

Virus scanners add another layer of protection, if the malware was installed using credentials, social engineering or maybe even a zero day, if it is known you will still stop it.

As a concept security is always built in layers, assuming that the more obstacles you put attackers will have a harder time, which assuming you are not a high enough value target will make you an undesirable or practically safe.


How can I compare GPG encrypted files in order to upload only the ones that have changed? This question follows this one, in regards to encrypting files individually in order to upload them to a cloud service.

--- Scenario:

I have my folder full of unencrypted files
Via script I make a shadow copy of all of them
Via script I encrypt them one by one with recursive GPG encrypt commands using my own public key the --symmetric option and a dedicated passphrase
Via syncing app I upload them
Via script I delete the shadow copy (not sure about this one: but how could I later compare unencrypted and encrypted files in order to figure out which ones need replacement?)
By the time I re-run the procedure, some of my original files have now changed. Ideally, only these ones will need to be uploaded. I repeat points 2. and 3. so comparison with the encrypted files on the cloud (via sync app) can happen.

--- Question Major Problem:

Considering that two copies of the same files encrypted with GPG will never look the same (see answers to this question), how can I achieve comparison between the encrypted files?

Or should my procedure be completely different?

You can't compare encrypted file contents if you're using gpg.

You have two ways forward that I can see:

Build a hash (say, sha256) of each file before you encrypt it and store it somewhere. Compare the hashes instead of the files. This might become a performance bottleneck if your files are very large. You can check whole trees by building hashes of hashes kind of like git does it. I have a python backup script that does this to detect changes in a large file base; you can have the script if you're interested. You'd have to add an encryption step to it, though.
Look at the modification time of the file content (this is stored by every filesystem along with the file content) to find out whether a file is newer than another one. This is incredibly fast, but you need to take care to get a working system.

However, no matter which way you go, the following problem (from your first comment) will haunt you:

  But I'm still confused as to when the comparison of timestamps should happen, and between which groups of files. [the emphasis is mine]

This is a fairly difficult problem burried in every sync scenario: If you have two sets of files (e.g. two file trees), you need a way to figure out which files in tree A should be compared to which files in tree B. This isn't a problem when you just modify file contents, but what hapens when you add a few files, rename others and delete still others? You basically need an algorithm to determine the edit distance, and a tree editor (to determine and apply a small, or the smallest, set of operations that will turn tree A into tree B). I believe this is an O(n^2) problem and it's an algorithms question, not a security question (e.g. you should ask it on one of the stackexchange sister sites).

Also, if you want your solution to work for file trees, not just a single folder, I doubt you can solve this with a small batch script; like I said, I did something comparable for backup purposes and my script has grown to considerable size (e.g. thousands of lines).


sftp first connection before exchange cert If a client connects for the first time to a server via SFTP, the first connection before receiving the server certificate is transmitted in the clear?Let me explain: it is assumed that the client wants to connect for the first time to the SFTP server, before receiving the certificate, it will send its credentials in the clear? This is the only time where the user And password are send in clear?

SFTP is an extension of SSH. The SSH protocol supports:

  There are several ways to use SSH; one is to use automatically generated public-private key pairs to simply encrypt a network connection, and then use password authentication to log on.

That is, the secure connection is created before authentication occurs. In short, username and password are never sent in the clear.


How secure are webservers from linux repos? how secure are Webserver like Apache2 or Nginx on a current linux, e.g. Debian, when downloaded from a repo of this distro? Of course, they have to configured correct and must be up to date.

If they are unsecure, what do companies do with their webservers for more security? Commercial support/patches?

Edit: In repos are not the latest versions, but old versions with securtity fixes. Are they secure like the latest versions?

The web servers you've menationed as being shipped with Linux distributions (Apache and Nginx) are two of the three most commonly used web servers (stats from the May 2016 Netcraft report).

As such it's safe to say that a very large number of companies consider them safe for widespread use on the Internet (which is by definition a fairly hostile environment).

Having those web servers installed from linux distribution repositories likely doesn't make a large amount of difference to their practical security as most/all linux distributions will provide security patches where new issues are found.  Some linux distributions will "backport" security fixes so that these are applied even where the base versio of the software is not upgraded.  This can provide benefits from a stability perspective.

As to whether they are "secure" enough for your needs, that's impossible to tell without knowing about your organisation in specific.


What are the vulnerabilities of reusing passwords for generation of keys and encrypted files? The main reason why reusing a password for different accounts is not recommended is that if the password is compromised, all accounts are compromised.

This question is about vulnerabilities other than that.

For example you may want to generate two different PGP keys, one for signing, one for encryption, that you generated through separate processes but using the same very strong password.

If an adversary has both public keys and some messages encrypted with them, is he more likely to break your keys because of the fact they were both generated by a single password? If yes why? If yes, the more keys you generate with the same password the more vulnerable the keys?

The example was PGP, but the question generalizes to any other situation where the same password is reused, in separate instances - to generate either keys, or encrypted volumes or encrypted files - that are made public.

My guess is that the repetition of a password could generate some kind of observable regularity in the keys or files. Nevertheless there's always the moment of randomly moving the mouse to generate what you want, and if files and keys get generated by different instances of random mouse movements ain't that what counts? I ain't sure.

The password (passphrase) you mention is used to symmetrically encrypt your private asymmetric key. You use the private key (not your password) to decrypt/sign your messages, this process is not affected by your password.

In case that the attacker obtains all your encrypted private keys she won't have much chance either, even if you used the same password in many cases, modern ciphers are designed to prevent that and much stronger attacks:

https://en.wikipedia.org/wiki/Attack_model


DDoS might be very unlikely to happen to my website but in any case a CDN that should protect from it slows my website I humbly assume that DDoS is very unlikely to happen to my website.
A CDN that should protect from it slows my website according to my personal experience and tests (perhaps only because of the strange demand to have all webpages redirected to www. versions when the CDN is active, perhaps not only because of that) and it's also in beta version (supplied by my hosting provider itself) so I might just want to disable it.
Given that my hosting is shared hosting, would the very fact that the hosting is "shared" and the hoster must protect the environment shared by me and other customers actually redeems me from the need of a CDN to protect from DDoS attacks?

I'm a little unclear about your last paragraph so I'll answer a bit broadly.  If you're enabling DDoS protection on a shared hosting system, doing so will protect your site and potentially the other hosted sites from DDoS.  If the other sites are not DDoS protected, an attack directed at them could potentially take your site down, even if your own site is DDoS protected.


Is there any security reason that mail services like gmail or yahoomail limit the size of file attachment? Despite the fact that Email standards such as MIME don't specify any file size limits, but in practice email users will find that they can't send very large files(more than 20 or 25 MB).
Some experts say that "you can safely send files upto 10MB between any email providers without the fear of message not being delivered"
Also I hear that over the Internet a message will often pass through several mail transfer agents to reach the recipient. Each of these has to store the message before forwarding it on, and may therefore need to impose size limits.
According to above, I have three questions that have one direction:

Why mail transfer agents need to impose size limits?
is there any security reason for this limitation?
Why the limitation has not been exceeded 25 MB until now?

Comment:"With MIME, a message and all its attachments are encapsulated in a single multipart message, with base64 encoding to convert binary into 7-bit ASCII - or on modern mail servers running Extended SMTP, optionally full 8-bit support via the 8BITMIME extension. the MIME encoding, which typically uses Base64 adds ~33% overhead"
Update: I think that the reason is not only because of mitigating DoS attack,because:
An attacker can not perform attack with one file! So he  needs enough email transfers, if he have a mechanism for performing his attack with many email, and he is faced with file limitation,instead of sending 10000 email with 50MB, he performs attack with 20000 email and 25MB size.(as an example)

MTAs often virus scan, DLP scan, or perform other scans that take CPU time.  Sometimes a MTA is on a bandwidth constrained network link.

Base64 encoding bloats a message from its binary size by 33%, which increases pressure on disk and on the network.

Exceeding these limits will cause a denial of service attack against the MTAs, or even against the host itself in the event of a NDR return message.


Securing restricted shell environments I've read a few things to indicate that restricted shells can be broken out of if not implemented properly (even wikipedia, for instance).

I'm looking for some guidance on what causes security holes in restricted shells and how to solve these problems.

I assume the main problem is the binaries that you allow the user to use; if any of these programs facilitate execution of further programs/scripts with higher privileges.
Does that mean a default rbash shell is relatively secure?
Are there any specific programs that are (more-or-less) definitely safe / not safe (so far I've seen specific examples of vim and scp used to break out)?
And are there other things to think about?

Also, are there better alternatives to using a restricted shell when you want to limit the commands that a user can run?

Update 1
Following on from what bstpierre mentioned with using ssh command=, has anyone tried using command= to force the user to run a script that took input from the user using SSH_ORIGINAL_COMMAND and then ran limited additional commands/programs based on that input?  I imagine this would have quite a limited use-case, but seems viable to me so long as the script was careful about the input it accepted.

Update 2
The suggestion I made in Update 1 turns out to be exactly what gitolite does; using command= and SSH_ORIGINAL_COMMAND, with some hook magic to differentiate between branches. Info from their docs.So I know that this method is a viable alternative, but I'm still after an answer to the original query about restricted shells.

I've set up restricted shell environments that put the user into a chroot jail. Only the bare minimum executable files are copied into the jail. The shell user has hardly any permissions in the jail -- everything is defaulted to deny, and I only provide permissions where necessary. You could combine the jail with rbash for an extra layer of protection. The advantage of a chroot jail is that, if the user breaks out of rbash, he's still stuck in a chroot jail and can't access the rest of your system. (There have been instances where it's been possible to break out of a chroot jail, but properly constructed on a patched OS it is hard to attack.)

Another point to consider is whether you really need to provide a shell. Could the service you need to provide be set up as a simple, secure web service?

Finally, if the shell is provided via ssh, you can restrict the command set available to the user by requiring login via keys and setting the command= in your authorized_keys file. You do have to be careful here, though, because if the command(s) you permit allow the user to "break out", you're no better off than with the same attack against a restricted shell.


Why stack is not at the same address when exec running in GDB During writing some basic challenges, I discover that the exploits are not working if not launched in GDB. To test this behavior, the following program print register values and code address:

#include <stdint.h>

intptr_t esp;
intptr_t ebp;

void call_me()
{
  asm("movl %%esp, %0" : "=r" (esp) );
  asm("movl %%ebp, %0" : "=r" (ebp) );
  printf("call_me: %8x\n", call_me);
  printf("esp: %8x\n", esp);
  printf("ebp: %8x\n", ebp);
}

int main(char *argv[], int argc)
{
   call_me();
}

When compiled with -fno-stack-protector and -z execstack and running with ASLR disabled (kernel.randomize_va_space=0) the program returns:

call_me: 804841c
esp: bffff720
ebp: bffff738

But when running inside GDB the program returns:

call_me: 804841c
esp: bffff6f0
ebp: bffff708

Why the 0x30 differences for $esp and $ebp ? Does GDB add something ?

The difference is very likely due to differences in the environmental variables of the process when the program is run with gdb  compared to when it is run outside of gdb. Since environmental variables are stored on the stack, this can affect the memory locations.


AES 128 and Cryptoperiod I'm trying to determine how much risk I'm exposed to by using the same AES-128 key for files.

I tried to understand https://securityncompliance.wordpress.com/2014/04/19/cryptographic-keys-and-their-cryptoperiod-nist-recommendations-2012/ which says something like '>2030' but I don't know what that means.

For example, if a 'would be' hacker had 2,000 of my encrypted files but not the AES-128 key, could he realistically crack it?  How about 2 million files?

I agree that website is confusing.

As I understand it, ">2030" means that we expect the AES-128 algorithm to withstand the test of time into the 2030's. That said, this site (linked to by your site) suggests that you change your "Symmetric Data Encryption Key" every "<= 2 years".

Those numbers will be based on the rate of increase in computing power available to crackers. Ie "somewhere in the 2030's, it should be possible for an attacker to brute-force an AES-128 key in less than 2 years of computation.

Of course, that's barring any major breakthrough attacks against AES. It also assumes that the data you're protecting is important enough that someone will be willing to pay the equipment and electricity costs of several years of server farm time in order to get it.

The question about how many files before rotating keys is hard to answer. A better way to measure it is "how many gb of encryption" before rotating keys. As far as I know, NIST is not yet concerned enough to publish maximum amounts of data that can be encrypted with the same key. In this answer, Tom Leek suggests that you should be able to encrypt up to 250 millions of terabytes with the same AES key without any problem. Though this amount would probably be reduced if there is a lot of repetition in your files (ie they all have an identical header block or something).

What NIST has published (see NIST SP 800-38D, section 5.2.1.1)  is that you should not encrypt single files larger than 64 gb. The reason for this is that after ~ 64 gb encrypted with the same key and the same initialization vector (IV), you start expecting to see collisions at the block level. As long as your data is in chunks smaller than 64 gb, and you use a unique IV for each chuck, you're fine.


Which block cipher should be used in TLS 1.2 (while keeping 1.3 in mind)? I have been looking a bit at the various block ciphers for TLS. As everyone should (pipe dream) have migrated to TLS 1.2 by now it should be considered how to prepare for TLS 1.3, when it has been implemented.

In my daily work I have been looking into which block cipher algorithms to recommend for TLS 1.2 while keeping 1.3 in mind. On Wikipedia (the treasure trove of information) I found that AES-GCM could be a good candidate for the block cipher as it will be usable for TLS 1.3 and is one of the better ciphers considering performance (see Stanford presentation on AES GCM).

This question is in part "should I use GCM or CCM", however that is - somewhat - answered here. The important part - for me - is that the cipher to be used must be possible to compute and process using a small amount of transmission data. In my context I am limited by both processing power and amount of data to be sent, so could anyone suggest or give proof of which of the block ciphers supported by TLS 1.2 and future 1.3 are best in this regard?

EDIT:
To answer the comment.
The clients will not be browsers as such, they will use a channel secured by TLS. The engine... I am actually not sure that is fully decided. It is going to be on machines that are set up to connect to a centralized server. I realise this sounds a lot C&C-ish, but it is more IoT-ish. I hope that answers the question and helps in giving me a hint to what the answer to my question is.

In my context I am limited by both processing power and amount of data
  to be sent, so could anyone suggest or give proof of which of the
  block ciphers supported by TLS 1.2 and future 1.3 are best in this
  regard?

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

Reasons:

CHACHA20-POLY1305 cipher suites are part of TLS1.2.
Is available on LibreSSL since 2.3.0 and will be added to OpenSSL 1.1 (to be released on 2016-08-25).
Is mobile device friendly and much more efficient (especially on devices that do not support hardware accelerated AES).
Offers 256bit of security by default (unlike 128bit for AES, in most cases).
Is compatible TLS1.3 as the new version will drop static RSA and DH key exchange mechanism (RFC). ECDHE will be preferred in most cases.
Is built using an Authenticated Encryption with Associated Data (AEAD) construction like CGM (weakened. Cause: nonce reusage initial paper, BHUSA2016 slides + original paper), CCM or EAX (broken).


How does one securely create a MySQL database and user via the command line? I'm making an app whose functionality includes creating a database and its user. This is accomplished like so:

mysql -e "grant all on database.* to 'user'@'localhost' identified by '$PW';"

$PW is the password to be used. This code can be found in a shell script that is called when a user of the GUI clicks a specific button. But isn't that insecure, since the password is sent over the command line? How can I better secure my application?

But isn't that insecure,

There is no absolute scale of "secure", indeed it is not even a vector or scalar property. (IT) Security is about ensuring that your technology does not do things it is not intended to do - while continuing to do the things it should. This is a very long winded way of saying you should have told us what the threat model is.

Leaving aside the many questions about how your application persists the pasword and whether it needs a password at all and the fact that your method is dependant on the root user not having a password....

Your current method will expose the password (briefly) to other users via 'ps' on Unix/Linux (and probably something similar on MSWindows - you didn't tell us what OS this sits on, but the 'bash' tag kind of implies Unix/Linux). And if it was run directly at the command line, will be present in audit logs and your shell history - although you said this was in a script. There are potential path and alias exploits a third party could use (if they have access) to subvert the behaviour - although is starting to get a little esoteric.

So considering only the issue described in isolation, and constrained by the only tools available being bash, then:

echo "grant all on database.* to 'user'@'localhost' identified by '$PW';" | mysql

is slightly better (by default, echo is a bash builtin and hence does not start a new process with a command line).


Identify encryption algorithm for .enc files I need to identify the encryption algorithm used to encrypt some files. I have the key, but I can't decrypt it using OpenSSL, because I don't know what algorithm was used to encrypt it. Is there any way to identify these files' encryption algorithm?

You can identify:

a) metadata embedded in the encrypted file by many encryption tools - including algorithm name and mode

b) several old, weak encryption algorithms (so weak, that it's possible to detect them by patterns or by statistic analysis in encrypted file - for example Caesar Cipher, but also many more algorithms used in 20th century even for military purposes)

c) what algorithms were possibly/impossibly used to encrypt the data, based on the encryption key structure (sizes of individual parts of the key, or simply metadata embedded in the key file)

Unfortunately that's all.

If you have "raw" encrypted file, without any headers, then you can try to analyze the internal key structure, and then try to decrypt the file using all algorithms that use decryption key with the same sizes of individual parts.

However, it's also possible, that your encryption key is not "raw" but just an input data to some transformation, eg. PBKDF2. If so, it might be impossible to decrypt your encrypted file without knowing all details about used encryption mode.


Does two factor authentication increase the attack surface? Would adding two factor authentication to an application increase the
  attack surface of this application?

I think it would, since by adding complexity the likelihood of a vulnerability in my application is increased and so it opens another path for the attacker to exploit the system.

Would this be right?

Two factor authentication is a great way to help prevent unauthorized access especially if you use a product that's already been in development and had time to mature. Should you choose to roll your own 2-factor from scratch you expose yourself to many risks thus widening you attack surface. When looking for a provider I would look at something like RSA's SecurID which is a excellent implementation of 2-factor.


MS-Word and Digital Signatures We would like to digitally sign DOC (MS-Word) and PDF documents using PKI.
Is this possible using an internally deployed CA?

I've found lots of articles getting email digitally signed but almost no reference for Word documents.

A simple Google search points to this page which explains how to sign Word documents, with Word itself. The signer must own a certificate, and the signature will be considered as valid by any Word instance only if that certificate has been issued by one of the CA that the host Windows system trusts. Most commercial CA can sell certificates which will be appropriate; see for instance that page.

For PDF files, using Adobe's product, you need the "standard" Acrobat to sign documents. However, signatures can be verified with the free Adobe Reader. Note that the Reader uses its own list of trusted CA, not that of the underlying OS; and it is more restricted. There again, some commercial CA can sell you the relevant certificates; e.g. see this page.

(For some reason, Globalsign's pages come up first in my Google searches, which is the only reason why I use them as examples.)

There also are free tools to generate PDF signatures (the format is sufficiently open for that), e.g. PortableSigner. You still need a certificate that will be considered as "valid" by whoever will verify your signatures.


Security in automated systems using Puppet and Chef In an extremely interesting presentation at Puppet Camp London, Tomas Doran suggested a pretty radical approach for keeping everything automated by managing tons of Docker containers with Puppet.

As a security-conscious person, I like the idea of Docker, as everything runs in its own LXC and I configure all services to run as non-root users.

As a systems-administration-conscious person, I like the idea of Puppet management, as I can keep all configuration in a Git repository and even maintain different environments, all in version control. The advantage is also that I have tear-down-able (is that a word?) environments that I can theoretically rebuild from scratch without too much manual intervention.

However, there are things I'd like not to keep in a Git repository, namely SSL certificates, database passwords, etc.

How do organizations managing massive amounts of machines (like CERN) use provisioning services like Puppet and Chef while still maintaining security? Certain things seem easy, like enforcing permissions on files, but other things seem difficult, like installing SSL keys  or SSH host keys, which requires manual intervention.

I used to run a puppet installation, so I'll speak to what I did then.

SSH Host Keys are ephemeral.  So, when building a new system or rebuilding an existing one, we just let new keys be generated by SSHD when it first started.  There were relatively few people SSHing into these machines, and when rebuilding the machines, we published the host key fingerprints on an internal wiki.  So an attacker would have to compromise the wiki host and MITM SSH connections, and be in place to do so immediately after the machine was built.
We always generated new SSL keys when reinstalling the machine.  One of the human steps in rebuilding services that involved SSL was generating the key, the CSR, and getting it signed by the CA and then installing the cert.  We did use a script that was prepopulated by a puppet template to have the CN & other fields properly set.

I doubt CERN has a lot of hosts with SSL certificates involved.  Or maybe they do, but have an automated CA to sign certs at puppet's request.

I also don't consider storing certs & keys in a well-controlled git repository necessarily bad.  We just took the point at which we were rebuilding a system as a great opportunity to rotate our keys.


How common and how easy is sniffing plaintext communication? So the first reason we give to encrypt content is to prevent against a man in the middle sniffing all data. That is the reason ssh is used and not telnet for example. But in today's networks where there are really no hubs and all switches how easy and how prevalent are packet sniffing attacks?

What exactly needs to be done to get into a situation to sniff data and are there any tools to help?

I am not saying anything about encryption here, its purely a question about the feasibility and/or practicability of packet sniffing attacks. In fact recording encrypted communications might be useful in some scenarios e.g. to do cryptanalysis on the data or other attacks. So how do I sniff data in today's networks?

'How common' is not answerable or useful - you need to look at your risk.

'How easy' is much simpler to answer. It is incredibly easy if you are on the same network segment as an endpoint, but it is also easy if you can compromise a router or switch.

So, if you have data communications that are a target for an attacker, then they will work out how much value that data has for them. The threshold here is pretty low, because of the ease of attack, however it requires the attacker to have a local connection of some kind.

The tools to do this are free and easy to use, so please conduct your own risk assessment to identify the risk to you.


How to check if wifi is safe while travelling? I'm quite a bit of a traveller. So i tend to just stay with my smartphone and sometimes notebook.  I'm not a security expert but i would like to check how to know if wifi is safe to use. For example, at airport or cafe. Sometimes, cafes or hotels offer wifi without password or some kind of login page before use. The one thing I'm doing right now is if i use public wifi i dont go and online shopping i just check my emails and search some train times.

However, i would like to stay safe as much as possible how do i check if the wifi im logged in is safe from sniffer?

You can't. It doesn't matter whether the wifi is encrypted or not: you can't know whether the access point is trustworthy. A WPA2 access point with a strong password doesn't help when the access point itself is a rogue access point put up by someone who may or may not be the café or hotel owner. And yes, it happens — people put up open access points with reasonable-sounding names in likely places that don't have one, or provide better signal, in order to retrieve the data of unwitting visitors.

For something like checking emails, always use HTTPS. Take extra care to verify that the certificates are valid, and if they aren't, don't connect.

For something like checking train times, it doesn't really matter. If you're accessing public data and don't particularly mind if someone learns what you're accessing, you have no need for security. If you're concerned about privacy, or if you're concerned that the information may be maliciously modified in transit, connect to a known good VPN service. Again, don't click through any “invalid certificate” warning.


Cain and Abel Sniffing vs APR I have recently been performing a security audit at work (sanctioned of course) and have seen some interesting behaviour from Cain and Abel. I've purposefully avoided using APR so that my co-workers won't freak out at security certificate errors and have only been using the "sniffing" functionality.

Somehow, Cain is still able to pick up a lot of SNMP, MSKerb5-PreAuth, Telnet, LDAP, HTTP, and FTP passwords. How is this possible on a switched environment without using APR? I checked the ARP tables on a couple other machines while running the sniffer and they all had the correct ARP entries for the gateway.

At first I thought for some odd reason we may have had hubs on our network but I checked into it and it's definitely all switched.

I've read a lot of information on ARP spoofing/poisoning but can't find much at all on the specifics of Cain's sniffer.

Tomorrow I plan on running around with Wireshark to see if I can trace where some of these packets are coming from as they could potentially be very damaging.

In essence if you are not ARP poisoning "AND" your system is not on a hub, both of which you made sure of, there should be no packets not destined to your IP(s) which should be showing up in your captures. So the key question to look at would be what were the sources and destinations in the packets where you got the passwords/hashes/snmp data from. If they are all destined to your IP then either you are running C&A on an authentication server or SNMP trap receiver or something about your switching environment is seriously wrong.


why don't we measure the strength of crypto against the cost it would take to crack it? I hear all the time how many hours it would take to break a certain type of encryption. I think this may be the wrong metric to look at ever since scaling became an easy to implement solution.

Sure you can measure the hours it would take to break AES encryption with the fastest GPU on the market and that metric generally puts us in comfort towards feeling like there is no chance our crypto could be cracked anytime within our grandchildrens' lifetimes.

The thing is though, governments aren't limited by computational power, they're limited by their budgets and the United States defense budget for example landed somewhere around $600 billion this year.

It would have to be a simple metric like how much would it cost with the best hardware on the market to crack X type of crypto within one week. or, how many keys under Y encryption could be brute forced with $10 billion of computational power within a year.

While this might seem a little out of proportion, if DirectTv can be bought for $48 billion why is it so crazy to think that a government power wouldn't throw in even a small chunk of their budget to exceed anyone's expectations for crypto cracking strength?

Sure it would be a few extra variables and make the math a little harder to figure out. Even if we just kept it simple like what is the best hardware on the market per dollar and crossed those abilities at the scale of say even 1% of a government's total budget and corssed that with the strength of different crypto algorithms, I feel like we would have a more realistic view for how strong cryptography actually is in this constantly evolving industry.

There can never be a straightforward calculation for this.

For example if you look at the LogJam attack and rainbow tables it is quite clear that there is a clear trade-off and breakdown in the resources that can be invested to crack 'every' encryption event and the resources required to crack one encryption event.

Obviously each cypher and protocol (and implementation too) will be critically examined to push both the initial investment and per encryption cost higher and higher. Logjam will push for better choices in coming years.

Candidate list of different components

Pre-Compute requirements for the specific use-case to be attacked.
On the Fly or after the fact requirements for the specific use-case to be attacked.
Number of Candidate Events for the use-case that might be attacked (by a nation state for example) The pre-compute requirement costs can be spread over these use-cases.

And these components will change quickly and the applicable use-cases will be many and varied.


MitM Traffic with Burpsuite and a Mobile Device doesnt show up anything I try to Man in the Middle the traffic of an App to a Cloud.
For this purpose I use the Burp-Suite Pro Edition.

What I've done:

Setup a WiFi with an Alfa-Wifi-Dongle and create_ap; shared the network with my eth0.
Connect my Mobile Device to it and tested connection to http://example.com
Started an invisible proxy in Burp listening on *:1337
Try to route the traffic through the listener:

echo "1" > /proc/sys/net/ipv4/ip_forward

nft add table ip mitm

nft add chain mitm prerouting {type nat hook prerouting priority 100 \;}

nft add rule ip mitm prerouting iifname eth0 tcp dport 80 counter redirect to :1337

nft add rule ip mitm prerouting iifname eth0 tcp dport 80 counter dnat to 127.0.0.1:1337

Last steps are the same for any other ports I try to intercept (443, 8800 e.g.)

What I've tried so far:

Changed the Interface of the routing
Changed the Target Scope in Burp
Changed the invisible proxy to a non invisible proxy (now you know how desperate I am)
Changed the nftables destination host to only example.com
Used another proxy-host instead of localhost

The first issue I can observe in your ruleset is that your prerouting hook priority should be 0 or -100 as per the documentation, or at least lower than postrouting.

https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)

Are you Masquerading your traffic outbound towards the Internet? (pls refer to the link above)

EDIT (added for completeness) after the OP's own comment in response:

You also need a hook for postrouting for NATting to work.

nft add chain mitm postrouting { type nat hook postrouting priority 100 \; }


I want to remove my WAP access list Background:

Fabrication of data is a high security concern
Interception of (most) data is a low security concern
Destruction of data is a medium security concern (everything is backed up, but production would be crippled for hours)

Question:

I just came into a new IT position. Currently our WAP is setup with the WPA protocol and a MAC access list.

Personally I think with 60 end users and over 100 wireless devices that constantly grows and changes, managing the mac address list is ridiculous, especially since it is being duplicated over 3 WAPs manually.

Even if a malicious user got on our network, the damage they could do is somewhat controlled through group policy. The building is so big, it's just as likely someone unauthorized will just sit at a terminal and try to break stuff, I've made most users have very limited access to company data so that should be minimized.

I would like to take the approach of just not giving anyone the key since WPA encrypts the key on the users system anyway. It seems like the WPA key being secret is secure enough for wifi, am I just misinformed and is my way acceptable for my security conditions? It seems like having physically unsecured computers is just as dangerous. I'de rather not worry about wifi when it has a key on it whereas my 100s of ethernet outlets do not.

As MAC addresses can be spoofed (and are sent unencrypted), access lists based on them are ineffective. I agree that your time is better spent elsewhere. Also, WPA-PSK (aka WPA Personal, which is what I am assuming you are set up with) is in my opinion insufficient for businesses of your size. A single shared secret does not keep secret, especially when it can be brute-forced offline. You therefor may wish to invest the time you would have used maintaining your access list into setting up IEEE WPA-802.1X (aka WPA Enterprise)


How do client and server authenticate random number which is sent Both a client and a server send their random number each other in the ClientHello and ServerHello of handshake protocol of TLS. At the time, how do they authenticate the client or server which they want to communicate?

They make sure that the same ones if the session is the same because there is Certificate and CertifcateRequest after ClientHello.

Could you please help me for understanding. Thank you!

There is no authentication at the time the random numbers are sent. Instead the  client and server random are used as part of the string which is signed by by the server as part of the authentication (and also in the string which is signed by the client in mutual authentication).  For this it is not needed that the random numbers are authenticated - all what is needed is that they are not predictable and not determined by only the server (in case of server authentication) or the client (in case of client authentication).


With openssl, why does a decrypted & re-encrypted file differ from the original encrypted copy? I have a private 2048 key that I can use to decrypt 2056 bits of
encrypted data. I get out 128 bits unencrypted data. I have verified that this data is correct. (I dont know the original encrypt command).

openssl rsautl -decrypt -inkey private.pem -in data.2056bits.enc.bin -out data.128bits.dec.bin

I guess that the shrinking from 2056 bits input to 128 bits output is done  using some kind of padding.

What I would like to do now is to reverse the decryption. Encrypting data.128bits.dec.bin i would like to end up with the same data.2056bits.enc.bin that I started with. I thought that the below lines would do this:

opendssl rsa -in private.pem -pubout > pub.pem
openssl rsautl -encrypt -inkey pub.pem -pubin -in data.128bits.dec.bin -out data.2056bits.enc.bin

However data.2056bits.enc.bin is different than the one I started with.

It is however a valid encryption. I can do a

openssl rsautl -decrypt -inkey private.pem -in data.2056bits.enc.bin -out data.128bits.dec.bin

again and end up with the same data.128bits.dec.bin.

What am I dont wrong? Can there be 2 different data.2056bits.enc.bin s that yield the same data.128bits.dec.bin ?

One of the basic goals of cryptography is that someone who intercepts encrypted messages shouldn't be able to learn anything about the unencrypted originals. If you can determine whether two encrypted messages have the same content without actually decrypting them, then you've found a weakness.

To prevent that, an encryption scheme must produce different results when encrypting the same message twice. The padding that is added when you do an RSA encryption is different every time.

If you want to study RSA without padding (a.k.a. "textbook RSA") you can use the -raw option to rsautl. The input must be exactly the size of the key modulus since there's no padding. Just make sure you don't use it for any serious application.


YouTube channel gone crazy! OK, I use youtube just for listening music and watching videos. I don't upload, and I don't comment. Sometimes I do like some videos/comments.

But today I accessed my channel and I saw like 20 comments from my account.

They looked like this:

  "Yes i mean it. this is really fantastic. and i can tell u , really
  lucky that i registered and got my dream fresh products from
  maybelline for nothing :). its worth a try here => "

Any ides on how to prevent this in future, or report. Any idea is appreciated :)

Most probably, your account is compromised. Change your password and use Google's second factor authentication if possible.

There is also the possibility that you have malware on your system that will use your active sessions to post this kind of spam. Use a free AV and consider buying one.

Update:

I looked for your spam message, followed the link and landed on a site that enticed me to download malware detected by very few antivirus products. This adds to the probability that there is malware on your system. Antivirus should be your first action but re-installing is the safest way.


How to Protect Webservice on Private Network? We are building a webservice that will only be queried by other servers on our private network. I was suggesting that we put that webservice over https and use either client ssl authentication or a password that we would send with every request to protect unauthorized access to the webservice.

The webservice is able to make modification to the data in our databases so if an attacker could access it, he would be able to alter our important data. So, I thought it was important to protect it properly but when I talked to the network admin, he dismissed my concerns as paranoia and said that the webservice will be on http without any authentication. His argument is that the webservice is on our private network and behind a firewall so we don’t need any other protection.

I’m not sure what to think… Should I worry that we will have a webservice over http without any authentication?

EDIT

Would using a password without TLS be enough since it's on a private network? The "issue" really seemed to be around wasting time to setup TLS for "nothing".

Short answer is "yes - you should worry".

Modern attacks almost always target clients; and once an attacker has a toehold in your network he/she can pivot to any resource the client has access to. He/she may also be able to "man in the middle" traffic on your LAN; or better yet - gain credentials to the switches/routers and sniffers in your network.

So I'd suggest you definitely should use https (TLS 1.2 or better) on the web service. Sessions should also be authenticated: for user convenience you may need to use some kind of session cookie or "single sign on" with Kerberos or similar.

In addition: your database server should be protected. Is there any reason for clients to directly connect to it? Probably not. So use some kind of firewall in front of the database server to limit inbound connections: only your web/application servers and systems management servers need access!

Firewalls on the perimeter are important but they are far from being the only defense you need. For background consider some of the high-profile breaches we've seen in the news recently! Access wasn't obtained by breaking through a firewall - almost always it was obtained by compromising a client that is already inside the network.


Is it still possible to run an online dictionary attack from a single machine, without anonymisation? This question concerns dictionary attacks conducted:

Over the Internet, using programs like THC Hydra
Via protocols such as HTTP, FTP and SMTP

I believe I'm right in thinking that: a) due to the sophisticated layers of security they tend to employ, such an attack cannot be run successfully on the bigger sites (Facebook, Twitter, Gmail, Outlook and so on) without needing to mask your IP, channel the attack through the Tor network and distribute it among an army of botnets; b) that the efficacy of these attacks on smaller self-hosted sites is limited only by the competency of the person(s) running their servers.

However, what about the gap that occupies the (arguably) larger space in between the two - the medium-to-small web hosting providers that the rest of the web relies on for uptime.

On average, is the security of these organisations generally advanced enough to detect a guessing attack from a single IP address and permanently ban the address over those protocols? Is anonymising yourself during an attack on such a target just as much of a necessity as it would be when targeting the big sites?

Or to put what I'm asking another way: has the security of the smaller web hosting organisations now become sufficiently advanced enough so as to make guessing attacks from a single machine, without anonymisation, entirely obsolete?

I ask this because none of the write-ups I've seen on the topic (guides to the use of THC Hydra and similar programs for both dictionary and brute-force attack) so much as mention either anonymisation or the distribution of attacks with bots, and it's left me wondering just how necessary or unnecessary such steps are when doing so.

Are there hackers that are actually getting anywhere without taking those measures?

The security of a web site is not related to the size of the company. Large companies like Sony were hacked and they used poor security practices (clear text passwords). On the other hand, an individual site that would have a security specialist as admin would probably use up to date security protection. The only rule is that the security of a web site is limited by the capacity of its security admin. It includes both raw competences but also financial resources, because physical security only comes at a cost.

Now the remaining part of your question is mainly a question of resource and knowledge between the attacker and the defender: best of the two will win. For the attacker it means a successful exploit, for the defenser it means at least a unsuccessful attack, but the goal is often the identification of the attacker. This is a constant whatever you use as anonymization tools: nothing at all is enough if the target is not interested in knowing who you are, but I would not rely even on TOR to attack the NSA...

That means that if you attack a site, all depends on what you are attacking:

if they have little interest in security, your attack is likely to be unnoticed, and could even be successful
if the use average security, your address will be banned before having a chance to be successful, but things will not go further
if they protect highly sensitive informations, chances are that you find some policemen knocking at your door - or even more drastic action if the site was owned by a criminal organization...

TL/DR: it makes sense to explain how to use tools to attack sites, because this is useful knowledge for pentesters, you can also find some guides on how to protect your anonymity from average sites, because many people do not like to be excessively tracked. But it is unlikely that you find a security specialist to explain how to build an attack from the beginning, because 1/ they are not interested in teaching that and 2/ they know that there is no fit all way.


PHP processing form submission, how can I best protect sensitive information submitted via the form? I am using PHP 5.6 on Apache 2.4

I have a form that will collect sensitive information about the user that need to be encrypted. My current solution grabs the sensitive information from the POST and immediately one way asymmetrically encrypt it with a public key before storing it the database. I will be using SSL on the site.

My plan is to retrieve the encrypted version and decrypt locally as the information is needed, and when the data isn't needed further, I am going to delete it entirely.

I am worried that if the server is compromised and a hacker is capable of knowing that the above is going on, there is an opportunity for the hacker to write a script to collect the POST data before I can process and empty it.

I have looked into encrypting the information before the form submits via JavaScript, but I am concerned about CPU / memory load it would cause on the browser.

Are there any better ways to make sure at no point can someone, via an injected script, access the POST data? Or am I just being extra paranoid?

Clarification:

I am encrypting the sensitive information with RSA 16,384 bit public / private keys. The average size of the information block is closer to 8000 bits, but the 16,384 bit allows for extreme use cases.

Only the public key is on the server, I process the information into a JSON array and then use PHP's openssl_public_encrypt() function. I then store the encrypted block in MySQL.

When decrypting the information for use, I download the encrypted block via a secure admin portal (HTTPS, CSRF token, recycled one way hash password comparison) and decrypt using a JavaScript based library on my local machine.

This is my worst case scenario

Prior to this project, I would have agreed with the sentiment that if a hacker is on my system, then I have bigger problems. However, a hacker sniffing this information prior to the encryption is exactly the biggest problem I have. It's not CC#s, I am handling that via Stripe and 100% PCI Compliant.

However, I would have equal, if not greater, liability if this information was compromised.

That is why I am going to such extremes as handling decryption locally. I have read the PCI compliance basics, such that sensitive information needs to be encrypted in transit and in storage, but there seems to be a gap during processing even there. If I am wrong there, please point out documentation, so I can better educate myself.

Do not use new solution, reuse what others have gone though. A good place to start is OWASP.

For the transport, use SSL and do not manage some kind of encryption on the browser instead.

Once data lands on your server, assess whether to store it encrypted and what risk exactly you want to avoid by encrypting them. This will drive the encryption architecture (physical theft prevention? Admin access prevention? ...).

And then, the absolutely key is to make sure your application is coded correctly. The OWASP link above will point you to generic cases and specific implementation solutions (for PHP for instance)


Database table name prefixes and security by obscurity One of the most common pieces of advice with respect to securing WordPress, Magento, and other widely-used pieces of software is to add a prefix to database table names or change the default prefix. For example, one frequently hears to change the default wp_ prefix for WordPress to something obscure, like 1sdf34jSqo8_.

The question I have is this: Isn't this no more than security by obscurity? And if so, is it a good practice to do it anyway?

The pros and cons that I see to this are:

Advantages:

Many SQL injection attacks necessarily have two steps: identify the tables and then do something else. This doesn't prevent attacks like submitting a password like xyz' OR 1=1 --', but it does prevent, say, a query like DROP TABLE foo actually doing anything, until the attacker somehow learns the table name.
It helps mitigate the nightmare zero-day attack in which there really is a SQLi vulnerability. A little obscurity is helpful in those situations.
It might make it a little easier to intercept and block certain attacks via mod_security or a WAF. For example, if my table prefix is 1sdf34jSqo8_ and that string shows up in GET or POST data, I'm going to be very suspicious of that request. But then, if the attacker has that string, I'm likely pwned already. Seeing that text from anyone not already authenticated as a superuser is actually probably a direct-to-pager alert, in fact.
It enables installing multiple copies of an application in one database, for those instances in which a host or service provider allows you to have 1 or 2 databases but doesn't limit the number of tables (which has never made sense to me, but I digress). *This isn't really a security concern, true, but it's a major reason people enable prefixing like this.

Disadvantages:

This is a huge pain to implement as a developer. It means every table reference in your code needs a constant or variable added to the table name. Simple SELECTs are bad enough; schema changes and patches can become real nightmares. This also breaks the ability of many IDEs to do things like autocompletion and spelling checks on SQL statements.
Thanks to the above problems, it's arguably more likely to result in bugs and possible vulnerabilities due to that one time someone on your team wrote a statement like SELECT * FROM {prefix}foo LEFT JOIN bar ... and forgot the prefix somewhere.
It obviously is at least a form of security by obscurity. This leads to sloppiness, overconfidence, etc.
It doesn't solve any problems that prepared statements and whitelisting don't already fix.

I think the accepted answer to the question "Is it okay to reveal database's table names?" nicely summarizes my thoughts - you don't lose anything by revealing table names if your database is secure against injection. If there's a breach at another layer, like a successfully uploaded and executed rogue script, then (1) the table prefix will be easy to discover, and (2) you're hosed anyway.

So, the short version of the question: is this actually something developers should do when creating applications, or is it just a bad practice masquerading as an additional layer of security?

EDIT: To be clear, I'm not asking whether the end user should go ahead and change the prefixes for, say, a WordPress installation's database. I'm asking whether, when a developer is creating an application that uses a database, the developer should enable this kind of functionality in the first place.

Most modern databases store metadata in regular tables (Information Schema) so if there is an SQL injection the attacker will eventually find out every necessary information for exploitation, including your naming schemes.

In case of Wordpress and other popular software custom settings may help dodge some automated attacks, as primitive exploits may assume that standard names are used. However if the attacker uses a bit more advanced tool like SQLmap, the custom naming will be revealed almost instantly.


Check logs for Heartbleed exploit use? According to articles such as the following, it's apparently possible to check logs for heartbeat requests matching the payloads described in the Heartbleed exploit.

Is this something that any server operator can check for in their own logs (at the server level, any standard Linux distribution)? If so, which logs should be checked, and for what pattern?

From the access logs of a service (nginx, Dovecot, etc.), you cannot see whether you were affected or not. Unless you have previously captured all SSL traffic, you cannot see whether you got attacked in the past either.

The pattern to match in a packet capture is very simple:

A malicious Heartbeat request is sent.
An overly long Heartbeat response is returned (for buggy versions).

If the Heartbeat request is not encrypted (i.e. it got sent before the handshake is completed), then the data in the transport layer (UDP, TCP or an extra application-specific layer) is:

18       # Content Type Heartbeat
vv vv    # TLS version (e.g. 03 01 is TLS 1.0, 03 03 is TLS 1.2)
ll ll    # Record length (length of the following data)
01       # Message type (1 = request, 2 = response)
xx xx    # Payload length
[payload]
[at least 16 bytes of padding]

If the payload is not exactly the length xx xx (big-endian), then you were possibly attacked. It would be successful if you get a response back:

18 vv vv    # Same record layer header
ll ll       # Length of following data
02
xx xx       # Same length as requested
[data of length xx xx]

An example command (which requires root) that captures all future data from network interface eth0 until interrupted:

tcpdump -i eth0 'tcp port 443' -w ssl.pcap

You can use Wireshark to investigate the file ssl.pcap. The display filter ssl.heartbeat_message shows all Heartbeats requests and messages. Note: sometimes the SSL filter does not get applied. In that case, right-click a packet, click Decode as.. and select SSL. Since git commit 3f81af22e0116a2f83c0298de7874959b3967da2 (11 April 2014), you can also use the expert filter ssl.heartbeat_message.payload_length.invalid to target malformed Heartbeat requests (if unencrypted).

As for encrypted heartbeats... it is not common to see heartbeats, so when you got one for TCP connections, it already becomes suspicious. Some hints for encrypted heartbeats that may help:

A heartbeat request followed by gigantic heartbeat responses is a sign of a vulnerable server that was successfully exploited.
A heartbeat request not followed by a heartbeat response may signal an attempt to exploit the server, but the server is patched and does not respond.
A heartbeat request followed by an encrypted Alert may signal an attempt to exploit the server, but the server does not run OpenSSL and rejects the invalid request.
A large number of subsequent heartbeats (even if it is small) may be successful exploitation attempts with small payload lengths.


Disadvantages of HTTP GET/POST Flooding Attack? I asked about What is HTTP GET/POST Flooding Attack? recently and I got a few detailed answers about what they are and how they work.

Now I want to find out what are the disadvantages of them.

Main disadvantages (for the attacker) of that kind of flooding attack are:

Traces. If the attacker is doing the HTTP requests himself, then he must first establish a working TCP connection, i.e. one where he can receive response packets. Therefore, his IP address will appear in the logs of the target server. (Alternative is to predict TCP sequence numbers for new connections, which is nigh infeasible with modern operating systems which use decent random generators for that.) Launching the attack while avoiding retribution implies using many relay systems, which are expensive to gather, especially since most will be "burned" (revealed as relays) in the process. This contrasts with SYN floods in which the attacker can use fake, random, non-incriminating source addresses for his packets.
Scale. Serving a typical HTTP request is not very expensive for a Web server, which does that all day long. To drown it under the influx of requests, the attacker has to muster a substantial workforce, especially with regards to network bandwidth; he will not flood the server with 3 or 4 PC, rather 300 or 400 at least. Flooding is about who, between target and attacker, will have the biggest network and the fastest CPU.
Duration. As soon as the attack ceases, the target server becomes fully operational again. It is hard to obtain long-lasting effects. But the longer the attack runs, the easier it becomes for law enforcement agencies to pinpoint the perpetrator.
Cheesiness. Flooding is the level zero of attacks. It is brutal and inelegant. It has no finesse. If the attacker runs the attack in order to gain some prestige among his fellow attackers, this might backfire (floods are for script kiddies).


How are the disk encryption keys protected when a laptop is locked? If you were installing such operating system as Ubuntu, you would have seen an option to encrypt your home directory or the whole hard drive with an AES 256bit cipher.

When your laptop is totally shutdown it is absolutely impossible to read the data that is encrypted. However, when your laptop is fully on, obviously all data is unencrypted and can be read by anyone.

What I would like to know is what happens when you lock the computer? Is the data in RAM protected somehow or is the data STILL readable but just behind a password? What I am saying is if you lock your laptop, is your data in RAM still as safe as on your Hard drive when it is fully powered down.

Short answer is "data STILL readable but just behind a password". It is rare that anything in RAM is encrypted, simply because it would require some sort of a password to decrypt, and most passwords would reside in RAM anyhow.

Going a bit further with this, the decryption password for the majority of disk-encryption programs would actually also (ironically) reside in memory.

Keep in mind that Full-disk encryption (or your home directory) applies only to your drive (HDD or SSD), not your memory.