Would a custom random string do what I want? Upfront, please overlook my naivety. I have a service app that talks to a web api. I only want the service to talk to the web api, nothing else. Means I need to secure it and I'm trying to understand why I should use a client certificate as opposed to a sufficiently long random shared key/string.

The way I'm thinking about it is; I live in a house and use a key to open my front door. I made a copy of the key and have given it to a family member so they can also unlock the front door. Now back to the digital scenario, if I create a random key/string, permit only those that pass that key with requests to my web api, and get my service app to include that key in all requests to the web api, am I not achieving my goal of only allowing the service app to access my web api? Why would I need the extra complexities of creating and installing a client certificate?

Thankyou

Contrary to giving a hardware key to some family member the random string you propose is just data and could be easily copied without notice. And while you might feel that the transport of the hardware key in the pocket is sufficient protection the situation is different with data only as the key.

Still, if you protect your data key well it might be secure enough in your environment, although the exact security requirements of this environment are unknown. Protecting the key means at least using HTTPS so that nobody in between client and server can sniff the key.

But even with HTTPS it is enough that a single of the systems having the key gets compromised. In this case the key can simply be copied and misused because all systems use the same key. Assuming that the misuse of this shared key is noticed at all the only option is to revoke this single shared key which means a new shared key need to be distributed to all systems. In this case it would already an improvement if you use a different key for each system since then the impact of misuse is limited and you only need to revoke and update the key for a single client. This scheme of having a different key for each client could be simplified by using client certificates with your own certificate authority and just trusting any certificate issued by this authority.

Client certificates also have the advantage that they could be hardware backed using a smart card or similar. This way an attacker needs to have physical access to the system to steal the key. Compromising the system from remote is not sufficient, but misusing the existing key from remote might be possible if there is no local interaction required for using the key (i.e. always in smart card with no PIN). And even if the attacker manages to get physical access to the hardware key he will probably not be able to copy it with acceptable costs so the loss of the key will be noticed and access to the key could be revoked.


How to avoid leaving any local trace that I went to a website? I want to visit a web site, but I want to ensure there is no trace left on my computer that I did so.  How do I do that?

This question is not concerned with anonymity or detection on the network side, but on the local side. I am familiar with the major browsers safe browsing modes, private browsing, etc. However, that can still leave artifacts in some cases, e.g. from plugins.  Also, this question is not concerned with malware, rootkits, keyloggers, etc.  I won't be uploading or downloading files.  I'm not concerned about preventing eavesdropping of files.  Assume that I am already using Tor, a VPN, or a similar mechanism to prevent eavesdroppers, ISPs, and web servers from identifying me.

Instead, my question is how to eliminate local evidence on my machine that I went to a particular website. For example, maybe I want to check political websites but have no record stored on my local machine, even if I am using plugins, etc.

I do not want to boot a Live CD.  While I realize a Live CD could be used for this purpose, the idea is you are doing your normal Windows stuff then you want to do banking, political activities, or "leisure" browsing for a few minutes.

I was wondering if there is any real value to a setup like this:

Create a ramdisk
Install sandbox software
Get a "portable" version of the browser
Run the sandboxed version of the portable browser on the ramdisk.

My thought being, you can just kill the ram disk to delete all traces. Would you even need to use a private mode at this point? If the sandbox is prevented from writing outside of the ramdisk I would imagine you'd be safe.

The other issue would be how much of a pain would it be to set this up. Ideally, the sandbox is destroyed when the portable browser is closed; when you open the app it creates the sandbox and copies the portable version to the ramdisk-sandbox from the original version.

Does this work?  Is this an effective way to solve the problem?
Any thoughts on how to actually set this up?

Revision history:  At first there was some confusion; some folks interpreted the original version of this question to be asking about how to protect yourself from malware.  That's not what I'm looking for.  Instead, I'm looking to prevent leaving evidence on my hard disk of what web site I visited, for a particular web site, and with as little inconvenience as possible.

There are some security benefits to running the browser in a sandbox.  If the browser gets compromised, then the sandbox can limit the damage.

However, there are also serious usability implications of running your browser in a sandbox.  For instance, say you want to download a document off the web and save it somewhere for later use.  Nope, sorry, no can do: a proper sandbox will isolate the browser and prevent it from writing to the rest of the filesystem.  Or, suppose you want to take one of your documents or pictures and upload it to a website.  A sandbox has to choose between allowing this (supporting a common use scenario, but also raising the risk that a compromised browser could start exfiltrating files of yours over the network) vs denying it (preventing you from getting useful work done or limiting your ability to use certain web services).  When you try building and using a browser sandbox, you run into many tradeoffs like this.

So, a sandbox can be useful in especially security-sensitive situations, but just be aware that it comes with some tradeoffs.

One commonly-used way to run the browser in a sandbox is to run the browser in a virtual machine.  You can isolate the VM from the rest of your activities, providing isolation.  Also, if you wish, you can use a throwaway VM that restores back to a known-good checkpoint after each use, so that a compromise that occurs during one session cannot harm you in future sessions.

There is no particular security benefit to running in a ramdisk, per se.  (A ramdisk does not prevent a compromised browser from writing to the rest of your filesystem, leaving malware on your system, or doing other damage.)  I suspect you may be thinking of running the browser in a throwaway VM or some other sandbox technology that reverts back to the initial state after each session.

The simplest way to set this up is with a VM.  Another simple way is to use, as you suggest, a LiveCD.  There are also commercial products out there that focus on sandboxing browsers.  (See, e.g., Sandboxie; there are probably many others.  There used to be a company called GreenBorder that sold a browser sandbox, but it was not a commercial success and no longer exists.)  See also Is using a “Red” and a “Green” browser to balance LOB requirements and security a good approach?.


What is the point of TURNS in WebRTC WebRTC makes use of TURN-Servers if the direct peer to peer connection fails. There are two protocols available: TURN and TURNS (TURN over TLS).

According to the MDN:

  All data transferred using WebRTC is encrypted.

If all data sent via a data channel is end to end encrypted with DTLS by default, why does TURNS even exists?

Isn't TURNS only encrypting the connection between the server and the client?

Wouldn't that be unnecessary overhead?

EDIT - Why not simply use plain TURNwithout any server/client encryption? I know what TURN-servers are used for, but I do not get why we would want to encrypt the connection to the TURN-server. Because of the DTLS encryption between the peers, the TURN-server cannot read any of the transferred data. Hence nobody else can, so why even bother adding another layer of encryption?

One reason is for better firewall traversal. You can get past some stricter firewalls with TURN/TLS over port 443 to disguise WebRTC traffic as HTTPS traffic.


When should I issue more than one multi-factor device to a user? Is it OK to give several active tokens vs none at all? Most of the conventional IT.Sec thinking I've seen says that a user can only have one multi factor authentication device.  I'd like to challenge that defacto-thinking and ask if there is ever an occasion where:

More than one multifactor device (token) would be issued to a single human  (or user account)
In a ASP scenario, (or service like Amazon Web Services) when would more than one token be registered?

The key difference I'm illustrating above is corporate controlled vs web service like banking, IAAS, SAAS, etc

Should users be allowed a "backup" token if they lose or forget their primary token?  How many tokens should they be offered?

This last point would also be valid where a YubiKey Nano (or similar) is installed on a Work and Home PC.  This user may also have a travel token as well.  The concept is that the threat footprint is reduced (albeit not "perfect")

I have several multifactor authnetication devices linked to my paypal account. I also have two different multi-factor authentication devices securing my stackexchange logon.  It is definitely possible to do so.

THere are multiple requirements to do so.  One is simple convenience (I authenticate with the device nearest to me at the time).  A more formal requirement might arise because different tokens are issued at different levels of Assurance (LoA) - I have multiple credentials at different levels of assurance. It may be convenient for me to sign in with a low assurance credential, but if I want to take an action that requires a higher assurance, I may need to re-authenticate with a different credential.

@Lucas Kauffman is entirely correct; I do NOT want my admins to log in with the same credential when they are browsing the internet that they do when they are patching my servers.

This answer could easily go on at book length and be outside the scope of SEC:SE.  The National Strategy for Trusted Identities in Cyberspace (NSTIC) can be viewed as an answer to the question.


Is it more secure to program a client-server system in a language other than English? I'm developing a system with communication via REST between front (JavaScript) and back end (Java/Spring) and this question popped up.

Does it makes this system more secure to name variables, URLs, etc in a language other than English?

I imagine it could because, since the most important programming languages are in English, it's likely most programmers know at least a bit of it. Naming our stuff in another language could make hacking more difficult because the attacker would have a harder time to understand what means and does what.

I couldn't find results on Google because "programming" an "language" together makes it impossible to find results about the other meaning of "language".

Technically slightly, yes. But:

It would be security by obscurity, which is a bad idea
It does not boost confidence in your product
It would be very easy to figure out what does what, it would only take a bit of time
Google Translate, you can just use meaningless names, it would still not help much
It would make maintenance harder
It would make audits very hard, as the auditors may not understand the language

All things considered, it is probably never worth it.


What is ISO27000 (27001) and how to achieve it? I have recently came across ISO 27000. Basically what I learnt is that it is used for audit purpose in organizations. Can you tell what exactly it is, if I am wrong? What tools are available for ISO 27001 audit and how can I learn about it? Can simple penetration tools be used for the purpose?

ISO27000 has little to do with penetration testing. It's a collection of ISMS (Information Security Management Systems) standards that provide a list of controls which an organization should implement as it enables (or should enable) proper security governance.

It's more on a conceptual level and provides more a set of rules which can be used to create policies and processes.

The standards can be used for both implementation as well as auditing. Auditors will review if you have correctly implemented all concepts and acredit you with the certificate if it is deemed you have performed a correct implementation. They will request to see the defined policies and will test these against the actual situation. This is almost never technical.

One of the controls (there are several) requires the company to perform regular attack and penetration testing. The auditor will not perform a penetration himself but will request relevant reports. The policies often also define how problems should be tackled or how risks can be accepted or mitigated. The auditor will review the report and request how follow up is performed (and review if this is done correctly)


Is a mongodb build that uses the -ssl option vulnerable to heartbleed? If one is using MongoDB enterprise, or built MongoDB from source using the -ssl option (as described here), is that MongoDB vulnerable to the heartbleed bug?

I know mongo needed openssl-devel to be installed on the machine for the build to work. But is it now using that vulnerable openssl version internally and now mongoDB needs to be entirely rebuilt or updated? Or if you update openssl on the server that is sufficient?

The answer to this (not just MongoDB, but any program) is quite system dependent.

If you are running MongoDB with SSL enabled at compile time, and enabled at run-time, and it's using a vulnerable OpenSSL (1.0.1—1.0.1f with hearbeat not explicitly removed), then yes.

If you are only listening on localhost, or you have packet filtering/firewalling to allow only trusted clients you are less at risk, but you are still vulnerable of course.

OpenSSL provides two libraries, libssl and libcrypto, MongoDB uses both (this flaw is contained only in libssl). If OpenSSL is dynamically linked in, you should be able to just update OpenSSL and restart the affected processes. If it is statically linked in, you need to update OpenSSL, rebuild the affected software, stop all affected daemons/processes, reinstall, then restart them. Whether you upgrade to 1.0.1g, or a patched 1.0.1(≤f) with the problem feature disabled, see below for steps to confirm that you've properly updated.
Then get busy picking up the pieces if you have untrusted users/connections.

On most *nix systems you can run ldd against the binaries, this will confirm if OpenSSL (i.e. libssl.so) is dynamically linked. This only proves a binary uses OpenSSL, no dynamic dependency does not always mean it does not use OpenSSL: it may be static, loaded by a different dependent library, or even loaded on-demand (e.g. Apache httpd loading mod_ssl.so). mongod links directly against OpenSSL though..

An alternate approach to ldd which may be more reliable:

determine the process PID(s) then as root, run lsof -p PID or lsof -p PID1,PID2,... to see if it has the library open
on Linux you can instead cat /proc/PID/maps and check which libraries are mapped in

The above only work when a dynamic library (libssl.so) is used, if the static library (libssl.a) was used the code is present directly in the binaries, not loaded from an external library (which makes it harder to upgrade of course, most systems use dynamic OpenSSL libraries partly for this reason).

Some software (I wish they all did), tells you what build and run-time features/libs they use, by way of logging at startup or with verbose/debug/version/help command line options. For MongoDB use  mongodb --version for this. In 2.6, this calls the API function SSLeay_version(), so it will correctly show the run-time (not the build-time) version of OpenSSL, but it doesn't tell you if it's statically or dynamically linked. In the case of Mongodb, you know OpenSSL is enabled, and since the  mongodb excutable is directly linked against the SSL libraries, ldd will tell you if they're dynamically linked or not.

In other cases, you might be stuck with something unpretty to try and determine what library version might be statically linked: strings -a or objdump -s.

MongoDB provides an SSL/TLS TCP service when SSL is enabled, check if it's listening on anything other than localhost via netstat, or by attempting a connection (probably port 27017). The lsof output also shows listening ports, or try lsof -p $PID -a -i tcp for just TCP (note MongoDB doesn't run TLS on a distinct port).

If you have a recent(-ish) nmap you can use its mongodb-info script:

$ nmap -vvv -sV --version-all --script mongodb-info.nse -p 27017 localhost
[...]
PORT      STATE SERVICE VERSION
27017/tcp open  mongodb MongoDB 2.6.0
| mongodb-info:
[...]
|     compilerFlags = -Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-\
        aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-\
        pch -pipe -O3 -Wno-unused-function -Wno-deprecated-declarations -fno-builtin-\
        memcmp
|     loaderFlags = -fPIC -pthread -Wl,-z,now -rdynamic
|     debug = false
|     version = 2.6.0
|     OpenSSLVersion = OpenSSL 1.0.1e 11 Feb 2013
[...]

You can also probe for the problematic TLS extension with OpenSSL's s_client, though take care to use a recent version which sends a TLS client hello and has the heartbeat extension enabled, an SSL2 client hello will not enable the extension, nor will a client without heartbeat support:

echo Q | openssl s_client -connect myhost:27017 -tls1 -tlsextdebug

This works regardless of the SSL connection preference you are using for MongoDB.

The server extensions will be listed within the first few lines of output, before certificate details:

CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "session ticket" (id=35), len=0
TLS server extension "heartbeat" (id=15), len=1
[...]

This alone doesn't prove you are vulnerable, or that you are running OpenSSL, or even a specific OpenSSL version. If you like living dangerously, you may wish to attempt to use one of the POC scripts. (I've used ssltest.py successfully, and without crashing Apache httpd or mongod processes, YMMV.)

To check your OpenSSL version and options use openssl version -a, the presence of -DOPENSSL_NO_HEARTBEATS indicates the problematic feature has been disabled at build time. There's no guarantee that the openssl command will use the same library as anything else, to really check thoroughly you should identify all likely libraries:

find / -name "libssl.*"

The default behaviour (gcc+binutils) when searching for libraries is "first found" honoring the library directory ordering, when both dynamic and static versions of libraries found together it prefers dynamic libraries (unless -static is used, this isn't an option with MongoDB since it's implemented in C++). Even if libssl.so is present OpenSSL could still be statically linked, though for a normal build with libssl.so available, it will dynamic not be static (the MongoDB SCons build makes no special attempt to use libssl.a).


Does BitLocker with SED require a TPM? Assuming a BIOS that supports SED (Self Encrypting Drive) hard drives, and given that Windows 8 will use hardware encryption like SED if the disk has it, does BitLocker still require a TPM to avoid using USB? This regards a standalone laptop not part of a domain.

You can setup bitlocker (with SED) without TPM. But...
if you dont want to use USB and if you dont want to enter preboot password then TPM is required. TPM is required to save keys that require for SED to unlock. SED must be OPAL complied to work with TPM.


Does two-factor authentication reduce the need for a long password? I've recently enabled 2-factor auth on a number of web apps, mostly using Google Authenticator. Does this mean that the importance of a strong password on each site is reduced? I would prefer to use passwords that are easy to type on a mobile device, if that doesn't compromise security too much.

EDIT

My particular need for wanting to shorten/simplify passwords is about the time it takes to enter punctuation on a tablet/phone - 3 taps (, !, ), and 2 for a capital letter. From these answers, I'm thinking a better approach would be a longer password consisting only of lowercase and numbers, possibly with repeated letters. (Jamming 'kkkkk' on the end of a password would probably make it a fair bit stronger, while being very quick to enter.)

[note: I originally posted this to Superuser as the blurb for this site says it's for "information security professionals"]

Mostly, two-factor authentication reduces the need for strong passwords in the same way as safety belts in cars reduce the need for efficient brakes. When you drive your car, your probability to be killed during a given journey is the probability of your having an accident, multiplied by the probability of your being killed when an accident occurs. Good brakes reduce the first probability, while the safety belt reduces the second probability. For a given target probability of dying, if you enhance the safety belt (e.g. by fastening it, compared to not fastening it), then you can tolerate less effective braking.

The relationship between the authentication factors is somewhat similar. You use 2FA so that the failure of one factor does not grant access to attackers. So if a password is one factor, then the second factor can save your skin if the password turned out to be weak.

An extreme example is a smart card: most banking cards use a 4-digit PIN code, which, for a password, is pathetically weak. However, the card will lock itself after 3 bad PIN codes, making such poor passwords tolerable. The "second factor" here is physical ownership of the card: attackers cannot try PIN codes without having the card in hand and talking to the card, under the scope of the 3-bad-codes rule.

Ultimately, the choice is up to you, based on a risk analysis. Personally, I fasten my seatbelt and I keep my brakes in good conditions; meaning that when I use 2FA, this is not to allow the use of poor passwords at an unchanged risk level, but to complement good passwords for a much lowered risk level.


What can stop a browser to cache data from ProtonMail conversations? I think this question arises primarily from my insufficient understanding of browser caching. Let's log in to ProtonMail, and read a message. My understanding is that an encrypted 'blob' of data gets downloaded by my browser, and it gets decrypted locally. Can ProtonMail ensure my browser will not cache the text, readable after the decryption? Can I ensure it with some straightforward local method, preferably without plugins?

I did not specify any web browsers.

ProtonMail use the following header in his replies :

Cache-Control: no-store, no-cache, must-revalidate, max-age=0

According to the standards :

  no-store

  The cache should not store anything about the client request or server
  response.

Thus, the data downloaded should not be cached.


Questions regarding CRLs (producedAt and not modified) I have two questions regarding the safety of requesting CRLs.

My first question is: shouldn't CRLs contain a producedAt field just like OCSP responses? This would make sure a hacker doesn't send an old (but not yet expired) CRL to the client, right? Why isn't this done? Is it because CRLs are bigger and signing them each time would cost too much time? Or is it because CRLs are seen as static files (which wouldn't be a really good reason)?
Then my second question. I've seen my browser requested a CRL with an HTTP If-Modified-Since header. The server responded with a 304 - Not Modified code. Wouldn't this also be an easy way for hackers to withhold updates to a CRL (as long as the old one's still valid)?

[...] is it because CRL's are seen as static files [...]?
  Wouldn't this also be an easy way for hackers to withhold updates to a CRL (as long as the old one's still valid)?

Yup. Both limitations are known. And from how I read the RFC, both are deliberate design choices.

From RFC 5280, section 3.3 Revocation: (emphasis mine)

  An advantage of this revocation method is that CRLs may be
  distributed by exactly the same means as certificates themselves,
  namely, via untrusted servers and untrusted communications.

  One limitation of the CRL revocation method, using untrusted
  communications and servers, is that the time granularity of
  revocation is limited to the CRL issue period.  For example, if a
  revocation is reported now, that revocation will not be reliably
  notified to certificate-using systems until all currently issued CRLs
  are scheduled to be updated -- this may be up to one hour, one day,
  or one week depending on the frequency that CRLs are issued.

Further reading

Related question: 2015-12-28, Why do so many browsers show sites with revoked certificates?


Scanning multiple hosts with Nmap's Default Accounts NSE script not producing the expected result I'm utilizing Nmap's default account credential scanner.  I've built a couple of my own fingerprints and I've tested that the fingerprints work when scanning one host at a time.
Example command line usage:

nmap -p80 --script http-default-accounts --script-args http-default-accounts.category=web,http-default-accounts.fingerprintfile=./my-fingerprints.lua 10.10.10.10

When I try to scan more then one host either using -iL (input file) or by defining multiple IPs at the command line, nmap is not identifying that all of the hosts are utilizing default credentials.  Nmap is only reporting that one of the hosts is utilizing default credentials.  And the host nmap identifies as utilizing default credentials varies (it is not always the same host).  I have also tried adding --scan-delay, but that does not change the scan results.

Example command line usage (input file):

nmap -p80 --script http-default-accounts --script-args http-default-accounts.category=web,http-default-accounts.fingerprintfile=./my-fingerprints.lua -iL hosts.txt

Example command line usage (command line):

nmap -p80 --script http-default-accounts --script-args http-default-accounts.category=web,http-default-accounts.fingerprintfile=./my-fingerprints.lua 10.10.10.10 10.10.10.11

Has anyone had experience with getting different results when scanning multiple hosts?  Is there something I need to change when scanning multiple hosts?

Scanning multiple targets at once should not make a difference. You may have a bug in your fingerprint code, but I can't tell without seeing it. If you want better support, open a new issue on the Nmap issue tracker with the following info:

output of nmap --version
output of your scan with the -d option for debugging output
Relevant contents of my-fingerprints.lua
Does the script work with the built-in default accounts fingerprints, or do those show the same irregularities?

I'm willing to bet that just running your scan with -d will show output from the script under each target, and the output will be a useful error message.


Can malicious code fit in 14 bytes? I was reading this The New York Times (NYT) article about the hack of Jeff Bezos's phone. The article states:

  The May 2018 message that contained the innocuous-seeming video file, with a tiny 14-byte chunk of malicious code, came out of the blue

What malicious code could possibly be contained in 14-bytes? That doesn't seem nearly enough space to contain the logic outlined by the NYT article. The article states that shortly after the message was received, the phone began sending large amounts of data.

Yes, it can. It could be just the trigger vulnerability which would load data on specific areas of the movie in memory and execute.

The malicious part can be pretty small, and the payload could be stored elsewhere. After extracting and executing the payload, additional modules can be downloaded, doing way more than the loader.

It's like most malware infections work: a small component, called the "dropper", is executed first and it downloads and executes other modules, until the entire malware is downloaded and executed. Those 14 bytes may very much be a dropper.

In this specific case, those 14 bytes could load parts of the movie on memory, load its address into the register, and jump into it. Examining only the video would not show anything suspicious, as the code would look like video data (or metadata), but the 14 bytes from the loader would stand out.


Who defined the term "fully homomorphic encryption"? Rivest et al. proposed the concept of privacy homomorphisms, but did not distinguish between partial versus fully homomorphic encryption. Gentry seems to take for granted the idea that fully homomorphic encryption must preserve both addition and multiplication.

Clearly, someone in the intervening three decades made the distinction and gave a definition, but who, and in what paper? I'm having trouble finding a source.

Also in 2009, Gentry published Fully Homomorphic Encryption Using Ideal Lattices, defining fully homomorphic encryption like so:

  Definition 2  (Fully Homomorphic Encryption).
  E
  is fully homomorphic if it is homomorphic for all circuits.

Yet, he hints at Rivest et al for the term:

  Rivest et al. [54] asked
  a natural question: What can one do with an encryption
  scheme that is
  fully
  homomorphic: a scheme
  E
  with an effi-
  cient algorithm
  Evaluate
  E
  that, for any valid public key pk,
  any
  circuit
  C
  (not just a circuit consisting of multiplication
  gates), and any ciphertexts
  ψ
  i
  ←
  Encrypt
  E
  (pk
  ,π
  i
  ), outputs
  ψ
  ←
  Evaluate
  E
  (pk
  ,C,ψ
  1
  ,...,ψ
  t
  )
  ,
  a valid encryption of
  C
  (
  π
  1
  ,...,π
  t
  ) under pk?

citing "On Data banks and privacy homomorphisms" which, as you noticed, does not use the term.

Another publication by Boneh et al, "Evaluating 2-DNF Formulas on Ciphertexts" from 2005 does not use the phrase. Neither does "Evaluating Branching Programs on Encrypted Data" by Ishai et Paskin from 2007.

Also, as the term is self-explanatory to a fair degree, as the previous models were merely partially homomorphic, Gentry might use the term as-is without explanation, but instead chooses to clarify:

  We propose a solution to the old open problem of con-
  structing a
  fully homomorphic encryption scheme
  . This no-
  tion, originally called a
  privacy homomorphism
  , was intro-duced by Rivest, Adleman and Dertouzos [54] shortly af-
  ter the invention of RSA by Rivest, Adleman and Shamir
  [55].

Given that the term was not used in papers relevant to the subject before Gentry's publication and that the definition he gives has no source, it is likely that Gentry coined the term.


Identifying EXIF Tampering Is it really impossible to detect changes to EXIF data? Reading from this link, it seems that it is not possible to detect EXIF changes:  https://photo.stackexchange.com/questions/43150/how-to-detect-if-a-photos-metadata-has-been-changed

I thought I should ask the question in this forum as we have more security experts here. I am just not convinced that there is no way to identify that an EXIF information has been tampered with. Do you know a way to identify changes to an EXIF data? In our case the images are taken with mobile devices.

EXIF can't be trusted.

I am just not convinced that there is no way to identify that an EXIF information has been tampered with.

It's hard to prove a negative. But I think your just as our of luck here as you are with trying to prove that an ASCII text file has not been altered: no way of doing that.
You don't own the camera, the camera is dumb and has to rely on someone to operate it.
So if that someone lies to the camera, then the camera has no way of telling. And neither  have you afterwards.
So unless there are some gross inconsistencies somewhere (e.g. EXIF says "no flash fired" when it's obviously flash photography, e.g. EXIF-GPS reporting location as the North Pole when there's palm trees in the picture, etc.) you have no real way of finding out.
I think EXIF was meant to be more of a convenience feature, rather than a trust feature.
So it's pretty much like the date stamp that some analog cameras used to put on photos:
It's nice to have but easy to fake if you set the camera to the wrong date on purpose or if you take a photo with no time stamp enabled and then later add one when you make a copy.


Can I use DCT and LSB method for multiple watermarking? I have an idea of applying DCT on an image and then embed text into the LSB of the coefficient of DCT and transmit the image to B (the receiver). Now, using the same procedure, can B transmit another watermark along with the previous one with this method to another person? Is this a suitable procedure?

Since you usually compress images, which would do something very similar, at least in the case of jpeg compression, but would completely omit or severely reduce LSBs, I guess, no, in practice not.

If you're sending around full-color pictures uncompressed, at least I'd look at the entropy of your LSBs and the PSD, and the latter would probably lead to the suspicion that you're using steganography.


Your connection will not be private - Wi-Fi CA certificate warning message on Android I try to connect to a Wi-Fi network, Eduroam, using my new Android device. It asks me to provide the CA certificate and warns that otherwise my connection would not be private.

  No certificate specified. Your connection will not be private.

On my previous device, I did not have such warning message. The IT administrator says it's OK not to provide the certificate, but I'm not so sure about it. He said that our organization does not have it.

What threats am I exposed to, if I use this network without CA certificate?
Does it cost for an organization to get it?

Without a valid certificate in place, there is effectively no way to verify that the owner of that network is who they say they are.

Secondly, these certificates are used to encrypt the client device with the destination so you could be vulnerable to a MITM attack here.

The organisation does need to pay for a registrant authority to distribute a certificate - in my experience a lot of very small organisaitons who host public WiFi see this as a needless cost.

Your usability of the network won't be affected but I would not connect to an unverified, public WiFi as it's trivial to intercept any data flowing between you and the AP: it's the digital equivilent of not locking a public bathroom door.


What is the purpose of this cookie? I have a site. My site does not have any cookies. It is developed with Drupal 8(CMS) and have few articles. Just for a curiosity I did check whether my website uses cookies or not. I did use Firefox to check.

The Firefox message box showed that, your site is using cookies as shown below. What this cookies is for? Do I have to add information about this cookie in my privacy policy.

The cookie may be a Drupal or PHP session cookie.  Drupal is as PHP application.  PHPSESSID is the default PHP session cookie name.  Drupal overrides this default with a name starting with SESS, followed by a hash.  The hash is a hexadecimal representation of an MD5 hash of the session name or the value of the cookie_domain setting in the settings.php file.  Since you blocked the name, I can't tell for sure whether taht is what you are seeing.  This may help.


How to send cookie to API on seperate domain in safari So basically with my app, I keep users access tokens in memory for the duration page load (e.g. once they refresh the token dissapears). To prevent them from having to sign in again, I have my auth server (https://api.myapp.com) set a httpOnly, secure cookie with a refresh token. This works fine for most users, however, some users are able to set custom domains, this means that the client react app is now on theirapp.com and trying to auth with my api on api.myapp.com . This still works in Chrome (latest), Firefox, and Safari Incognito, but does not work in normal safari (seems to completely ignore the refresh cookie).

What possible solutions do I have to making this work? Basically I want it so that:

user navigates to theirapp.com which makes a request to api.myapp.com
This returns a set-cookie: header with a httpOnly; secure; domain; .myapp.com refresh cookie.

I want it so that this cookie is then sent when the user refreshes and the SPA react app makes a POST request to api.myapp.com/auth/refresh. Is this possible in safari (again this works in all other browsers and even safari incognito)?

I don't want to have to resort to storing a longer lived access token in the users localStorage or a non-httpOnly cookie as that's obviously pretty vulernable to XSS.

When cookie A is set by api.myapp.com while the origin of the request is theirapp.com, then cookie A is treated as a third party cookie. Third party cookies were allowed by browsers until recently. Safari announced all third party cookies will be blocked by default. Both Firefox and Google will follow soon.

The suggestion from the said post which likely applies in your case is to use OAuth 2.0 authorisation. Or you could use OpenID connect (which is based on OAuth 2.0).


Security of Firefox extensions such as Mailvelope I am asking these question because I am not very familiar with JavaScript or the Firefox plugin/extension system. The specific context is the Mailvelope pgp extension but the questions are general and would apply to all extensions.

Can another extension access memory in use or previously used by another extension?
Can another extension act as an MITM keylogger? Can JavaScript from another page/tab that is open?
Can another extension modify the code of another (e.g. on disk)

This question should be moved back to stackoverflow firefox-addon tag.

Yes an extension can get access to another, see this topic: https://stackoverflow.com/questions/22057888/controlling-a-firefox-extension-via-javascript/22099148#22099148

I'm not sure what you mean by "Can javascript from another page/tab that is open?"

Im also not sure what you mean by "Can another extension act as an MITM keylogger?"

Code of Firefox addons does not run in tabs, it runs in the whole browser scope, so it can access tabs, pages, and it can log keys, that come into the browser. You can make it log keys on the OS level with js-ctypes: https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/Standard_OS_Libraries

An extension can modify the code of another, it would first look for the addon by the addons id, then it would unpack the xpi file if it is an xpi, then edit it, then repack the xpi. The changes will not take place until browser restart though. If the addon is not packed as xpi it can just edit the files in the folder, but again the code will not take affect till browser restart. OR if it's restartless until re-enable of the addon.


Prevent cross domain form submission with nonce? I haven't done much in web security before but am now in need to prevent a form from being submitted from anything but my own domain.

I know how to lock this down in an .htaccess file but the referrer isn't very reliable from what I've understood.

I'm now looking into nonces. I've set up a nonce on my form which works (I'm using Wordpress so creating nonce fields are easy).

What I now need to know is does this actually help me preventing cross domain submissions?

In my mind it does as you would need my secret key to generate the nonce string but on the other hand the nonce string is visible in the page source. Does that mean you would need my secret key again to translate the nonce string to validate it?

I'm hoping someone can clear this up for me!

Preventing form submissions from another source is a solved problem, and using a nonce is one of the recommended methods.

For some background, there's a form of attack against web applications known as Cross-Site Request Forgery (XSRF). A cross-site request forgery, in simplest terms, is when someone loads JavaScript on a malicious page that makes posts to another page.  There is more to it than that, and if you're unfamiliar with CSRF, I strongly recommend reading up on it.  (See Jeff Atwood's article in addition to the OWASP article I linked to above.)

The good news is that many web development frameworks already have pre-built mechanisms to prevent XSRF attacks, and they do so by ensuring that posts come from your own domain.  Again, using a nonce is one of those methods.

From the OWASP page on XSRF:

  Related Controls

  Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many
  frameworks (ex, Drupal.org 4.7.4+) either have or are starting to
  include this type of protection "built-in" to every form so the
  programmer does not need to code this protection manually.
  TBD: Add a per-session nonce to URL and all forms

At the bottom of the OWASP page are several references including links to already available mechanisms for addressing this, including the OWASP CSRF Guard, which uses J2EE, .NET, and PHP filters that append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.


How are 1x1 pixel images used in a malicious context? I have been analyzing malware and I am seeing many 1x1 png and gif files. What could these be used for?

Single pixels are used for traffic monitoring. There is at least one legitimate usage known to me: The German organisation VG Wort uses so-called Zählpixel to distribute some money to authors of copyrighted texts on the internet based on visits to their texts.

There are also tracking devices by advertising agencies (including the Referer Header they learn which IP visits what web page) one might consider legitimate.

Also authors of malware want to know their "customers", and single pixel images are a stealth way to learn about them.


What is the difference between key mechanism in wep and wpa I haven't found the resources explaining about exact authentication mechanism about wpa-psk in the internet. finally i found securitytube videos i found one video regarding the wpa-psk concepts.in those videos it is said that wpa-psk uses dynamic keys unlike wep keys these are per-packet basis and per-session basis. i didn't understood what is the difference in them even wep is also providing unique keystreams per packet basis and per session basis and he also mentioned the main vulnerability resides in static wep key what is that mean i didn't understood.

Wired Equivalent Privacy (WEP) Is defined in IEEE 802.11. It uses a 40 or 104 bit key along with a 24 bit Initialization Vector (IV), and the RC4 stream cipher. The purpose of an IV is to ensure that the same key is never used twice but for it to work the IV must never repeat. It is also important how it is combined with the actual key. WEP concatenates the IV with the root key, which is static and does not change after setup, and then sends it to RC4.

So the input to RC4 is IV + KEY or can be thought of as RC4(IV+KEY). The IV being only 24 bits (about 16 million frames) will repeat quickly on busy networks, this allows related-key attacks. This was done because the key can only be used to encrypt one message or you end up with basically a two-time pad. The IV is also sent in the clear along with the ciphertext so that the receiver knows what IV was used because it is needed for decryption.

Further there are different modes of choosing an IV. If you use a counter method you are guaranteed to not repeat an IV for the duration of 16 million frames with WEP. If it is random due to the birthday paradox it happens much quicker. WEP uses a counter mode and the related key attack is made possible because the RC4 PRNG is not designed to be secure for closely related keys like RC4(1+KEY) and RC4(2+KEY).

Today with tools like aircrack-ng it can be broken in seconds simply by listening to traffic. As of 2004 WEP has been officially replaced with Wi-Fi Protected Access II (WPA2) in the IEEE 802.11i standard.

Wi-Fi Protected Access (WPA) was designed to be backwards compatible with
the hardware that WEP algorithms ran on which required the use of WEP’s RC4 to
encrypt traffic. It has the addition of the Temporal Key Integrity Protocol (TKIP) which generates a new 128 bit key for each packet and no longer allows the system to be broken by simply listening. It does this by combining the root key with the IV and then passing it to RC4.

In 2008 an attack on TKIP was released which allows an attacker to send some chosen packets by exploiting WPA’s Message Integrity Check (MIC) which was used to replace WEP’s CRC-32.

Wi-Fi Protected Access II (WPA2) uses the same 8-63 character Pre-Shared Key (PSK) as WEP; however, it avoids the problems of WEP and WPA by replacing both the TKIP and RC4 with AES-Counter Mode CBC-MAC Protocol (AES-CCMP) which restricts AES to 128 bits. AES-CBC mode providing robust protection against patterns being found and CBC-MAC providing excellent message integrity.

There are currently no attacks directly against the encryption protocol of WPA2 and it should always be used over WEP and WPA.

Further reading: The best resource for in depth explination of crypto basics, and intro to crypto I know of is this video series Introduction to Cryptography by Christof Paar.

A good video focused on your question specifically is Attacks on stream ciphers and the one time pad although it does not cover it in nearly as much depth, it is a good higher level overview.

This question probably would have been answered much quicker on the cryptography page.


Can the primary operating system be hacked when using another one on an external drive? I have Kali Linux on an external flash drive that is 128GB. I would like to build a PC with my friend but I don't know which operating system to put on it. I want to be able to play games and I know that the parts I've searched for are pretty fast and I also know that Windows is the best for it. But I am also aware that Windows is the most vulnerable OS compared to Linux and MacOS. I know that MacOS is secure because things like SIP (System Integrity Protection) and other features that I'm unaware of exist. My question is, is it possible to get your other operating system hacked even while Kali Linux is plugged in and the primary OS is "Sleeping"? If so, then I'd rather have security over games with MacOS. But if not, then I'm going to stick with Windows for the entertainment.

My question is, is it possible to get your other operating system hacked even while Kali Linux is plugged in and the primary OS is "Sleeping"?

If you don't have full-disk encryption enabled on your computer, and you get hacked while running another OS from an external drive, then the attacker can mount the main computer's drive and compromise your main OS by modify some of its components to introduce a backdoor. However, this is not OS dependent and can happen even if your main OS is MacOS or Linux. The solution is what multithr3at3d says, either enable full disk encryption so the attacker cannot modify the OS as they like (note however that they may be able to corrupt it), or else run Kali in a virtual machine, which will completely isolate Kali from the host.


What are the most common password salting methods? I learned that the Sun guys used the login name as salt for password hashing. Is this a common approach?
What are the most common salt values?

Using the login name as salt is common but not really recommended: it does only part of the job. The point of a salt is to be as unique as possible among all instances of hashed passwords, so as to thwart any attempt as parallel attacks (attacking several hashed passwords simultaneously, using precomputed tables such as rainbow tables... are parallel attacks). On distinct systems, several users may share the same login name (there are so many Jones and Smiths out there). Also, a given user may change his password while keeping his name; but even an old password is valuable for an attacker (if only because an old password is often a password that the user will reuse the next time he is being instructed to change his password; also, many users will use identical passwords on other systems).

The recommended way to generate a salt is to use a good random number generator (ideally cryptographically strong RNG) and have it produce a bunch of random bytes. If the salt is long enough (16 bytes or more) then this ensure the required uniqueness with overwhelming probability, and without much hassle (no need to lookup in a database of existing salts, for instance).

We can only hope that this recommended way is also, or will soon become, the "most common" way.


Reaver returns different WPS PSK and AP SSID each time it finds correct PIN I am testing a router for vulnerability, and I've noticed an interesting anomaly. It isn't the first time I noticed it, either. When entering the right PIN, Reaver will return with a different PSK and SSID each time. However, none will ever work. Here's an example of output:

~$ reaver ...
[+] Waiting for beacon from xx:xx:xx:xx:40:19
[+] Associated with xx:xx:xx:xx:40:19 (ESSID: xxxxxx7Y)
[+] Trying pin xxxxxx33
[+] WPS PIN: 'xxxxxx33'
[+] WPA PSK: 'bE8vLF121WVW8YJhiJSHU5VdYItwo5Y8Cv8KpWV9'
[+] AP SSID: 'NTGR_kRq'

~$ reaver ...
Reaver v1.4 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <cheffner@tacnetsol.com>

[+] Waiting for beacon from xx:xx:xx:xx:40:19
[+] Associated with xx:xx:xx:xx:40:19 (ESSID: xxxxxx7Y)
[+] Trying pin xxxxxx33
[+] Trying pin xxxxxx33
[+] WPS PIN: 'xxxxxx33'
[+] WPA PSK: 'd45zG5uYHwsdu14ZEsioF9IWWzRrJPL2eWBrGYAkRikYThaC4'
[+] AP SSID: 'NTGR_A5VzduBlQv'
macai@macai:~$

These two attempts were made less than a minute within each other. The BSSID, PIN, and real ESSID have been blanked out. The generated PSKs and generated SSIDs, however, are both real.

So, the question raised is threefold:

Is this behavior a glitch, or is it deliberate technology?
Does this behavior have a name, and if so, what is it?
Are there any known vulnerabilities of this behavior?

This behavior is very similar to WIPSs (Wireless intrusion prevention system).

  A wireless intrusion prevention system (WIPS) is a network device that monitors the radio spectrum for the presence of unauthorized access points (intrusion detection), and can automatically take countermeasures (intrusion prevention).


Rely on name constraints or intermediate CA pinning? Two different services are exposed, call them 'cat service' and 'dog service'. "Cats" and "dogs" authenticate to the services via client certificates. The client certificates have cat and dog identities in the Subject (or SAN) field.

The PKI hierarchy is as follows:

           root CA
        /           \
   cat CA            dog CA
     /                 \
cat client certs     dog client certs

I want to prevent cat service CA operator issuing dog client certificates (and the other way around).

It appears there are two options for this:

use the name constraint certificate extension on the intermediate CAs. In this case, the server is configured to trust the root CA. Now, if a client sends a dog certificate signed by the cat CA (+cat CA as a part of the cert. chain), the server sees a contradiction and rejects even before validating against the root CA.
Have the 'cat service' listener pin the intermediate 'cat CA' and dog service pin the 'dog CA'. In this case, the server doesn't trust the root CA.
As pointed out in the comments by garethTheRed, there's also the third option: >> Use Certificate Policies to constrain each CA path to an OID. Have the Root CA issue each Sub CA cert with it's own OID and have the server check this during path verification of the client certificate.

What are the upsides/downside/comparison of the three approaches?

Note: this is question different than Will two intermediate CAs signed by the same root CA trust each other's signed client certs? as it asks if there's any particular down/upsides for any of two listed approaches.

I prefer option #2, as it's simple to understand, simple to implement across different stacks.

Option #1, you need to define mutually exclusive Name Constraints for the two services, possibly makes certificate issuance more difficult (additional checks need to be done before issuing cat/dog client certs), ensure the certificate chain validation library you are using properly respects Name Constraints extensions, etc.

I know you mentioned that the validation will be done on the service, which you have more control over, but if the validation has to be done by browsers, Safari/IE and possibly other browsers don't implement it properly.


Should I use C for post Exploitation Once I have gained shell access to a box on a remote network, is it most efficient if I use the C programming language to create some tools to use for learning about the network and further exploiting it, or is it possible to get nmap and other ready made tools inside of the network?

The answer to this very much depends on the circumstances.

If you're on a time-limited test or exam situation, then I'd recommend against trying to write your own C-based tools as part of post-exploitation.  It would be very time consuming and likely not the best way to approach it, as there are a huge number of post-exploitation tools that have had 1000's of hours of development time and you don't want to replicate that.
If you're doing this purely for your own research/education and have no time constraints then, sure, something like C or Go would be a good language to write things in as they're cross platform and have minimal dependencies once compiled.


Can passwords be brute-forced through RDP? We had a small discussion about a security-related article at work today, and I was a bit surprised about one thing - they claim that some attackers managed to brute-force guess the password of someone and log on through RDP. The article was written with emphasis on the idea that you shouldn't leave RDP publicly available because of this.

I'm confused that it would work. Even on the most basic Windows installations there is password throttling. After 5 failed attempts there is a forced 30-second pause (or something like that). Is RDP exempt from this? Can you really try hundreds or thousands of passwords per second through RDP? I couldn't find this information on google.

Let's assume that there is no domain lock-out policy (otherwise this obviously won't work) but also that nobody has explicitly disabled any throttling that was enabled by default.

The lockout-on-failed-logon thing usually doesn't apply to local admin/etc. You can enable a setting that locks it out, but the default setting is that the lockout setting don't apply to admin accounts.

I'm not sure about the throttling you mention though, but it is a very common thing to see thousands of brute-force login attempts per hour on windows servers with RDP exposed to the public internet. These show up in the security event log as audit failures with event id 4625. Very often they cycle through common user names, so maybe that's how they bypass throttling ( if throttling applies to RDP).

Related: I put together a windows service a few years that firewall blocks the source IP if too many of those audit fails appear in the event log within a given time span with the same source IP. Here's a link to a short writeup on that: http://huagati.blogspot.com/2014/02/blocking-rdp-brute-force-logon-attacks.html


What's the use of DKIM/SPF if it only validates the Enveloppe From? DKIM and SPF are mentioned as powerful mitigations for having your domain abused for phishing.  But when I send a mail like this:

Return-Path: <me@mydomain.example.com>
From: Citibank security team <security@citi.com>
Reply-To: Noreply <noreply@citi.com>
Subject: Unauthorized attempt on your account

With Enveloppe From <me@mydomain.example.com>
With a valid DKIM signature for mydomain.example.com
Sent from a host that is authorized to send according to the SPF policy for mydomain.example.com

It is my understanding that the mail will be shown as if it actually was sent from Citibank.  The mailserver logs may show something about an unaligned DKIM-signature, and a DMARC-report may be sent to Citibank eventually, but it doesn't at all prevent a scam-mail from being delivered.

Why does the specification check the From: address so loosely, while that is the only identifier a user would see directly in their mail client?

.. and a DMARC-report may be sent to Citibank eventually, but it doesn't at all prevent a scam-mail from being delivered.

citi.com has a DMARC record with an explicit reject policy:

$ dig txt _dmarc.citi.com
...
_dmarc.citi.com. ...  TXT     "v=DMARC1; p=reject; ...."

This means if the receiving mail server implements DMARC it will reject the mail since no aligned SPF or DKIM will be found. If no such checks are done at the recipients side the mail will not be rejected.


Is a new protocol needed for credit card transactions? It seems like many places spend a ton of time and money securing their site for credit card transactions. However, there are still millions of credit card numbers being stolen. Fraud is big business, and easy to do online. In Europe, credit cards have been almost entirely replaced with chip and pin systems that protect against stealing of credit cards at the terminal and the loss of physical cards. This is starting to make its way to the US and Canada as well. However, the easiest place to steal credit cards seems to have been the internet for some time now.

So I've been thinking, would it be possible to create a secure protocol for placing credit card transactions online so that sensitive data doesn't need to be sent to the web server? Is it even feasible to migrate to such a system?

What I am thinking is along these lines:

Merchant contacts their processing service provider and obtains transaction code.
Merchant responds with transaction code, amount/summary, and processor information via HTTP headers, with content to fall back on if the client doesn't support it
Client sends a request to their issuing bank with authentication information, passing along the same information sent by the server.
Client's bank checks funds and contacts the merchant's processing service provider, agree on the information, and gets an approval code if the transaction is good
Bank responds to client with pass/fail details
If the transaction failed, the client can try another account or responds to the server with failure
On success, the client responds to the server with the approval code
Merchant confirms the approval code with their processing service provider and captures funds when ready

In this scheme, the client and merchant never exchange sensitive information. So you either have to attack the banks, the client's machine, or replace the credentials on the server so everything goes to your personal account (which is risky).

I guess this isn't so much of a question, as it is looking for thoughts on how to improve things.

You've asked a bunch of questions.

Do we need a new protocol for credit card transactions? "Need" is not the right word.  Credit card security is all about risk management: balancing the losses due to security problems, against the costs of a better security mechanism.  In the credit card space, there are huge costs to changing the protocol, given the huge deployed base.  In addition, anything that makes it even a little bit harder or less convenient for credit card holders to make a purchase has major implications for the credit card company's bottom line, so credit card companies may be glad to accept some rate of fraud if in return making a purchase is really easy and convenient.

So, while the current protocol for credit card transactions (send your credit card number in cleartext to the server) has almost no security from a technical perspective, it may well be good enough, when you consider the costs of the alternatives.  In any case, this is not a yes/no question: it's a matter of balancing the risks and the rewards.

Is it chip-and-pin more secure?  Chip-and-pin eliminates a number of security problems in prior systems.  However, it has problems of its own.  First, there have been some security problems found, in turn, in chip-and-pin.

Second, adoption of chip-and-pin in the UK was initially tied to a change in the liability model in a way that has harmed consumers.  In the event of a disputed charge on your card, what happens?  The answer used to be: by default, the bank would refund you (if you claim you didn't make the purchase, the presumption lies with you: the bank had the burden of proof if they wanted to argue that you are lying).  With the adoption of chip-and-pin, many banks changed the model: by default, you have to pay (if you claim you didn't make the purchase, the burden of proof is on you to prove it).  I'm not familiar with the latest status, so I don't know if this is still true, but I think it illustrates a general risk to consumers.

In particular, when new protocols are adopted, there is an opportunity for mischief: an opportunity for banks to claim that the new system is so secure and so impenetrable that, in the event of a dispute, the bank's computer systems should be presumed correct.

Could we design a more secure protocol for web-based credit card transactions? Yes, certainly.  The primary challenges are not technical in nature -- rather, they relate to the ecosystem.  There are many players here, with diverse interests, and any change would need to be adopted by most or all of the players -- which means, a new protocol will only be successful if it is in all of their interest.  Designing a protocol that reflects these ecosystem constraints, and is simultaneously more secure, is the real challenge.

Before diving too deep into design of a new protocol, I suggest you start by studying history.  For instance, you might look at SET, a protocol which encrypted the customer's credit card number on the client side, so that the merchant never got to see the credit card number (only an encrypted version).  Sounds like a good idea, right?  Yet SET went nowhere, for a number of reasons related to legacy issues and ecosystem considerations.  So, study  your history, and learn from it.

Resources for further reading.  I suggest the following papers and resources to learn more:

Optimised to fail: Card readers for online banking, Saar Drimer, Steven J. Murdoch, and Ross Anderson.  Financial Cryptography 2009.  See also the associated short blog post.
Wikipedia on EMV Vulnerabilities.


John The Ripper Error: No password hashes loaded when cracking a zip file in kali linux I was practicing bruteforce attacks using John The Ripper. I want to crack a zip file. I obtained the hash and stored it in a zip file but when I attempt to crack the zip file it is giving me an error saying No password hashes loaded

This is the hash inside my passwordFile
Traffic.zip:$pkzip2$2*2*1*0*8*24*9fd8*23cd*ef2dcc3d08252e794fb90a80cf425f5ed83f04235bb66e8b75a8050817505569c3b30ae3*2*0*f5*1804*456ba01d*42*4b*8*f5*456b*23dc*ec2337b7340f21407a143d82f96fa0369aa6691a48126cbe945aab87e6e233f892999da88975e6a1c50c5fc1c6f58ac9075a5ebe45bb92e5fdf160845a6bfa9bfd0cabd515e83dae1a550dc71992459813bf8c96d31db4a4f5cf989d89ce04d75b71ed81d95315135fa6d0b73cef3b48ff0fefb67545f3fa319f9e2f7b5d325d4151c290c89f01a2a9d5398b23851e493971027d70dfdeeb94e307adccb7ebfbc05d0cc304f121ade8c349f6dd42977cdd8992729a4ad6395f18d9de4be424624510366c7d859302277f2a180159f920ce8310261883d85a2964ff77a72e50c12ff64c3ead48177ff470dc14bb176d77ecaeaeadbe*$/pkzip2$::Traffic.zip:Traffic/.DS_Store, Traffic/traffic.doc:Traffic.zip

You need to update to the latest John the Ripper.  I experienced the same error as you with john 1.8.0 but when I downloaded the latest bleeding edge release from Github (1.9.0-jumbo-1+bleeding-d29f456a4 2021-01-20) I was able to crack the same file:
$ ./john passwordFile.txt
Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
Warning: OpenMP is disabled; a non-OpenMP build may be faster
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:./password.lst
techno           (Traffic.zip)
1g 0:00:00:00 DONE 2/3 (2021-01-23 16:44) 20.00g/s 1298Kp/s 1298Kc/s 1298KC/s frodo..barbara
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
$

This is not uncommon.  "Run the latest bleeding edge" is a standard prescription for fixing issues with John the Ripper.  I followed the instructions in john/doc/INSTALL-UBUNTU which explicitly tell how to grab the bleeding distribution; they're probably a good starting point for Kali (although the names of some prerequisite packages may differ).


Would biometrics be more secure if it was a sequence and not a single biometric scan? I was looking at this question How is Fingerprint Authentication Secure?

Where it talks about biometric scans, and the answer by @Lie Ryan mentions this isn't a secure authentication method, but more for identity and such for those who are witnessing you actually using your biometrics to identify.

My question is, what if Biometrics were a series of scans, and not just one, kind of like a password?  Instead of entering 1 letter for a password, we use a sequence.  Would this be secure if we did this for authentication via biometrics?

For instance, what if our biometric password was pinky(L), ring(R), Middle(R), pointer(R), pointer(L), pinky(Toe Left), etc.

Would this actually provide to be secure?  How much harder would it be to crack this type of biometric scan?

NOTE:  There was mention in either the above question, or another question I read, that spoke about the merchant, or another party scanning and keeping your prints in their system....  I understand that is not good, but wouldn't the same be said if you entered a pin, or a password?  wouldn't it be possible to steal that data as well?  The issue is, they would need your device in order to access payments... right?  Or would they be able to exploit something?

So again, my question is, how safe would a sequence of biometric scans be instead of a single scan?  How good of an Authentication scheme would it be overall, compared to passwords?

Thanks all, happy new year.

EDIT:  The answers so far both mention about the data not being able to be changed.  My point is that with a sequence of biometric data you are giving a much harder time.  If we consider each Biometric as an Alphanumeric, why couldn't a sequence work?  If 123F is figured out to be your password, F123 is completely different, even though the metrics are the same (not saying F123 is secure, but you know what I mean).

Also, as mentioned above, if your metrics are stolen, just like a pin or password, you just change the sequence.  if pinky pinky ring ring pointer pinky gets cracked we should be able to do ring pinky rping pinky, pinky pointer pointer ring, and it should be fine.

As pointed out below by @Julian, the scans these days can be tricky, which could affect the entire process, but it's possible that partials, or other data could help.  Also, like entering a wrong password a few times, these things do happen, so with biometrics it is the same.

The real issue with biometrics is that you cannot change them. Well, not without surgery anyway!

That is why you should never replace secure authentication methods with biometrics. As you say, all a biometric does is indicate the you are present and that really only works if there is someone watching - even then there might be ways around even that (a-la Mission Impossible style).

When used on laptops and the like, biometrics are a convenience not so much of a security feature. They are better than using poorly chosen passwords/pins but not generally as good as a good passcode or other multi-factor authentication. (thats a bit of a generalisation, the reality is rather more complex perhaps but hopefully you get my meaning).

So while your idea has some merit, you are still left with the issue that the actual metrics cannot be changed. Yes, you can change the order of the metrics but not the underlying metrics themselves.

You also have the problem of false readings to contend with. The more readings you take, the more false positive/negative entries you will get.

I should, of course, note that not all biometrics are equal. It is harder to obtain iris data than fingerprints for example. But not impossible and once compromised ... game over.

  Would this actually provide to be secure?

You write that as though you meant "Secure" - in reality we are talking about differing risks. Your idea is lower risk than a single fingerprint scan but at higher risk of false readings.

  How much harder would it be to crack this type of biometric scan?

Somewhat. More data and you need the order not just the metrics.

  keeping your prints in their system ... I understand that is not good, but wouldn't the same be said if you entered a pin, or a password? wouldn't it be possible to steal that data as well? The issue is, they would need your device in order to access payments... right? Or would they be able to exploit something?

Again, the issue here is that, once compromised, you can't change them. When someone stores your biometric data, if it is compromised, you might never know but even if you did, there is nothing you can do about it.

  How good of an Authentication scheme would it be overall, compared to passwords?

Not good. Because it is hard for users to do. Even a single fingerprint scan can be tricky to get right and often needs more than a single attempt. It isn't just about the security it's about how people have to interact with the system.


Threats due to a stolen password db file (e.g. keepass) If someonelse could get your password db file (e.g. .kdbx file for keepass), maybe due to a hacking attack, how threaten is your security in fact?
Of course this is a problem and you should change all your passwords, but how "dangerous" is this really? Is there any value without having the master password?

If you've picked a strong master password, they've effectively got an encrypted blob of data which they can try brute force your password from, but may never succeed (Assuming that the password DB format is free from errors).

However, unlike with a website password or other online service (Chat/ssh/etc), there are no limits on how many times they can try different passwords, or on what speed the password comparison runs at - they can send copies of the file to thousands of machines and try to brute force starting from different places to minimise the time to find the password. With a website, the web server is the limiting factor - even with thousands of source machines, it will only do comparisons at a rate it can support, or it'll fall over.

For a really good password, this doesn't matter - the number of potential passwords is far too high to try them all in a useful time (assuming for the purpose of argument that whatever data you have is probably not very useful to anyone in a few thousand/million years). Picking and remembering a really good password is harder though, so it's possible that it is actually a quote from a book or common phrase, which might be tried sooner than pure brute force would suggest.

If, on the other hand, you have a weak master password, they've got an easy to decrypt list of passwords and sites, and it probably won't take them long to get access.

Additional - based on @André's comment:

As André says, if the hack occurred on a device where the database is used, as opposed to one where it is just stored (main PC vs. backup server), there is a chance of a keylogger being used to find the master password. As a result, it would be recommended not to open any password databases on machines which are suspect until they have been completely rebuilt from a clean state. Most password managers try to prevent passwords being read from memory, although this is not 100% perfect, but again, this can be avoided by not opening the database on suspect devices (or ones which you don't have control over).


TLS: is authentication and forward secrecy possible without PKI? Im making a project that consist of a client/server system that requires TLS without PKI..

Design Requirements:

The client MUST authenticate that it's communicating with 'THE' server

The server MUST authendicate that it's communicating with 'A' client

The communication MUST be confidential

The confidentiality of a session MUST NOT relay on the confidentiality of a previouse session (aka forward secrecy)

And the integrity of the transmited data MUST be verified

Im thinking of using DHE for PFS, SRP(or alternativly PSK) for authendication with AES/CBC cipher and SHA for integrity.

My questions are..

Is this protocol stack possible?

Is AES 256 CBC reliable for confidentiality?

Will all the requirements be met by this design?

And if the SRP/PSK password of a client is obtained by a third party will he be able to evasdrop on other clients?

ps: i'm aming for the highest security option possible

Thanks in advance for any feedback and sorry for any confussion caused, i just starter learning about crypto..

There is no need to use a PKI with TLS. The only thing a PKI does is to make the authentication part of TLS scale. When using self-signed certificates, PSK or similar all trust information (like certificates or pre-shared keys) need to be distributed to every communication peer in a secure way. These information need also be be kept up-to-date, i.e. when new communication partners get added, secrets gets compromised or similar. Using a PKI instead this process is reduced to sharing the trust anchors (root certificates) which rarely need to be updated and to regularly check if a certificate got revoked. Using PKI thus gives you an easy creation and sharing of new trust information and also revocation and replacement of compromised trust information.

If you already have full control over all communication peers and also have a secure way to distribute new trust information and also revoke these if compromised then you don't need to use a PKI. If you don't have this infrastructure yet then using a PKI might be the easier and probably more secure than implementing everything yourself.

As for the specific protocol stack you mention: While PSK/SRP authentication can be used in theory with DHE/ECDHE as key exchange as dave_thomson@ correctly pointed out in a comment below, these ciphers seem to be rarely implemented. But with certificate based authentication DHE/ECDHE is commonly used and self-signed certificate don't need a PKI either. Also, while AES with SHA-256 is secure ciphers using AEAD like the GCM ciphers are preferred today. And ECDHE is preferred compared to DHE.

  And if the SRP/PSK password of a client is obtained by a third party will he be able to eavesdrop on other clients?

If the essential secret (pre-shared key, password, private key) is obtained an attacker will not be able to decrypt sniffed data if DHE/ECDHE is used for key exchange. I'm not sure how PSK/SRP key exchange behave in this regard. But in all cases the attacker can impersonate the peer and get access to the decrypted traffic inside a man in the middle attack. Since the attacker has the secret this can be done without the other party realizing the problem, i.e. the authentication still succeeds. This is one of the reasons revocation and replacement of such secrets needs to be implemented - which is already included in the PKI.


Cryptographically prove open sourced source code of server I want to prove that the source code I am using is the same as the open-sourced version, which is publicly available. My idea was to publish a hash of the open-sourced version and compare it to the hash of the deployed server at boot. However, because the open-sourced hash is available pre-deployment, it is possible for a bad actor to hard code the hash into the server and avoid the hash function.
Is there a way I can prevent this from happening? I found that Heroku is using a similar approach where they are fetching the commit hash. Is this tamperproof? And if so, how is this different from my approach?

This is essentially an impossible task.
If you have read Ken Thompson's "Reflections on Trusting Trust", then you already know everything I am about to say. If not, please keep reading:
Imagine I publish an open-source project, that is written in some language, and simply takes input and returns the input unchanged - like a very simple version of echo. You download my source code, read through it all (it's just a few lines long anyways) and then you compile it. You can be sure that your program does exactly what you think it does, right?
Wrong.
How do you know that your compiler didn't add any extra instructions, such as checking whether or not the input's sha-256 hash is e257f6eccac764b6cea785a0272e34d3dbc56419eac2ad436b9fb4bddcd10494 and if it is, do something unexpected.
You might say that that is unlikely, but you cannot ever be fully certain of it. But perhaps you want to be fully certain of it, right? After all, you want to cryptographically prove that the software you are running does exactly what the source code says it should do. So you inspect the binary with a reverse-engineering tool, like Ghidra or IDA Pro. But...how can you be sure these tools do what you think they do? Sure, on the surface they might seem as if they show you the binary as it is, but how can you be sure that they don't hide the maliciously inserted code from you?
You could completely forego existing compilers and write your own in bytecode, byte by byte, instruction for instruction, but how would you do that? You need some program that writes those bytes to disk. How do you know that those are not infected and write some extra bytes?
And even if you completely forego programs and just use a magnetized needle and a steady hand, how can you be sure that your CPU actually runs the instructions you want it to run and doesn't run some extra instructions? After all, CPUs run microcode these days, which is difficult to inspect.
In summary...
... it's extremely hard to prove that a computer does what we think it does. Can you show some hash of some source code or deployment state to show something to your customers? Of course you can. But that really doesn't mean anything.


Decrypt RSA ciphered TLS 1.2 traffic using client RSA private key (not server) I am using stunnel as a MITM to decrypt TLS traffic in between an app and its web server.

The traffic between the app and the MITM server cannot be decrypted simply with RSA cipher as the app is not accepting such cipher anymore.

The traffic between the MITM client and the webserver could be decrypted with the RSA keys method as the webserver allows the use of RSA ciphers and the MITM client is configured to use RSA ciphers only.

Thus, I captured traffic between the MITM client and the webserver. I can confirm the cipher used is from the RSA family (TLS_RSA_WITH_AES_256_GCM_SHA384).

Question:

I used to decrypt TLS 1.2 RSA traffic by using the server pem file. In this setup, I only have client RSA keys. Would it still be possible to decrypt the traffic knowing only the client's RSA keys? And where could I find them?

My stunnel client conf is as follow

[client]
client = yes
accept = 127.0.0.1:31337
connect = webserver.com:8888
cert = C:/whatever/stunnel/config/stunnel.pem
ciphers = RSA

I tried to include the stunnel pem file in Wireshark but without success. Am I doing something wrong here?

I'm assuming that [client] is the configuration for the connection between stunnel and the server. In the case cert specifies the optional client certificate which is used to authenticate a TLS client against the server. This certificate is not involved in the key exchange at all and thus cannot be used to decrypt the traffic. Only the server certificate is involved in the RSA key exchange and thus for decrypting the private key of the server certificate needs to be known.


Ettercap (dns_spoof) I need to prove to my boss that he has a vulnerability to a mitm vector on his network. To do so I have been trying to configure ettercap with dns_spoof as an example.

When I run the attack on myself I am redirected reliably, however, I cant redirect any other computers on my network (I own them all so its all good).

Does anyone know what might be causing this? I have flushed the dscache on them and still nothing.

I have found a solution to this problem.

I enabled packet forwarding on my kernel and the attack works great now.

 sudo sysctl -w net.inet.ip.forwarding=1


Resources/tools for controlling access to corporate email on smartphones If one of our employees has access to corporate email on a smartphone I want to make sure that if they lose the phone then whoever finds it can't get at any corporate email on that phone.

For iOS devices there is the iPhone Configuration Utility which looks like it can do what I want. Is there other similar software available on the other smartphone platforms?

I've work with a number of organisations looking to address the same issue. Due to regulatory issues or just a low risk appetite, each organisation has gone down the enterprise solution level, so that is the point of view I will add advice from.

Each time one company has been the front runner for the provision of the service and this is a US based company called - Good Technology with their "Good for Enterprise" solutions.

They offer "Enterprise-Grade Security and Management for iPhone, iPad and iPod Touch"

Positives:

Safe access to corporate email, contacts, calendar, Intranets, and Web applications on iOS devices.
On-device encryption. Which protects the data from the device.
Ability to apply corporate policy templates.

And in terms of your question, offers the ability to perform a remote wipe of the data. With Good, the enterprise data is the only data wiped. Which if you are in an organisation that supports personal device use is a great option.

On the downside, all data passes through the US based network operations centre. So you may need to understand if there is any issues for you as an organisation. Also as this is an enterprise solution, so cost may also be a barrier.

Hope this helps.


Integrate OData pentesting tool to ZAP add-on We are currently working on a ZAP (Zed Attack Proxy) add-on designed to facilitate the pentesting of our new framework.
Our solution is using OData so we were wondering if their was existing tools that we could have integrate in the add-on. I heard about OyeData, but it doesn't look like you can easily call it from another application. SQLmap would have been easy to call from our add-on, for instance, but it does not support OData testing.

Have you ever encountered an testing tool that could fit our requirements ? (Perform SQL injection through OData, and be "simple" to call/integrate from an external application ?)

ZAP already supports OData in the spider and active scanner, which means that all existing active scan rules (such as SQLi ones) will work with OData:

https://github.com/zaproxy/zap-core-help/wiki/HelpStartConceptsSpider#odata-atom-format
https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsOptionsAscaninput#build-in-input-vector-handlers

Having said that I'm sure theres more that can be done, so be very interested to hear of what else your add-on will be able to do :)


Australia's Legal Do's and Don'ts of Hacking Just wondering what methods used in Pen-testing (Denial of service, dropping a shell, phishing, etc.) would land you in legal trouble in Australia?

Do anything you have written, legally binding permission to do. Don’t do anything else.

Those dos and donts apply pretty much everywhere and should be followed. There may be some gray areas such as stumbling onto a bug or glitch on a web facing portal, and you can report those, but don’t start anything intentionally just to have fun. This is where you can get in a lot of trouble really quick.


How hackers implemented DDoS attack with 602 Gbps? Everybody's heard about DDoS attack with 602Gbps Bandwidth that crashed BBC site, But is really Botnets and hacked servers can implements an attack in this scale ?

It may be possible, but attackers usually relies on an amplification attack to ensure the traffic coming from the botnet is much more effective.

Amplification attacks are easily implemented on udp protocols where the source IP can be trivially spoofed as there is no three way handshake to establish a connection. If a udp protocol allows you to receive a large packet in response to a small packet you have an amplification. Past examples of these are DNS and NTP queries. The attacker then spoofs the vicitm's IP and sends out the requests, the much larger responses are then sent to the victim's IP causing the DDoS through bandwidth saturation.


Attack that stops internet access for several minutes I have a question that might sound a bit weird: A friend of mine (Person A) is being attacked by a former friend (Person B) and now person A asked me for help. Person A and Person B know each other from the internet and Person A used to trust Person B.

Generally speaking, Person A experiences network issues in his WiFi network.

Person B has access to Person A's iCloud account and other accounts. Also, Person B may have changed settings (VPN, certificates, ...) or installed apps on Person A's iPhone because Person B told Person A that he knows how to cheat in a smartphone game. Person A doesn't remember anymore what Person B told him to do. Person B never had physical access to the iPhone nor the router.

Apparently, Person B can launch an attack that stops the internet on Person A's iPhone for several minutes. This only concerns incoming traffic because during these attacks Person A can be heard by me on the call, but Person A can't hear me for the time of the attack.

This doesn't only affect the iPhone, but also other devices in the same WiFi network. That's why I was thinking that Person A might have access to the router, but he could have never had physical access.

Person A is rather inexperienced with technology and, as far as I know, Person B is an experienced senior software developer who is interested in pentesting.

Does anyone have any idea what Person B might have done to Person A's iPhone/router and how he is remotely able to stop his internet?

I appreciate any help!

This could be as simple as person B previously enabled remote WAN management of the router.  Person B knows the router's external IP address and password.  He can login and reboot it remotely, resulting in "several minute" outage.

Another possibility is person B is aware of a DOS attack which affects this router triggering a reboot.

Fix: update firmware, reset to factory defaults, change password.  Recommended on both router and iPhone.

In general, if a computer (or router, or iPhone) is compromised, wipe it and start over unless you are an expert.  Back it up and erase it as if you were selling it. Reinstall the OS (phone could be jailbroken). Change all passwords, including the router, WiFi, and cloud passwords. On the router update the firmware and restore to factory defaults.

A third possibility is this is a bandwidth DDOS attack, but there's not much you can do about that.  If your Internet pipe is full, your Internet pipe is full.  In addition, WiFi can always be jammed by an (illegal) jammer radio within radio range.


Which authentication at the end of the Secure Remote Password protocol? For the the client and server to prove to each other that they have the same premaster shared key, the original author suggests this:

M = H(A | B | K) -->
                 <-- H(A | M | K)

The RFC 2945 recommends this:

M = H(H(N) XOR H(g) | H(U) | s | A | B | K) -->
                                            <-- H(A | M | K)

How many of these concatenations actually increase security?  Also, how much freedom do I have to alter it without reducing security?  I would imagine that it would be just as secure for to one replace the XOR with concatenation, for example.

A - public, random every time, determined by the client
B - public, random every time, determined by the server
U - private in my implementation, username (salted hash and salt are public)
s - public, associated with the user account password, determined by server
N and g - public, constants, determined by programmer
K - private, random every time, secret key between the server and client

Which definition should I use?  The difference between the two is that more public values determined by the server are concatenated into the second hash.  Is this actually worthwhile, since any attacker knows H(N) XOR H(g) | H(U) | s | A | B just as well as A | B?

EDIT:  Uppercase U is actually the username.  I was reading it as lowercase.  Obviously not big on C#'s case-sensitivity.

At the end of SRP, client and server are implicitly authenticated to each other. "Implicit" means: "I do not know if I talked with someone who really knows the shared secret, but I know that he knows the symmetric key I just got from the protocol only if he knows the shared secret". If you want to make sure of that, challenge the peer: have it use the symmetric key.

Now it is not as easy as it seems. In particular, an attacker could try to make a machine talk to itself. To ensure security, you shall derive several symmetric keys from the one which was produced by SRP: one key to encrypt from client to server, another distinct key from server to client. And a pair of keys for integrity checks, too. This is hard to get right, so it is highly suggested to use a protocol where all those details were painfully tuned through years of attacks and counterattacks -- namely, TLS. Did I talk about RFC 5054 ? TLS includes the Finished messages which are, basically, the challenges I am talking about. When a machine has received a Finished message from the peer, and it could be processed (proper MAC, proper value when decrypted), then the peer is duly, explicitly authenticated.


Multi-factor auth into centralized log server I've been searching for an answer to this question. According to PCI DSS Requirement 10.5.3, it asks for sending logs to a centralized secure internal log server.

Would we need to enable multi-factor auth into the internal log server if it is secured and segregated? Specially if we have firewalls only allowing CDE pushes into the log server but no backward traffic (in other direction) is allowed from the log server into CDE via FW rules.

Basically locking it down so you can't get into any part of CDE from that Log server. Thanks for any help or guidance on this.

When looking at the potential importance of those log servers to the security of the organization, I wouldn't even hesitate to implement multi-factor authentication on them. PCI DSS primarily requires the audit trail for reporting the aftermath of a breach, and that means money.  If breached, you can use that data to say "the attacker hit payment system X from January 3-10, but never entered the database", which can limit your liability to the seven days of data that flowed through system X.  Without trustworthy logging, the investigators could claim "it's unsure, so we're finding all data from October through January is at risk."  That could be the difference between thousands of accounts vs millions; which could be the difference between sending a few notification letters vs ending up on the nightly news.  Both are bad, but trust me, one is much worse.

Those are just the worst-case costs.  Architecturally, that log data is the ideal place to plug in analytic engines to help you detect anomalous activity early, and can help you identify an intrusion long before the attacker makes off with your data. So while many intruders are of the snatch-and-grab type, some of the more serious APT threat agents try to cover their tracks, and look for ways to disable logging and analytics so they can remain hidden for a long time.  Don't make it easy for them.

And if you have a 2FA system in place already for accessing the rest of your in-scope machines, it shouldn't be too much harder to extend that capability to your log server as well.

However, the official answer is going to be "whatever your QSA decides is secure."  Multi-factor authentication will certainly make it that much easier for her to sign-off on that requirement.  But really, you should want those servers to be secure, even more so than the auditor.


Do app lockers improve smartphone security? I recently installed Norton App Lock on my smartphone. It asks for a password pattern every time one tries to open an app. So, theoretically, it protects you in case someone is able to bypass your OS password pattern.

But it also hurts usability because I have to input these patterns frequently.

Do those kinds of app really improve security in anyway?

TL;DR

They can in theory improve security a bit in general, but not if you are trying to protect from anyone you would actually call an attacker. In practice they can provide a bit more privacy in some situations, but then using your phone might become a hassle and in the end it might not be worth it.

Long version

If you use different passwords for each app, or at least different passwords for apps that are supposed to be accessed in different situations, then yes, I believe it can add some security, but it might not be worth the hassle.

I am thinking of this example: suppose you have three different passwords, one to unlock your device, one to unlock your email application that you only use for work, and one to unlock your picture gallery. Now, it's probably very easy to steal one of your passwords/pins/gestures by shoulder surfing, especially by people who are frequently around you like friends, partners, etc. When you are hanging out with friends the password you type most often is probably the one to unlock your device, then you might also type the one to unlock your picture gallery pretty often, and you probably won't type the password to access your work email at all. So a friend might grab your phone, unlock it, browse the gallery, but not read your work email. If you have a phone that requires your fingerprint to unlock the screen, then the above scenario only applies if somebody grabs your phone while it's unlocked.

So this was just to show that it can indeed add some security, and as usual it depends on the possible scenarios and possible "attackers". On the other hand, you will have to use several different passwords, enter them too often, and there are probably some applications containing potentially sensitive data that you need to access very frequently in a lot of different situations (whatsapp?), so protection becomes less effective even in the scenario I described above. I'm also not sure whether it can slow down a decent attacker (not your average friend, unless your friends are decent attackers), preventing them to access some of your application data at least for a while, at least until you discover your device has been stolen and maybe remotely wipe all your data, but the link provided in a comment to your question seems to imply that a decent attacker won't really be hampered by this application for long.


Port Scanning - States definition I am currently reading the "NMAP Network Scanning" book by Gordon Fyodor Lyon. On page 77 there is a description on how NMAP categorizes the ports based on host's responses (or not).

What would help me to better understand them is a clear association to the flags returned by the host. Therefore I created the list below and would appreciate to have it doubled checked by you guys:

 State             Response

 Open              SYN/ACK (SYN probe)
 Closed            RST (SYN probe)
 Filtered          No Answer or ICMP Type 3 and 13 (SYN probe)
 Unfiltered        No Answer or ICMP Type 3 and 13 (ACK probe)
 Open/Filtered     No Answer (UDP, FIN, NULL, XMAS probes)
 Closed/Filtered   No Answer or RST (Idle Scan)

Open:

The attacker sends a SYN probe to the port he wants to test
The port sends back a packet with SYN and ACK flags

Closed:

The attacker sends a SYN probe to the port he wants to test
The port sends back RST/ACK packet directly

Filtered:

The attacker sends a SYN probe to the port he wants to test
Two scenarios:

The port responds back with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited)
More frustrating scenario for the attacker: the SYN probe is dropped (no answer at all)

Unfiltered:

The attacker sends a ACK probe to the port he wants to test
The port responds with RST packet

Open/Filtered:

The attacker sends a UDP, IP, FIN, NULL or Xmas probes to the port he wants to test
No answer is received

Closed/Filtered:

The attacker performs an idle scan  (-sI)
The zombie machine receives RST packet,  or nothing at all from the target machine (this means the attacker will receive IPID=1 from the zombie)