Are cell towers basically routers? If so, could one be hacked to spread malware to all connected devices? Just listened to a bit of the Darknet Diaries podcast episode on NotPetya. It’s insane just the damage it was able to cause even if it was only able to infect one machine initially. Which got me wondering: how could a similar large-scale attack happened?

Then I thought about cell towers. Our phones blindly connect to them every day. In fact, attackers can set up rogue towers that trick phones into connecting to them instead in order to perform a MITM attack. They just have to broadcast a stronger signal. That’s crazy.

So I was wondering: aren’t cell towers basically routers? If so, if an attacker was able to take control of one, and if they had some sort of iOS/Android 0-day in how devices receive packets or whatever, could an attacker essentially spread such a wide-scale attack like NotPetya launched?

Relevant talk: https://media.ccc.de/v/36c3-10737-sim_card_technology_from_a-z

  Our phones blindly connect to them every day.

Wrong, towers need to authenticate; if you're not using obsolete 2G ciphers, that auth can and will be relatively secure.

  In fact, attackers can set up rogue towers that trick phones into connecting to them instead in order to perform a MITM attack. They just have to broadcast a stronger signal. That’s crazy.

and not the case. The average stingray just gets the phone far enough to register with its unique ID.

Not saying that you can't build a malicious cell interceptor, but it'll require cryptographic cooperation with the mobile network operator. (Or a really old phone that accepts downgrade attacks to insecure ciphers, but I think these have become rather rare.)

  So I was wondering: aren’t cell towers basically routers?

No, not really; the infrastructure behind is. However, you control the base station, you define what backend phones connect to.

  If so, if an attacker was able to take control of one, and if they had some sort of iOS/Android 0-day in how devices receive packets or whatever, could an attacker essentially spread such a wide-scale attack like NotPetya launched?

No, because every software distribution system I can think of uses TLS, and/or software signatures.

  and if they had some sort of iOS/Android 0-day in how devices receive packets or whatever, could an attacker essentially spread such a wide-scale attack like NotPetya launched?

It's impossible to discuss the functionality of hypothetical 0-days, since their capabilities are undefined. If there's a weakness that allows the operator of an MNO to execute code locally, well, then it can. Otherwise it can't.


Are there any possible methods for us identifying byte sequences which contains some plaintext? I want to implement one algorithm for automatically identifying some plaintext info from byte sequences. For example:

6d 6c 70 00 00 00 01 d0 03 05 00 00 00 00 00 00 mlp..... ........
27 14 00 00 00 00 01 a7 e5 1a 00 2c 62 73 4a 30 '....... ...,bsJ0
52 63 63 44 4c 34 4a 76 4b 41 52 36 36 30 41 36 RccDL4Jv KAR660A6
77 7a 48 58 78 52 4b 52 58 57 50 42 4d 6f 77 4c wzHXxRKR XWPBMowL
52 34 6d 37 6d 57 67 3d 00 00 00 00 00 00 00 01 R4m7mWg= ........
cc b5 4b d4 41 2e e4 42 48 c2 73 bf 2e 40 68 4f ..K.A..B H.s..@hO
28 9f 24 c0 c7 23 ab af 1d d2 f3 fb aa 15 01 c3 (.$..#.. ........
06 55 83 a7 c3 3a 68 1d 16 ee 7f 01 9a 51 39 1b .U...:h. .....Q9.
0a c9 64 2a 59 ad 4a e7 b9 af 7c 08 29 0c 1d 0b ..d*Y.J. ..|.)...
e9 39 9b d3 c3 3f 38 82 20 c7 d1 81 62 cc 7b 6f .9...?8. ...b.{o
5e 8c 45 ae 5d ec 34 09 2d ec 8a 33 7f 35 e5 05 ^.E.].4. -..3.5..
bf e5 77 7d c4 76 e2 2e 63 1e 21 ef bc 97 d7 df ..w}.v.. c.!.....
2a fb 25 df b0 54 e0 b8 4a 42 36 1f dd d1 7f b9 *.%..T.. JB6.....

This hexdump data contains base64 encoded data,are there any possible methods for  me identifying this data which seems like plaintext from the byte sequences?

Hard to say :) String can be an ASCII string, unicode string, byte string, whatever. It really depends what you are trying to achieve.

In case of base64 its easy, because just 64 characters are valid to be included in base64 string: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/, additionally there can be separator "="

So what you can do is to compare the data byte by byte and check if the byte matches one of characters in the defined character set. If so, add it to string, if not, print previously collected string, set it to empty and continue.

Another way is to use some tool as @TessellatingHeckler recommended. I would recommend it too because it is going to be un-achievable by your own when it comes to UTF or whatever else character encoding.

Edit: I forgot to mention that it will never be possible to collect valid strings only as some random byte sequences looking as string will not be a valid string in the end. Or you can come with some neural network ;) Humans can recognize it easily right? :)


HTTP Public Key Pinning vs Certificate Transparency, which is better and why? We are rolling out a new mobile app. Our security team recommends us to pin the public key in order to avoid MITM. iOS already has CT checks and we can enable that for the Android app as well.

The security team's arguments for pinning are:

Pinning is a more hardened solution
CT is more reactive, we might have to live with a rogue certificate until it is revoked and logged in CT logs
CT checks would not work in environments where corporate assets may have company PKI deployed and MITM attack is done using the company PKI

My argument for not pinning:
Assume we generate a certificate and it is a 2048-bit RSA key pair. The certificate expires in 1 year, maybe 2. We go to the CA for a new certificate and the CA says “No, your key is too small, come back with a 4096 RSA key pair”.
In effect, because we pinned the public key in the app, the app is bricked.

Now we release a new version of the app, but it takes typically > 1 month for the app to be adopted by all the customers. During this time, while our customers are trying to access the app at home, trying to look for offers to come and spend money in our ecosystem, they won’t be able to use the app and hence we stand to lose the customer and potential revenue.

A rogue certificate might affect 1, maybe 2 customers if someone is really being targeted to be hacked (MITM target), but the above risk is a risk to the entire customer base and for amount of time that is not directly quantifiable.

Does it really makes sense to pin? If yes, how do we mitigate the above scenario? Am I not seeing something?

they won’t be able to use the app

If this is true, it means your application design is not good. One of solutions is that if you switch key you should also provide a new end point. For the transition phase you would support both end points, with the old and with the new keys.

When you switch they key, you would also release a new app version with the new key pinned. The old app will use the old end point and the old key. The new app version - new end point and new key.

After transition phase ended, you shut down the old end point. After this phase (1-3 months) only the users who refused to update the app will have problems. All other users will not even notice that you have switched the key.


Windows Encrypted temp directory for files at rest in Windows? It would be nice if there was an area on my computer where I could work with temp files that may contain sensitive information that could be encrypted with bitlocker or something similar when the files are at rest.

It would be even nicer if these encrypted directories could remain with their projects, and maybe be decrypted as needed at the OS level, but then locked out of again.

Is there a way to accomplish such a thing?

All NT-based versions of Windows since 2000 have a feature called Encrypting File System (EFS), although "Home" and similarly low-end editions can't use it. You can look up more information about this feature from Microsoft as well, but here are some relevant ones:

Encryption and decryption is transparent; keys are managed by the OS and used automatically when reading or writing. There's no "locking" or "unlocking" the files; any process running in an authenticated session for any allowed user will be able to decrypt the files.
You cannot actually encrypt directories, but if you set the Encrypt flag on a directory it will encrypt all files placed in the directory.
All file data is encrypted, though file metadata (name, size, permissions, etc.) is not.
Encryption uses user-specific keys. If you want multiple users to have access to the file, you have to have given each user access before encrypting the file.
The encryption keys are protected by the user's password. If a user forgets their password and needs to have an Administrator reset it, the user loses access to EFS-encrypted files unless the user had previously backed up their EFS key. Changing passwords (where the old password is used) doesn't cause any problems, though.
By default, even local or domain administrators cannot decrypt EFS-encrypted files. However, there's a setting in Windows to automatically grant administrators access.
EFS requires NTFS. Moving a file or directory within an NTFS volume, or across NTFS volumes, will not decrypt it. However, moving it to a volume using any other file system (such as FAT32/exFAT as typically used on flashdrives and SD cards) will decrypt the file if possible, or fail the move if not; these file systems do not support the metadata used by EFS.

BitLocker or some other full-volume encryption (FVE) is usually preferred over EFS these days, although they are suitable in slightly different scenarios. FVE will encrypt the file system metadata, such that an attacker wouldn't be able to read file names. FVE uses newer, more-secure ciphers than EFS. FVE is sometimes easier to use offline (if, say, the computer dies and you connect its drive to another machine) so long as you have the recovery key. FVE is machine-wide instead of user-specific. You can combine FVE and EFS if you want to, although it's mostly redundant.


Is there a way to make a WEP-secured AP uncrackable? For some days, I was feeling that my Internet bill was booming. Then, I recently found out that a boy near my house was accessing my router to use the Internet. Then, I read some articles how to crack WEP security and found that it is way too easy to crack WEP.

So I was looking for some ways to increase the security of an AP using the WEP protocol. But I didn't find anything. My router does not support WPA/WPA2. So how can I make my router more secure, I mean uncrackable?

There is no method to make WEP uncrackable, or at least secure. So I suggest buying a new router that suports WPA2.


Hooking an *unexported* API I want to know is there any way to hook (inline hook) an unexported API of a PE?
I have this binary (PE 32 bit) which does not uses any DLL (A statically linked binary) and I would like to know what should be the approach to hook a function in this binary (in memory) ?

Following is a thought of mine, but don't know how practical it is? Please let me know your thoughts. Also, please let me know if you have a better solution.

Inject DLL to the running binary
Injected DLL have to find address of the API to be hooked:

search for byte sequence in text section(bytecode of API to be hooked)

Add the hook (JMP instruction)

If the above way is the only way to do it. How practical is it? Please let me know your thoughts. Thanks in advance.

Following is a thought of mine, but don't know how practical it is?

If you don't have access to the source code of the program, you have to make a lot of assumptions about the format of the arguments, etc. And you have to emulate the original behavior of the function in a way that doesn't break the program, or jump back to the (remainder of) the original function after emulating the part of the function you overwrite with the JMP instruction.

You may also have to change the page protection, as program code is usually not writable by default.

Programs that take certain kinds of anti-reverse-engineering measures will be hard to patch in this manner, because they checksum their program code from time to time.

But, for a plain unprotected binary this can work (with requisite effort expended).


Difference between authentication and identification [Crypto and Security perspective] I am always confused by the way the word authentication is used in security literature (i.e., outside the crypto realm). Most of the time I understand that they are actually implying identification.

For example from Wikipedia: Central Authentication Service uses the term authentication to imply identification (if I understand correctly).

In Crypto, as far as I understand:

Authentication: a proof that message originated from holder of some given secret.
Identification: a non-transferable proof that the other party knows some given secret (without revealing secret)
Non-repudiation: a transferable proof that message originated from holder of some given secret.

[Please let me know if I understood the three terms correctly. Feel free to provide alternate/refined/more helpful definitions]

Can someone elaborate on the meanings of the two terms authentication and identification in both crypto and general security literature?

In the context of communications through a network, an identity is equivalent to the knowledge of a specific piece of data: summarily said, from the outside, what you can know of a given entity from the outside consists exclusively in what bytes that entity emits, i.e. what it can compute. Since everybody can buy the same kind of PC, differences in computing abilities ultimately lie in what the entities know. E.g. you are different from me, from the StackExchange point of view, only in that you know the password to the 'Jus12' account, and I do not, while I know the password of the 'Tom Leek' account, and you do not.

Identification is about making sure that a given entity is involved and somehow 'active'. For instance, the StackExchange server can make sure that I am alive and kicking by challenging me (my computer) with showing my password. Note that the StackExchange server (actually, another server because they use an indirect scheme, but that's a technicality) also knows my password, so when the SE challenge is successfully responded to, the SE server only knows that, at the other end of the line, operates an entity which is either me or the SE server itself. Identification protocols must take care to avoid or at least reliably detect the occurrence of a server induced to talk to itself by a crafty ill-intentioned individual (hereafter designated by the generic term 'attacker').

Identification, as itself, is quite useless. What the SE server wants to know is not that I, Tom Leek, exists and is awake; the SE server is quite persuaded of that, and does not care. What the SE server wants is to make sure that I approve of the HTTP requests that I am going to issue. They want authentication: that's identification applied to some other data. Thus, identification is useful insofar as it can be believed to apply to a bunch of data, which then as a "verified" provenance. The link between the identity and the data must be resilient with regards to the outrages that the attacker may inflict on the data. In the case of StackExchange, the attacker is supposed to be fairly weak, because integrity of an HTTP request is assumed: the identification part becomes a cookie, as part of a HTTP request, and the SE server just assumes that the attacker cannot alter the request or the cookie, or copy the cookie and graft it upon a new phony HTTP request.

More thorough authentication usually uses a cryptographically strong linkage, e.g. a SSL/TLS tunnel (often as part of HTTPS). The cryptographic properties of the tunnel imply that the server can be sure that it will be talking to the same entity throughout the SSL session; moreover, the server assumes that the user will not play any identification protocol related to his account password unless this happens over a SSL tunnel in which the server is duly authenticated (that is, the client is sure that it talks to the right server -- that's what the server certificate is about -- and that whatever data it send will go to that server only, so it is authentication). Under these conditions, if the server can identify me within that tunnel, then the identification covers whatever data is sent through the tunnel afterwards: the tunnel is the link between identification and data, so this is authentication.

Non-repudiation is a characteristic of some authentication protocols, in which the link between identity and data can be verified not only by whoever is, interactively, at the other end of the line, but also by an ulterior third party, for instance a judge. Password-based schemes do not normally offer that property, because whoever verifies the password must also know it more or less directly, and thus could frame the alleged emitter. Non-repudiation requires mathematics. Note that, in a SSL tunnel, the client authenticates the server through its certificate, which is full of asymmetric cryptography, but this does not grant non-repudiation: the client is sure that whatever data it receives from the server really comes from the server, but there is nothing that the client could record, which would convince a judge that the server really sent that data. To get non-repudiation, you need digital signatures. Without non-repudiation, one can get authentication with algorithms known as Message Authentication Codes, which are computationally lighter. Confusingly, there is a widespread (but incorrect) tradition of calling MAC "signatures".

Summary:

Identification: the specific entity E is involved and responding.
Integrity: whatever piece of data was received has been sent as-is by some entity E' and was not altered.
Authentication: identification and integrity at the same time (E = E').
Non-repudiation: authentication that can convince a judge.


Emacs and EasyPG not performing public key encryption I have a file which I edit and encrypt following this guide.
I'm a noob as far as security goes and thought that the point of including the line which specifies the cryptographic key to use

-*- mode: org -*- -*- epa-file-encrypt-to: ("my_key_email@foo.org") -*-

would therefore require me (specified by my email) to enter in my passphrase.
However, it seems that I'm doing things wrong as I'm instead doing symmetric encryption instead.  I know I'm doing symmetric encryption because I am never prompted for my_key_email@foo.org's passphrase. I can list the keys in emacs and my email shows up in the list when I "M-x epa-list-keys"

Can someone point out where I'm going wrong such that I can use my passphrase to encrypt the files? I want to prevent locking myself out by accidentally encrypting the file with a new password, which sadly has happened. :( And from what I've read so far, cracking the file is dang near impossible.

For completeness sake here is my .emacs file

(require 'whitespace)
(setq whitespace-style (quote (spaces tabs newline space-mark tab-mark newline-mark)))

;; EasyPG
(require 'epa)
(epa-file-enable)

(defadvice epg--start (around advice-epg-disable-agent disable)
"Make epg--start not able to find a gpg-agent"
(let ((agent (getenv "GPG_AGENT_INFO")))
(setenv "GPG_AGENT_INFO" nil)
ad-do-it
(setenv "GPG_AGENT_INFO" agent)))
;;(setenv "GPG_AGENT_INFO" pinentry)))

(defun epg-disable-agent ()
  "Make EasyPG bypass any gpg-agent"
  (interactive)
  (ad-enable-advice 'epg--start 'around 'advice-epg-disable-agent)
  (ad-activate 'epg--start)
  (message "EasyPG gpg-agent bypassed"))

(defun epg-enable-agent ()
  "Make EasyPG use a gpg-agent after having been disabled with epg-disable-agent"
  (interactive)
  (ad-disable-advice 'epg--start 'around 'advice-epg-disable-agent)
  (ad-activate 'epg--start)
  (message "EasyPG gpg-agent re-enabled"))

;;added to overcome bug in gnupg2 in Arch linux as pointed out here: http://www.emacswiki.org/emacs/EasyPG
(when (file-executable-p "/usr/bin/gpg1")
(setq epg-gpg-program "/usr/bin/gpg1"))
`

You already seem to be doing public key encryption.

In public key encryption, the data is encrypted with the public key and it is decrypted with the private key. The password is only used to protect the private key. The public key is public for anyone to use, therefore it is normal that you are not requested a password when encrypting.

Credit to William Hay who suggested both this and another possible explanation in a comment to the original question.


Block Incoming-Teamviewer Connection Is it possible to use an open-source tool such as Cisco IPS or Cisco ASA to block incoming Teamviewer connections to specific internal IP blocks, while allowing the outgoing ones? I cannot find a specific answer on other online sources.

I don't think you can do this with firewalls, at the networking layer. When you connect someone with TeamViewer, you don't do it directly. TeamViewer users connect each other by using a third party server in the middle.

You can see the answer of kobaltz for the question How exactly does a remote program like Team Viewer work?

  When you run TeamViewer, you are assigned an ID on their broker server. You make a connection to a Teamviewer ID, and TeamViewer passes the connection down through the TeamViewer client's established tunnel to the destination and you then you are prompted for password and then the connection establishes afterwards.

To achieve your goal, you should use TeamViewer's way. I think this article from TeamViewer is what are you looking for:  How can I restrict access for TeamViewer connections to my computer?

  You can also restrict access to your computer in different ways. Depending on how you want to restrict access and to what extent, choose one of the following options:

  To completely prevent any access with ID and password, exit TeamViewer in the taskbar.
  Any incoming or outgoing connections are no longer possible.
  To restrict access to ordained devices, use the Black- or Whitelist in the TeamViewer full version. Deny incoming connections for specific TeamViewer IDs or only allow connections for defined TeamViewer-IDs.
  To restrict features for incoming connections, use the access control for incoming connections. Choose between Full access, Confirm all, viewing access or deny any incoming remote control connection.
  To deny connections from outside your network, only allow incoming LAN connections.


Why did OCSP Must-Staple break BitDefender SSL interception I use one of my website as a test for various TLS techniques. Recently I added OCSP Must-Staple to this domain. After a week I got a complaint from a user they were unable to visit the website. They got the error from Opera, Edge and Chrome. The Chrome error was the clearest: ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

After some testing I found out their BitDefender doing SSL intercepting was the culprit. Now, I don't want a discussion about whether companies should be doing such a thing. I presume ERR_SSL_VERSION_OR_CIPHER_MISMATCH is just BitDefender saying: "I am unable to do anything with this, let's just block the user from visiting by negotiating no valid SSL version / ciphers with the browser". But I don't understand how the Must-Staple in the certificate caused this.

Maybe it wasn't actually the Must-Staple, or maybe it was in combination with some other header. I have HPKP headers which would be the next possible candidate, but I have had those for almost a year now. I am not that well versed in VM's and WireShark to do much investigating. Could someone help determine the actual cause to satisfy my curiosity?

SSL labs report

First of all, as it is common with TLS errors, ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome is in no way descriptive of a particular problem.

Next, I admit that I have never in my life touched BitDefender and especially its TLS wiretapping techniques with a ten foot pole, nor that I'd ever wanted to.

Having said that, I've seen a similar bug in similar products, so I may happen to give you a clue.

See, when a TLS interceptor sees a certificate, it copies it, replaces the certificate authority data with its own and signs it, and then sends to the browser (or whatever client software is trying to make a secure request). A basic TLS interceptor doesn't do anything else to the certificate: it doesn't, say, change subject alternative name field or mangle any other X509v3 extension value. Only the CA data is changed, the rest of the certificate is left as is.

As the CA data is changed, the subsequent OCSP staple won't obviously be valid, so the interceptor strips that data as well. In fact, it's acting as a proxy, so it doesn't strip anything, it just doesn't put a staple into the browser-facing connection even when it receives a staple from the server-facing connection, and that's it.

Now, the browser receives the certificate, signed by the interceptor, with OCSP Must Staple on it, but doesn't get a valid OCSP staple because it's not sent by the interceptor. At this point, the best your browser is able to do is to halt the TLS connection and display a cryptic error message.

NB: this is one way to break OCSP with a TLS interceptor that I'm aware of. BitDefender could be actually using another method, there are surely plenty of them.


Can HSTS be disabled in Firefox? For pentesting/VA, it is, of course, imperative to always be able to see the HTTP site of a target. If present, HSTS conflicts with this need.

Without using a proxy to address the problem (e.g. Burp), is it possible to natively disable HSTS in Firefox?

Type about:support in firefox
Click Profile Folder | Open Folder which should open your profile folder.
Find file called SiteSecurityServiceState.txt and open it
Find the entry for your site url and remove it. Entry would looks something like - github.com:HSTS  120 17242   1521194647604,1,1
Make sure for above firefox is closed so that it does not overwrite it.

Firefox stores HSTS entries in this file with their expiration periods. Removing this entry should allow you to hit http url. TO further prevent it you can probably change permission of this file to read only.
More details - Understanding HTTP Strict Transport Security (HSTS)
NOTE : This will not work for well known sites like google as those lists are preloaded by browsers. Works fine for others. See above link for details.


Google rank and HTTP/HTTPS site We have SSL on our site, however we have some legacy applications that do not support SSL, what to do in this case?

In order for them to work correctly will I have to leave HTTP and HTTPS active?

How does Google rank works in this case?

For the first part of the question, you could considere setting up a reverse proxy (Apache or nginx) in front of the legacy apps and have the SSL processing on the proxy. If you have full control on the datacenter, the proxy and the application can run on different machines, if you do not, they should run on same machine for obvious security reasons.

The second part (Google rank) is off topic here.


What are the disadvantages of a partial encrypted file system? There are two disks, one with a read-only filesystem, which holds the installation and configuration files (think root, usr, opt). The second disk is encrypted and holds everything dynamic and user data (think home, srv, var).

There is no swap and /tmp is on a ramdisk.

What are the security risks vs an fully encrypted filesystem?

Assume an attacker Grace who has physical access to your machine.

She doesn't know your password and wants access to the data stored on the encrypted disk. You will only type in your password if the machine seems not to have been tampered with. Plugging a device which stores everything you type on your keyboard between the keyboard's USB cable and your computer or hiding a microphone which records what you type (yes, that's actually possible) is risky because those modifications can be found.

So Grace decides to go a different path. She assumes that you won't swap out your read-only disk (bwt.: I hope it's a read-only disk because if it's only a read-only FS like you describe in your questions, you have a lot more to worry about) and on day α copies your read-only disk onto a disk of her and also writes down which read-only disk you're using.

She then figures out what program receives the password when type it in and modifies it so that it's stored in a place of the encrypted hard disk which probably isn't accessed during normal usage if the password is correct. She then swaps out the program on the copy of the read-only disk for her modified version and copies the FS to one of the same model of read-only disks you're using and makes it unwritable.

On day β, she takes her read-only disk to your computer and swaps your disk out for hers.

She then just waits until you use the computer and subsequently on day γ copies the contents of your encrypted disk.

Afterwards, she can decrypt everything.

This would not have been possible had you only used a single encrypted disk.


Why was DES with 112 bit keys (IBM) reduced to 56? On the French wikipedia page about DES it says that the original DES algorithm from IBM used 112 bit keys.

Why did they reduce this to 56 bits?

Edit: ok NSA convinced IBM but today it seems like a mistake. So did they have objective arguments or just impose their will?

The NSA convinced IBM that 56 bits was "enough":

  But whereas Lucifer had a key that was 112 bits long, the DES key was shortened to 56 bits at the request of the National Security Agency.

from Practical UNIX & Internet Security

  In the development of DES, NSA convinced IBM that a reduced key size was sufficient

from Data Encryption Standard - Wikipedia

  The NSA made two changes to DES: It tweaked the algorithm, and it cut the key size by more than half.

from The Legacy of DES - Bruce Schneier


JWT vs custom encryption for REST APIs over https For our REST API architecture, we are currently thinking over two options -

Json Web Token - pros are that it is industry standard, we pass a key which adds a layer of access control and using which we can also add secondary authorisation restrictions at our backend, maintenance of session and related security features are provided by Django by default.
Cons are that the params are open for anyone to see, it seems (and correct me if I'm mistaken) that it is possible that if someone gets access to our link, he could alter a param that is not linked with the core authentication process and thus compromise the data.

An in house encryption process we developed that encrypts all the params. Pros are that we are fairly certain of it to have never been compromised, for even if the link would have gotten into the hands of someone they wouldn't have known how to decrypt it to look at the params.
Cons are that we have to manage all the session data through our backend code in our tables, so we aren't able to utilize the Django features. Also, the idea that what we are doing isn't industry standard.

What is the right way to decide in this situation, and what are the factors that we should take into account?

Don't roll your own crypto!

This is the golden rule of cryptography. If you do, your application will crash and burn, and all the hackers will laugh at you. It has been done time and time again, with companies boasting about how their "custom encryption algorithm" is perfectly safe, because it's closed source and no hacker could ever figure out how it works. Turns out that it had huge glaring issues and exploiting it was trivial, every single time.

Even expert cryptographers, who spent decades studying how to make good cryptographic algorithms, consider it extremely difficult to make an algorithm that is safe against all kinds of attacks.

But what should we do now?

That depends entirely on what your API actually does, and what you use these parameters for. What JSON Web Tokens do is "representing claims securely between two parties". If this is what your API needs, then you should absolutely go for JWT.

Basically, once the user has authenticated themselves to your API, the API can then generate a JWT and send it to the user, which they can use to authorize themselves on every subsequent claim.

But can't an attacker just copy my token and thus steal my authorization?

Yes, if you used plaintext communication. But you should not be using plaintext communication, you should be using HTTPS to secure everything.

So why would you actually use JWT then? Because it prevents the person you sent the token to from modifying the claim. If you sent

{
    "uid": 163495,
    "sub": "MechMK1",
    "role": "User"
}

to me, then I would not be able to modify the claim to set my role to "Admin", for instance, since then the signature would not be valid anymore.


Security implications of auto-submitting OTP? So the question was originally asked as a part of the UX question here.

My question is that, Are there any security risks involved when I auto-submit the OTP? Currently, I'm limiting the number of verification attempts from the backend side.

What are the points that one should keep in mind while auto-submitting the OTP? I'm designing the app for the mobile platform.

I can't see any security implication with auto submitting a field rather than requiring them to click a button to submit the OTP. At worst you may have a few more accidental incorrect password submissions when people make a typo and it submits before they can fix it.

I guess it could be an accessability issue if you set the number of attempts very low and locked out accounts as a result.

There's a the small potential that when you lower the barrier of 2FA so low people may not put in the mental effort to notice when something is wrong https://www.biocatch.com/blog/ios-12-security-otp-autofill (although that specific link referrs to auto filling from a SMS message)


Encrypting the System Infrastructure The requirements are to Encrypt the data in our servers 'at rest' and the 'database' - in short the whole infrastructure.

Threat Model - to protect a possible data-breach by an adversary (or from unauthorized entity), from physical theft (or for safe disposal) and for secure duplication (for safe backups).

Problem - We are a 'SaaS' and deals with tons of users requesting data back and forth (from our servers) - therefore, the data which we plan to encrypt should remain highly accessible (user files, messages etc) and encrypted at the same time - without having a Public/Private Keys schema from the User side, which establishes the following notion.

Data should get encrypted as soon as it enters into the server (using any symmetric-crypto mechanism) and stays available for the users when they asks for it | A bit of research has shown full-disk encryption mechanisms (e.g. LUKS, lib-crypt, or PGP) which I'm not sure will do the job or not.
If full-disk encryption is the answer to our quest then the second issue is having the encryption key (being available on the same server) which will not address our threat model (as for an attacker who got the server access will not take much time to get the encryption-key as well). Secondly, it will require someone physically entering the (crypto) password on every server reboot (which is not possible - since most of our team works remotely and prefers automation).

Precise Concern: Which Encryption scheme will do the job efficiently by staying (robustly) available while covering the mentioned Threat Model - and what will be the preferred system architecture for handling those operations effectively?

The whole point is to protect the data which is being stored on our side in every possible way without compromising the overall performance.

I'll highly appreciate your enlightenment in this regard.

I am the Security Specialist at a SaaS company and we were looking at the exact same issue earlier last year.

The main issue you will run into is cost.  If you want your database to be readily available, but encrypted 'at rest' you basically need a beast of a server that does nothing but handle the encryption/decryption process.  As decrypting the data that you need to read is going to give you a performance issue, even with a beast of a box, you are still going to get at least 1 or 2 milliseconds delay added to your queries.

We looked into SafeNet's ProtectDB, but as we are not currently going for a PCI or a HIPPA compliance, we deemed that the ~$50k+ investment cost was not worth the limited benefit.

EDIT: ProtectDB is basically a separate server that houses all the encryption keys, and does a scan of your database to see where the data is.  When you are making a Database query, the ProtectDB box receives the traffic instead, and makes an encrypted connection to the database, decrypts the column / table, and returns the data.  Thus making it so that your devs/users are not actually directly connecting to the database anymore, instead you are connecting to the ProtectDB box.

Really, you are only getting two benefits: preventing someone from walking into your data center / DR site and stealing the physical box, and that is what security guards and physical locks are there to prevent. Or, if you get a major external network breach, and someone manages to get your database.  In both cases, you are really only adding time to how long it will take to break anyway.

I would honestly recommend that you invest that money into a WAF (if you don't already have one), like Incapsula, instead.


Robots trying to login to Azure VM when SSH port is closed in manager I have many robots trying to do SSH login in a Azure VM. In the resource manager SSH is disabled but attacker IPs are public, as you can see below, where I copy a log for auth.log (I have an Ubuntu machine). Fail2ban is blocking these IPs but I do not understand how they are coming to my VM.

What can be happening?

PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.18.238.7  user=root
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.18.238.7

Failed password for root from 121.18.238.7 port 60579 ssh2
message repeated 2 times: [ Failed password for root from 121.18.238.7 port 60579 ssh2]

No need to worry, these are just typical attempts to find vulnerable servers. You've Fail2Ban already installed, this way you decrease the brute force attempts.


How does an offline CA revoke certificates? If an RSA private key of a root CA is stored offline, how does it revoke certificates it signs?

From looking at OpenSSL config the default_crl_days option seems to indicate that a CRL must be regenerated every x amount of days. For an offline CA, this would seem to mean that someone would have to manually do this on this interval.

Is this correct, or is default_crl_days meant to be a TTL for clients to re-check the CRL? Is there a way of avoiding regenerating the CRL if nothing has changed?

A CA must indeed publish CRL regularly, and if the CA is offline, then human intervention is needed. Each CRL has an issuance date (thisUpdate) and a provisional date of next publication (nextUpdate) which everybody uses as an end-of-validity date for the CRL. The next CRL must be published before reaching the nextUpdate date of the current CRL; otherwise, verifiers will begin to reject the certificates.

Common practice is to have an offline root CA which issues relatively long-lived CRL (e.g. one CRL every three months, with a nextUpdate set to current time + 4 months). That root CA is used to issue only a single certificate, for an intermediate CA, which is online, and does the bulk of certificate issuance (and that intermediate CA publishes CRL much more regularly). The offline root CA is kept as a "last recourse": if the intermediate CA is compromised, then the root can revoke it, so there is a "bad period" to suffer (until the end of validity of the current root CRL, at most), but the root key distribution needs not be redone when the new (intermediate) CA is built and started.

A niftier method is to have a semi-offline root CA: the root CA is linked with the outer world through a physically one-way canal (I have done it with an audio cable: the "line out" jack on the server is inherently one-way, so no risk of intrusion coming up that cable). This allows the root to publish CRL often (e.g. one per week, even one per day) without needing human intervention. Actual revocation would still need physical intervention, so an intermediate CA as described above would still be highly recommended.

Note that an offline or semi-offline CA cannot synchronize itself with network time sources, so the root CA clock may drift. Since the CRL have a validity period, this requires some supervision (you can tolerate a drift of a few minutes, so this is no hardship, but you'd better keep an eye on it anyway).


netcat vs nmap for banner grabbing? I am preparing for a security exam and a question I failed in a practice has the following:
A command line tool that can be used for banner grabbing is called:
A) tcpdump
B) netcat
C) nmap
D) Wireshark

I chose nmap, but the correct solution is apparently netcat. I am aware that netcat is used for banner grabbing, but so is nmap: https://www.hackingarticles.in/multiple-ways-to-banner-grabbing/
What did I miss? Is the question incorrect?

tcpdump & wireshark
You can quickly rule out tcpdump and wireshark since both are used for packet captures. While banners could be grabbed by obtaining full packet captures, an encrypted stream circumvents it. Having access to the private key could decrypt the encrypted stream but not feasible for this question. It's overthinking and unlikely.
That leaves nmap and netcat.
nmap
Perhaps, for this material, nmap was placed in the network port scanner category. Its good you recognize there's much more functionality for I too see it as the "practical" answer.
netcat / nc
netcat is best known for establishing network connections which allows file transfers, sending custom requests to services (e.g. SMTP, HTTP, etc), and tunneling; just to name a few. So with nc handling the lower OSI layers of the connection, the user can manipulate the upper layers as needed. With banners being at the Application layer, nc can be used and likely why it's the desired answer.
Alternative
Another way to look at it is to consider pivoting. Of all the listed utilities, tcpdump and netcat are natively available on Linux/Unix systems. Thus making netcat the answer.
Context Matters
As mentioned in the comments, tests often look to evaluate your knowledge of the material. So it's best to approach questions using that lens.


UDP sockets open on all ports I'm on osx. netstat -an -f inet gives me a bunch (around 10) of entries like these:

...
udp4       0      0  *.*                    *.*
udp46      0      0  *.*                    *.*
...

In my understanding, this means there are applications accepting udp packets on any port from anywhere on any interface. Isn't this a security risk? How do I identify the processes that opened these sockets?

EDIT:

I identified some processes owning these sockets using lsof -i. They include WiFiAgent, sharingd, SystemUIServer and UserEventAgent. All of these seem to be part of OSX. However, there are much more entries in the netstat output than in the lsof output.

In addition, I still fail to interpret the netstat output. I thought it is only possible to open a BSD socket on a specific port, or to let the kernel assign a port if none is specified. So what does the *.* mean in the "Local Address" column?

I don't think you need to be too concerned. There are many legitimate reasons to have the UDP processes you have identified.

As you have noted, lsof can be used to find out which program is associated with the socket. Note that you will need to use sudo to run the command if you want to see information for processes which are not owned by the current user.

The . is the interface and port. If the interface is *, it means that the socket is bound to or can bind to all interfaces i.e. 127.0.0.1/localhost the IP of your ethernet or wireless interface and possibly the 224/multicast interface.

If the port is listed as *, it normally means there is no active connection to the port and there is no defined or well known port used by that service or it is a service that allocates ports dynamically and there is no current connection. When there is a connection, there will also be something listed in the status column, such as LISTEN, ESTABLISHED etc.

UDP ports are broken up into 3 basic groups 0 - 1023 used for common, well known services. Ports 1024 - 49151 for IANA-registered port use and 49152 - 65535 which are available for use by services and can be assigned dynamically as needed (assuming nothing else is using the port of course).

With respect to general security, there are a few basic principals you should follow

Turn on the OSX firewall. This will limit what can connect and to what ports. In general, the standard config allows your services to connect to external addresses but only allows external address to connect to you for either ports you allow or when it is part of some already established session - for example, if you have initiated a service which as part of that service, the remote system needs to communicate back to you on a UDP port.
Disable any services you don't use. For example, if you don't use OSX data sharing services, turn them off. Likewise, if you are connected over a wired connection and don't need wireless, turn it off. If you don't use/need location services, turn them off etc.
Some services can be configured to only listen on specific interfaces or only allow connections from specific hosts. This is more common with TCP, but can be done with some UDP based services. However, you need to be careful as you can break or adversely impact on a service if you restrict it incorrectly.

The key point is that you don't rely just on a single layer of protection. You have multiple layers so that if one layer should fail (due to a bug, misconfiguration, zero-day vulnerability etc) other layers of protection may provide protection. For example, I have a firewall on my OSX system, a firewall on my router and various security settings on my internal networking switch.

One of the benefits of something like OSX over Linux (for example) is that it has pretty reasonable defaults. Provided you follow the advice/best practice recommended by Apple, your in a pretty good position. However, one of the disadvantages of this approach is that it is often much harder to tweak the configuration to meet your specific needs. With a Linux system, you have full control and can tweak it to be as locked down as you like. However, you also have the power to completely screw it up. With OSX, Apple has taken some of that power away or made it very difficult to get to, so you have less chances of screwing it up. However, when Apple screw it up, then everyone is at risk. The other problem is that because it is so standardised,it provides a bigger target. Linux, with less standardisation means that if someone wants to find an exploit, they also have to find a Linux box with just the right mixture of software and configuration in order to have assurance the exploit will work. This is why I use my Linux system for high risk situations/environments and my OSX system for low risk situations. I spend less time tweaking and configuring my OSX system and it is convenient. I spend more time with the Linux system and while it is less convenient, it is more secure.

It should be noted that as UDP is a connectionless protocol which does not have the 3-way handshake of TCP, the security threats are a bit different. UDP is sometimes referred to as an unreliable connection because it does not have all the checks and balances of TCP sockets. It is used where loss of datagrams or datagrams arriving out of sequence is not a problem. It therefore tends to be used when you want to send/receive simple and low importance data. It isn't suitable for bi-directional communication where the order of packets is important and there is likely to be a 'session' involving a bi-directional conversation/communication. This doesn't mean you can't do such things, but that it is typically harder and less reliable than a TCP connection.

One of the most common threats based around UDP is denial of service. Because there is no handshake in the protocol, it is very easy to spoof the originating source IP. Many of the reflection and amplification denial of service attacks use this technique. For example, I could use the NTP protocl config flaw which allow you to query an NTP server over UDP to request a list of all the servers which have used it to synchronise their time, but instead of having my IP address associated with the query, I spoof a victims address. The NTP server receives the request and sends the response back to the spoofed IP I used. This is the reflection part. As the response is much large (more bytes) than the request, the data returned is larger than the data sent - this is the amplification part. If I do this to a large number of NTP servers, suddenly my victim starts receiving all these UDP datagrams it did not request. You can't do this easily with TCP because when I spoof the address, the destination I send the data to immediately tries to do a handshake with the spoofed IP I used. The real host with that IP will receive this handshake attempt and essentially go "eh What?" and the handshake will fail because it did initiate and doesn't know anything about the connection.


Can hash functions be used with CTR or OFB mode? I have been writing a class that encrypts and decrypts with block ciphers. I want to use Counter Mode(CTR/CM). We know that Counter Mode generates a keystream basing on counters, then XOR the keystream with plaintext to produce ciphertext. So, one can decrypt as long as he can reproduce the keystream, that is, to reproduce the counter and get the right key.

I observed that the decrypt method of a cipher is not necessary in CTR mode, since to reproduce the keystream we only need to encrypt counter blocks again.

So why can't I replace the ordinary cipher with a hash function(thus make key part of the counter) or a HMAC function(which accepts a key)? Are hash functions not-so-pseudorandom when compared to ciphers in keystream generation, or there's more reason?

p.s.: This question also works with OFB mode -- hashing an IV with or without a key again and again also produce something looks like a keystream.

p.s.2: an example:

1)Let's construct a counter of 16 bytes:

aPADDING00000000
aPADDING00000001
aPADDING00000002

Here we get 3 blocks.

2)Then use HMAC of MD5 to generate keystream:

key = 'This is a key.'
stream[0] = HMAC('This is a key.','aPADDING00000000').hexdigest()
stream[1] = HMAC('This is a key.','aPADDING00000001').hexdigest()
stream[2] = HMAC('This is a key.','aPADDING00000002').hexdigest()

# now stream is:
# ['73f2e665c30aaec5bbead51166aaa85f',
#  '91392d0755638fbce5c689f96b02494f',
#  '1d18a81751179858d151dd86179385f9']

stream_str = "".join(stream).decode('hex') # stream_str = '73f2 ... 85f9'.decode('hex')

3) Now stream_str looks very much like a keystream. To encrypt:

plaintext = 'This is a plaintext that has length of 48 bytes.'
ciphertext = stream_xor(plaintext,stream_str) # stream_xor XORs the two inputs bit by bit.

or, to decrypt:

decrypted = stream_xor(ciphertext,stream_str) # ciphertext produced before.

Angelo Rosiello and Roberto Carrozzo proposed this exact scheme (hash based OFB) in a 2005 paper called "ARC: a Synchronous stream cipher from hash functions" and showed that it is secure as long as a strong cryptographic hash function is used and the hash function is pseudo-random.

But the question is: why use a hash function instead of a block cipher? Block ciphers such as AES have proven more resilient over time to attack compared to hash functions. AES is generally faster than a SHA256 HMAC. What advantage is there to using HMAC for this?


Explain the last part of how Mitnick hacked Tsutomu Shimomura with an IP sequence attack I was reading up on why TCP ISNs need to be randomized, which led me to this write up by Tsutomu Shimomura. I understood how IP address spoofing and predicting the ISN helped the attacker establish a one way connection to the 'x-terminal'. But after that the attacker sends this data - rsh x-terminal "echo + + >>/.rhosts. He doesn't explain what this did and how he was able to get root access to the 'x-terminal'. I understand that rsh allows you to execute commands on a remote host. What I don't understand is what exactly does the command echo + + >>/.rhosts do?

This file is a configuration file for some kind of antique unsecured ancestor of ssh: rsh (Remote SHell, more info including syntax example here).

This antique tool relies its security on TCP three-way handshake in order to trust that a remote host is really who it pretends to be. Due to ISN prediction, you already know this was a weak way of authentication.

Then, the same way that nowadays we can use private keys to allow password-less access to a system, in those days you could configure rsh to ease your systems remote administration by filling the list of remote hosts and users allowed to connect to you system (just hostnames, no asymetric key involved, remember? Trusting the underlying TCP protocol...).

And here, what Mitnick does is simply to put a generic mask allowing any user from any host to connect...


What information is leaked from an OpenPGP encrypted file? If an attacker obtains a file that has been encrypted using an OpenPGP public key, what information can the attacker deduce?

For example, to what degree of certainty can the attacker deduce the identity of the intended recipient?

The key ID of the recipient is included in plain-text in the encrypted file. Other possibly interesting information "hidden in plain sight" is just the size of the file, or the name of the encrypted file (if someone just sends it without alteration of course.)

What you might not realise is that the recipient Key ID is effectively an optional field. Section 5.1 goes on to say:

  An implementation MAY accept or use a Key ID of zero as a "wild card"
     or "speculative" Key ID.  In this case, the receiving implementation
     would try all available private keys, checking for a valid decrypted
     session key.  This format helps reduce traffic analysis of messages.

You can encrypt using the -R (or --hidden-recipient) flag with gpg to avoid revealing the recipient's public key in an encrypted message.

$ gpg -e -R torvalds@linux-foundation.org message.txt
$ $ gpg --verbose --verbose --decrypt message.txt.gpg
:pubkey enc packet: version 3, algo 1, keyid 0000000000000000
    data: [2047 bits]
gpg: public key is 00000000
gpg: anonymous recipient; trying secret key aaaaaaaa ...
gpg: anonymous recipient; trying secret key bbbbbbbb ...
gpg: anonymous recipient; trying secret key cccccccc ...

:encrypted data packet:
    length: 76
    mdc_method: 2
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: secret key not available
$

As this point, gpg iterates through all the private keys it has trying to obtain a valid session key, as it cannot identify the public key used for encryption. However, also see this answer for ways to differentiate between recipients if the attacker has access to a large number of messages.

A practical aside -- secondary clues may be in various logs. For instance, an attacker who obtains such a message might also be able to access (say) a .bash_history file with the recipient's address, or a web-server log with IP addresses that provide clues to who POST'ed or GETs the file, etc.


Secure the config file of a service I have a service running on a linux box, started with upstart, that runs as user "the_user", it has to read a config file. Having the file owned by root would make things more secure, but would prevent the service reading the file.

I know that nginx can read a private cert file owned by root while running as a non root user.

I read about the approach or sourcing a script that sets sensitive environment variables read from a root owned file, and then launching the service process as the service user, which then "inherits" from the environment variables.

What is the best approach ?

Im unsure if this is the "correct" approach, but I would change the permissions of the file to owned by root but also owned by another group which only has read access. Making sure your upstart user is in this shared group.

# groupadd upstart
# usermod -G upstart the_user
# chown root:upstart the_file.conf
# chmod 740 the_file.conf

The above adds a new group "upstart" at which point user "the_user" is added. The file ownership is changed to user "root" group "upstart" and permissions set to "root" read, write, execute; and group "upstart" read.


How do I protect my info from apps like CallApp? It appears to me that apps like Whoscall and CallApp might access your photos and such. In case of a potential data breach/hacking in one of these apps - how can I delete my info from their servers?

If there was a breach then your information are likely no longer only at their server anymore and it is impossible to delete all copies. If you want to stop using these apps and want to make sure that your data are removed now (before a possible breach) you need to check this with the companies responsible for the apps since only these can remove the data. There is no universal way to remove private data from the web, no undo sharing data or similar.


Security of PDF reader software Are there any studies regarding the security of PDF viewer software from different vendors? I try to find the most secure reader.

PDF.js has been developed in javascript and is inside the (very secure) js sandbox. Chrome has one of the most secure js sandboxes, so you might want pdf.js in chrome.

Evince is very easily exploitable. I don't know which part the fuzz-testing included, but Evince bases on poppler, so that may make Okular insecure, too.


Why would I need to use the PRIVATE key to verify a file signature? I use JavaScript to open CAPICOM store to choose certificate. After that I export selected certificate, public key and private key of that certificate and put them in three hidden fields.

var privateKey = certificates.Item(1).PrivateKey;
var cert = certificates.Item(1);
var publicKey = cert.PublicKey().EncodedKey.Value

When signing xml I used:

To take certificate:

Dim hideCertCapicom As String = Replace(HiddenCert.Value, " ", "+")
Dim certificate As New X509Certificate2(Convert.FromBase64String(hideCertCapicom))

For defining private key I used:

Dim keyC As String = hideKey

Dim cspp As New CspParameters()
cspp.KeyContainerName = keyC

Dim tmpRsa As New RSACryptoServiceProvider(cspp)
tmpRsa.PersistKeyInCsp = True

This will successfully signed my xml.

For verifying xml I used:

Dim hidePublicKey As String = HiddenPublicKey.Value

Dim keyC As String = hidePublicKey

Dim cspp As New CspParameters()
cspp.KeyContainerName = keyC

Dim tmpRsa As New RSACryptoServiceProvider(cspp)
tmpRsa.PersistKeyInCsp = True

But this doesn't work. It works only if I use the private key again.

Is it good practice to sign and verify with the same private key or to do both with public key?

I was able to sign with private key and verify the signature with public key, and I want to share with you.

In SignXml() function I exported public key from private key:

Dim publicKey as String = tmpRsa.ToXmlString(False)

Then in the same function I call verifyXml() function:

Dim verifySign As Boolean

verifySign = VerifyXml(doc, publicKey)

In verifyXml() function I took public key on this way:

Public Function VerifyXml(Doc As XmlDocument, Key As String) As Boolean

     Dim tmpRsa As New RSACryptoServiceProvider()
     tmpRsa.FromXmlString(Key)

     Dim signedXml As New SignedXml(Doc)

     Dim nodeList As XmlNodeList = Doc.GetElementsByTagName("Signature")

     If nodeList.Count <= 0 Then
        Throw New CryptographicException("Verification failed: No Signature was found in the document.")
     End If

     If nodeList.Count >= 2 Then
        Throw New CryptographicException("Verification failed: More that one signature was found for the document.")
     End If

     signedXml.LoadXml(DirectCast(nodeList(0), XmlElement))

     Return signedXml.CheckSignature(tmpRsa)

End Function


How can ssh defend against timing analysis attacks? Along the lines of electrical usage revealing what TV show is playing, ssh timing attacks could reveal kinds of traffic, such as streaming video or even what specific video is being streamed.  This has already been mentioned in the context of leaking information about keystrokes. I would assume the principle applies to other categories of traffic as well.

How can ssh defend against timing analysis attacks for arbitrary traffic?

It is true, by analyzing the timing and size of packets, one can roughly determine whether those packets were keystrokes -vs- output.

This might give some (very rough) clues as to what you were doing when signed in to that server's SSH. For example, you might be able to guess if I was using vim -vs- analyzing logs -vs- running basic commands.

But what's the benefit to the attacker? I'm not seeing much here, but it is possible.

Related: ssh login failure detection at packet level

How to defend?

Do you really need to?
Use a VPN, which provides some protection by masking whether you are connecting to SSH at all, and which SSH you are connecting to.
The protocol could be modified to constantly stream data so that keystrokes no longer produce a spike in packet frequency.


Two factor authentication with my bank My bank requires a security dongle. Place the debit card in the card reader and enter a pin code.

An 11 digit code appears which is entered on the bank's website and access is granted.

But if I want to set up a payment they ask for all the details and then produce an 8 digit number, which includes data of the recipient. I then have to put my card back into the reader, enter my pin and then this 8 digit code.

The reader then produces a new code which has to be entered into the bank. If that is correct the action is authorised. If the reader is not communicating with the banks website how does it know how to produce the code?

It's hard to say how the implementation works without knowing what they are actually using. But most likely it will be something along these lines:

The smart card has a shared secret embedded on the chip and requires a PIN
A challenge is sent to you which includes a random generated value and often the amount which needs to be transfered and may also include a time parameter (to limit the signatures validity over time).
You generate an output based on the parameters using your shared secret
The output is sent to the bank and they perform the same calculation and see if it matches. When matched they are sure you signed the transaction.


What's the difference between `aes-128-cbf` and `aes-128-gcm`? We often hear of AES-128-CBF and AES-128-GCM, but what's the difference between them?

That last part refers to the mode of operation of the cipher.

GCM is the Galois/Counter Mode which provides authenticity. You probably mean CFB for the first one, which is the Cipher Feedback Mode, an older and more simple one that provides no additional function.

The main differences between cipher modes is what they are optimized for and what features they provide. Many require an IV, but some only a nonce. Some leak patterns (ECB), most don't. GCM includes a MAC, most others don't. GCM is also optimized for performance.


Anonymity of prepaid SIM card in phone linked to real identity I want to use a prepaid SIM card (text and calls only) anonymously. I bought the SIM card offline without providing any address or name.

I am now thinking about using a dumbphone I bought from Amazon and that I previously used my primary, "public" SIM card with (and would do so every once in a while). I  only plan on switching the phone on when I want to make phone calls or write a text, probably once every one or two weeks.

Will this compromise my anonymity? If yes, to what degree and who would be able to get to know my identity? Would it be enough to buy a new dumb phone and only use the new prepaid SIM with it?

Your Amazon purchased hardware provides identity information unique to the phone and unrelated to the SIM card.  You have linked the phone to yourself through that Amazon purchase and also via the previous use of that device with a SIM card with your identity.

The IMEI appears to be your main problem.  Please see details of identifiers here - http://developer.samsung.com/technical-doc/view.do?v=T000000103

Simply stated your scheme does not provide anonymity.


When connecting to internet through VPN what precautions should be taken? I've read this similar question and it has some very good information. Can a site that has personal information about you be accessed by another site to determine who you are/where you are? For example if I log into Facebook (let's pretend it has my real name and location) then I go to another website (for example a forum and post something bad about the government), even though my IP is hidden could anyone find out that I made the comment on the forum based on the fact I had logged into Facebook in the same browser session which has my personal info? The VPN service I use protects itself using shared IP addresses, how does this affect privacy?

What steps can I take to mitigate such a threat, if one exists?

Connecting thorugh a VPN does not provide anonymity. It just provides a different IP address. Any way in which you could otherwise be traced you still be traced.

If you want your VPN-redirected traffic to not be at all associated with your non-VPN-redirected traffic, then your best solution is to keep completely separate profiles for each use. The most complete way to do so is with two separate computers; the second most complete way is by using a separate OS on the same computer (also not that bad), and the third way is to separate out the browsers (not ideal, but less friction).

And then, of course, never do anything within the one profile that you do with the other. No shared accounts, no shared logins, no shared usage patterns, no shared anything. Don't even visit the sames sites.

Often when people's anonymous personae are tracked down (e.g. by a repressive government, etc.) and tied to a real-world person, it's by discovering patters in behavior, speech, timing, or other such side-channel details, or one one persona makes some reference to the other, or by both sharing some common offline characteristic (like the sound of your voice if someone talks to you). The more a given identity does, the more difficult it becomes for that identity to remain secret. The only safety (if there is any at all) is in keeping the anonymous persona sparse and very rarely encountered. It's an extraordinarily dangerous line to tread, so do so with the utmost caution.

Also, and here's a technical detail you don't want to forget: If a "content of interest" is seen by the government coming form a specific IP address, and YOU are seen connecting to a VPN at that same address... well then your secret is not so secret. If your only protection is a VPN, then you're not particularly protected.


Google Account Compromised - Possible Investigation? This morning, I've not been able to login to my Google Account.

Google says, my account has been compromised and I had to walk through account credentials recovery and verify (SMS to verify phone number, changing password)

Now, after securing my accounts again, is there any possible investigation?

I'm interested in:

Type of access (now saying unknown in activity log)
What data has been exposed during session
What settings was changed, if any ...

And I'm sure, that if anybody logged into my account, he didn't used his own computer, so the IP and location from activity log is kinda unhelpful.

Is there possibility of getting these informations?
And is it good idea to take some legal steps against the hacker, or it's unnecessary and/or impossible to take action?

The only thing you can do is take a look at the "Recent Activities".

You can find it by

clicking on the gear icon at top right of your Gmail page
then selecting Settings,
scrolling to the bottom of the subsequent screen and...
clicking the Details hyperlink at the bottom right, right beneath where it says something like, "Last activity in this account : xx hours ago".

When you click on the Details link, you'll have a list of all active current sessions for your Gmail account. You can close them by clicking the button, "Sign out all other Gmail web sessions".

You'll also find a table listing the last 10 access to your account. Try to find an IP address that doesn't belong to you, it might help. (But it's just an IP, and as you may know, this can be falsified :/).

That's the only thing you can investigate for sure.

But you can see if mails has been sent (look in the Sent folder, but maybe the attacker as deleted them, so look in the Trash folder. But again, maybe the attacker has deleted them for good).

You cannot exactly know what kind of information has been exposed (account password or access sent in your email, information regarding your contact such as email, telephone, etc, nor any settings that have been changed).

Now, I warmly recommend you to enable the two way authentication system from Google, in order to ensure an higher layer of security for your Gmail account.


Prove ownership of a GMail account Is there a way for a person to remotely and irrefutably demonstrate ownership of a Gmail email address? I've considered using DKIM signatures, but this has problems:

PGP Key Signing Robot DKIM Verified Emails

I've also considered using Google's OpenID or OAuth APIs, but I believe you can list other emails as your primary address in your Google account. Notably, the Google docs state: "The user's email address. This may not be unique and is not suitable for use as a primary key." While the API does report if the email is verified, it is not clear to me if verification is any more substantial than a simple email loop.
https://developers.google.com/identity/protocols/OpenIDConnect

I understand that there are very good reasons for Google to make it difficult to link emails to user accounts. However, it would be nice if a user could opt-into demonstrating this association.

Edit for clarification:
The context here is one of signing PGP keys or granting S/MIME certificates linked to the email. You want to be sure that the certificate you are signing was sent from someone with bonafide send/recv privileges, and not someone who forges a "from:" field, or who sits in the path between the signer's email provider and Google (the signee's email provider). Here, real-life identity doesn't matter. I don't care who someone is. I only care that the person making the request is also the person who has the username/password of the the claimed email account (or, I suppose, works for Google...). The purpose here is to bootstrap more secure forms of communication.

The argument here is that the standard email loop is insufficient. Email is prone to forgery and interception. But, there may be secure out of channel methods (E.g. OAuth or posting a public key to Google+). If nothing else, such an approach would provide additional evidence beyond the already ubiquitous email loop. Unfortunately, neither OAuth, nor Google+, nor YouTube comments, etc. can be reliably linked to an email address.

Following the ideas listed in comments above (thanks to Neil et al.) I found the Google Email transparency report:

http://www.google.com/transparencyreport/saferemail/?hl=en

This makes it very clear that Gmail>Gmail messaging is encrypted:

  Is email from Google users to other
  Google users encrypted in transit?

  Yes.  This includes Gmail, Google
  Apps and notifications from
  Google+.  That's why this report is
  focused on email deliveries where
  Google is only one of two providers
  involved.

So I think this solves the problem.

When receiving inbound email to a gmail account, one can check the DKIM signature to verify the email originated from a Google SMTP server (and thus was encrypted all the way to your gmail inbox)

In the outbound direction, you know your email originated from Google services, and thus will be encrypted all the way to the recipient's gmail inbox.

If someone can both send email and respond to a challenge sent via email (all within gmail), then I think this would be very compelling evidence of account ownership. Of course, a Google engineer could still inspect the messages at rest,  but I'm willing to accept such individuals as being in the class of "authorized to send/recv email from that email account."


Can you encrypt data using BCRYPT? Somebody else posted a question about ghostmail (https://www.ghostmail.com/crypto) and whether it looks valid. One of the things that triggered alarm bells for me was the sentence "Account Password (This is sent and stored encrypted using BCRYPT)". Do they simply not know the difference between hashing and encryption, or is there actually a way to encrypt a password with BCRYPT?

In that case, it is probably the password hashing function bcrypt, described by someone who does not make the difference between "hashing" and "encryption". Bad terminology, good function.

It must be said that there is an encryption tool called bcrypt as well, and which is known to do things very poorly, as far as encryption tools go. This is occasionally the source of great confusion.


Android with GAPPS, will Google know my IP even if I use a VPN? Since Play is a system app, will it know my through IP even if I use a VPN?
For that matter, wont my OS always know my true IP if I use a VPN, so unless I use a completely open source one it's probably leaking to Android or Windows for example?

Yes they will, if they care to.

Thanks to the total control on the device, they will know your devices innermost secrets and any of your secrets that you store on your device. The only possible exception is what happens in the baseband code (most baseband code is, I think, not part of Android). VPN functionality is outside baseband code.

Given Google's business model, I would imagine that they would care to (if not now, at some point).

When we choose a device and an OS, we implicitly "trust" the vendors of the device, key device-components, the OS and key OS-components.

Aside: It's not something I care to ruminate about since it rarely ever boosts my spirits. :)


Known Password Lengths and security considerations Many people wil often brag about the length of their password, like "yeah nobody is ever going to crack my password cause its 22 characters long." I was thinking, if you knew the exact length of their password, you could essentially lower the space and calculations necessary to brute force their password. My question is, does anyone know by how much does it reduce?

If I KNOW that a password is 22 characters in length, obviously you are not going to try any potential password that is not 22 characters in length.

tl;dr How much faster is it to crack a password if you know the exact char length?

If we assume that there are 128 possible characters in a password (2^7), then there are 2^154 possible 22 character passwords.

There are 2^147 + 2^140 + ... shorter passwords, which is pretty much the same as 2^147. So you have to do 1/128th less work if you know it's 22 characters and so don't have to try all the 1-21 character passwords first -- less than 1% less work, and not really significant.


Securing online SQL database and server I am trying to build a big project but lack the knowledge of security of servers and SQL. So, please help me by telling what necessary steps should i take.

Block all remote access :- I have heard that through firewall you can block all the remote users to connect your server unless you have allowed a specific IP to access the server (by adding a rule to firewall). Will this be enough to keep hackers away?
If a SQL user is only given GRANT EXEC rights will he be able to do anything except run the store procedures?
Should i go for Microsoft or Linux based OS : I have heard linux based I/O is very fast that is necessary for my application but is it more secure as compared to Microsoft?

Please feel free to correct me wherever i am going wrong as i am a newbie  .

Thanks in advance

For securing a server you can follow the TCP/IP Model for trying to have the most secured system possible.

With this model you will apply the principe of secure in depth and you will apply a secured principe on each layer of the model.

Example:
If your SQL server talk with only a few servers in the same local network you can do a static ARP table with each server.

To protect your layer 3 and 4 (protocol IP and TCP), you will apply firewall rules like this :

# MYSQL FROM WEB SERVERS
-A INPUT -s <ip source> -d <ip destination> -i eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 3306 -j ACCEPT
-A OUTPUT -s <ip source> -d <ip destination> -o eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 3306 -j ACCEPT

After, you will apply secured rules on your SQL server :

create users with appropriate rights on the DBs don't connect with root credentials, create a user per db and all others secured principes specific to your SQL server
secure your server (the OS) physically and logically

And finally, you will be aware to secure the applications (if you can) which connect to your SQL server.

With all of that, you have a starter point to begin to secure your system.


extracting JSESSIONID from document.cookie I was trying cookie stealing on a java and spring based web application.
Normally, a cookie can be obtained through <script>alert(document.cookie)</script>,
but in the above code, cookie is not alerted.

Burpsuite and tamperdata tools are showing this cookie: jsessionid=XXXXXXX..XXX

Is there any way to catch cookies client-side through javascript?

You can read the values of cookies using document.cookie or other client side solutions only if that particular cookie is not flagged as HttpOnly (assuming the browser you're using supports this flag).


What useful things can I do with the html5 "keygen" element? There's a new* keygen element in the html5 spec. It's supported in major browsers excepting Internet Explorer and Safari.

Here's what it looks like:

<form action="processkey.cgi" method="post" enctype="multipart/form-data">

<keygen name="key">

<input type=submit value="Submit key...">

</form>

The current implementations only support RSA as the keytype attribute.

Now my question, what useful things can I do with it? What's it for?

*: not really

The obvious usage is client authentication. It can be used to improve security in combination with a passphrase or smartcard, or to be a convenient replacement for entering a password.

The WebID single sign on protocol is an interesting proposal in this context.

The main issue with client certificates is that it is bound to the browser. So if you are on another computer, you don't have access to them unless you took precautions.


Getting Operating System Username using MySQL SQLi Suppose I have a website which has SQL injection vulnerability and I got the database schema etc. Is there any means by which I can get the operating system username or the SSH username?

Asking from hardening purpose

Depends on the permissions given to the database user who you are acting as. If they have command execution privileges, it would be possible to use those to run a command such as id. Without that privilege, though, it is not supposed to be possible, but could be if the MySQL user was also a valid system user. In that case, it is possible to obtain the MySQL user through the user() function, which could then be used on the system, although these would not be the same entity (e.g. they could have distinct passwords)


How to lure a Hacker? I am suspecting someone unauthorized is trying to or already in the network trying to get information on some data that we have. How can I lure this person to a "Honeypot" and gather information while they are connected to the network, and record the intrusions to better prosecute them for their doing.

If they are already in your network, just adding a honeypot may or may not be effective - you don't know what they already know of your network.

Do they know the IP ranges for HR, finance, data storage systems etc?
Do they have access to your change management system and would spot a new addition to the network?
Have they already backdoored the servers with the data they want?
Have they already got the information they need?

At this stage if the data is important, you may find it more useful to change access and remove them from your network, rather than try and track them.

Alternatively, if you know where this important data is, you don't need a honeypot - what you need is to closely monitor all activity and see whether any unusual connections are being made.

What has inspired your suspicions? If it was seeing something odd on your network logs, that would be a good place to start.

Generally, honeypots are useful before an intrusion, as they stop or slow an intruder before they get to your data, giving you a chance to identify or block them.


Where is the identification process when I use a key fob to unlock a door I can understand that typing my user name on the computer is "identification" and providing the password is "authentication" but when I use a smart card or a key fob I see no identification taking place?

This really depends on the system.  Simple key fobs don't do identification -- your identity is simply "someone who is authorized to open the door".  More sophisticated systems will have your identity programmed into the card or fob, so that both identity and authentication are established during the unlocking process.


IN OAuth 2.0, how is the client secret supposed to be kept secret? Using most OAuth 2.0 flows, a client application can identify itself to the authorization server by means of a "client id" and "client secret."

The OAuth 2 specification says that the client secret should indeed be kept secret.

However, if the client secret is inside of the application, then it's not secret - someone can use a debugger, disassembler, etc to view it.

So I am not sure the effectiveness and/or purpose of this client secret. Furthermore, are there any recommendations for securing a client secret on a client under the control of the general populace? The purpose here is to establish some form of trust between the client application and the Authorization server, independent of the resource owner (user).

Finally, what is the difference between using an OAuth flow without a client secret vs. using one with a client secret and not keeping that "client secret" actually secret?

OAuth2 specification defines two types of clients

   confidential
      Clients capable of maintaining the confidentiality of their
      credentials (e.g., client implemented on a secure server with
      restricted access to the client credentials), or capable of secure
      client authentication using other means.

   public
      Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.

And the use client secret are applicable only to confidential clients.

So basically You use it only when it can reside safely on secure server - and not in case of rich client (desktop, mobile, javascript in browser).

The purpose of the client secret is to prevent impersonation of the client. As you noticed without it anyone can extract credentials from end user application and perform OAuth flows on his own. But if the secret is safe server side - then one can not complete flow and obtain token.

As for using client secrets in client under the control of the general populace my recommendation is to don't use it at all as it adds nothing in terms of security.


Scope of PCI DSS regarding CVV According to PCI SSC, you can hold onto a CVV and other sensitive authentication data until authorization has occurred. In other words, the restriction on storing sensitive authentication data applies to post authentication/processing storage.

Are the machines that the CVV is stored on until authorization in scope?

Yes, the machines store, process, or transmit cardholder information (CHD) and/or sensitive authentication data (SAD), therefore they are in scope.


Single File Encryption in a Windows Environment Would it be correct to assume that encrypting a single file in a Windows environment, for example a simple text file containing login credentials for a variety of accounts, is inherently insecure?

It is my understanding that on most Windows systems, the creation of temporary files, caches and automatic backups means that it is likely that an unencrypted copy would exist somewhere on the system.

To put things concisely, what are the best practices for single file encryption on a Windows system, (if they exist.)

Your understanding is, indeed, correct.

Most probably you have a copy of that file on your system now. After you encrypt it, you'll either have to remove the unencrypted version yourself, or the encryption application will do that for you. As far as I know, there's no 100% way to delete a file and be sure that it's gone along with any evidence of its existence.

You have 3 options:

Search and destroy: Learn about all the places in which your file might have existed. This is not just about the temp directories and caches, this means down to the sector-level and effectively destroying the data by overwriting it. While plausible, I'd say it's practically impossible.
The alien approach: Encrypt the file on a different computer, copy the encrypted file to the intended storage place, then physically destroy the hard drive on the computer used for encryption. As long as you don't open the file (because once you open it, you'll run into the risk of leaking an unencrypted copy with caching, saving temporary files, accidental backup, etc...) Possible, but silly.
Full disk encryption: This is, by far, the most secure option. While, like anything in security, not 100% secure, it's your best option. I'd recommend some industry-standard application like TrueCrypt.


Reply to a spoofed SMS message If my phone number is (212)555-1212 and Bob spoofs my number vias SMS to Alice, will Alice's reply be sent to Bob, me or both?

EDIT: The concern is that the spoof prompts Alice to disclose information that Bob should not have.

Sent to you. Bob is simply spoofing your number not replacing/sharing it with you on the phone network. He can send on your behalf but not (as far as I know, or at least as easily) receive on your behalf.

EDIT: The only way this appears to be possible in such a way that Bob spoofs a number and can send and receive messages on the spoofed number is with much more unique software that generates "virtual SIM's" (as they called them) using fake, un-registered numbers.

Example of send and receive on spoofed number service using fake number.

The more common SMS spoofing in-which the spoof'er piggy-backs off a real number, they can only send not receive as all they are doing is manipulating the SMS headers.

A couple resources I found that cover this:

Guy strangely receiving phone calls and SMS complaints from people saying he called them when he did not.

Q/A site where some asked about a semi-related question.

Sorry about lacking technical quality in these resources, this is not a very well formally documented "attack" since it appears every service that does SMS spoofing does it a little different than the last.


Internet connection for POS of a Third Part From time to time, our premises and infrastructure is rented temporally for some conventions/meetings. One of these meetings requires an ordinary POS which would require a phone line or internet broadband connection to connect to payment gateway.

My concern is, what would be our responsibility as owners of IT infrastructure that is being borrowed for this POS? and how can I protect ourselves from any incident related to cards transactions through that POS?

Communication from the POS to the payment gateway should be encrypted. You do not have any access to the encryption keys. Hence it is impossible for you to get access to any card holder data.

Even if the traffic is not encrypted, those responsible for the POS would have to require you to provide a PCI DSS compliant network, for you to have any responsibility.

If card holder data is stolen, an investigation will try to find out where the data were stolen. If they're able to find a CPP (common point of purchase), and that the data were actually stolen from that merchant, the card brands will hold the acquiring bank responsible. Depending on the legal agreement between the merchant and the acquiring bank, the acquirer might fine the merchant.

Hope that helps.


Can OTP be implemented without 2FA? Say we have a system where we register users by a username and a phone number, could said system authenticate the user purely based on his username and an OTP sent to his phone number (assuming that implementation cost isn't a factor)? How secure would this be?

It would be as secure as the phone and the token transfer is. I.e. if the user looses the phone or if the phone gets compromised by malware or if the user displays incoming messages on the lock screen so that others can see it too or if someone can capture the SMS (or whatever you use to send) then the you've lost.
Insofar it is similar to sending the token per email and hoping that only the user has access to the account and that nobody can sniff the transport of the mail.


How are man-in-the-middle attacks actually implemented? For research purposes.

I'm wondering, in a high level way, how MITM attacks are actually done in the real world.

So over the internet the client talks to the server, or one person emails the other, and basically all that is happening is that packets of information are being send from A to B, right? My question is, what are the methods for an attacker to get hold of the communications mid transit, over the internet, and attack as a MITM?

The adversary can be NSA or a local enthusiast in a coffee shop. I just want to know a list of the different methods a MITM attacker can actually intercept communications and act as a MITM. Maybe listing some software as well, eg., explaining how something like Wireshark actually works.

Many thanks for the help.

edit: I don't think my question needs is so broad you have to close it. i just want to know the different techniques for being a man-in-the-middle. Literally, if Alice sends emails to Bob, how does Eve spy on this connection?

There are a large number of ways you could MitM on the internet, but it is so much more easier and reliable if on the same network (in my opinion).

The way I would do it over the web is trying to use a service someone has connected to (a website, application, proxy) the proxy is the most dangerous one as you control their traffic routing, which means you can serve up false https certs decode and be the man in the middle. or just generally mess with them.

a victim needs a certain level of understanding (none basically) in order to fall for such a weak attack.

when within a home network its alot more fun, inject the victim and router with arps and force control, rather than waiting for them to fall in your trap.

network = hunter like a tiger forcing, chasing your pray.
internet = hunter like a spider, waiting for the the pray to fall in your trap.


Custom Authentication in a RESTful API - Will this work? I was just wondering if this would be a reasonable way to write a custom authentication method for a RESTful API. It seems moderately secure, but perhaps I'm way wrong here.

1) Email and Password are sent over HTTPS to my server.

2) Server stores the email, and runs the password through a SHA512 hash with a 256 bit random salt. The hashed and salted password is stored in the database.

So now we have:

email = email@example.com

password = OHqhuewQclakufEjUbZMbowJKEGcvEBz,51c6a3cb58e10754f76e334de064a9dede7875141e1ce0233e3ff14fd7be98a4d5b8fc1c5ab871cb3b1d6b0c9f8073bc3558308511fc4fd6bd049aed5e58a9a4

3) Generate a random token with a lifetime (very random and large), store it the database, and then link that random token to that specific authenticated user.

4) I send the token back to the client through HTTPS (web, Android, or iOS), whereby it's stored in cookies or SharedPrefs or what have you.

5) Now, the client sends the token with every request. The server can then check the cached token value with the one it's receiving each time to make sure that the server always knows who's making requests.

Does this seem reasonable and secure? The issue I think that arises here is if the tokens database ever becomes compromised. Is there perhaps anyway to toughen that one part up?

Seems reasonable if step 5 is also done via HTTPS. As for what to do if you suspect the tokens have been compromised, you could store an ExpirationDate for each token and force users to reauthenticate after the token has expired. Upon suspecting a breach, just expire all the tokens immediately.


Securing elasticsearch behind a reverse proxy I intend to run an Elasticsearch index to store a persistent copy of data retrieved from an external service. My plan is to host the Elasticsearch index on AWS, and have it listen on 127.0.0.1 only. I was then intending to use a reverse proxy (nginx) to only allow search-type requests, and reject any others (e.g., updates, cluster management/stats, etc).

As I understand it, I could then do all updates locally on the box itself, and the reverse proxy would be enough security to prevent someone stomping all over my data.

So, my question is this: would a simple reverse proxy allowing/denying access based on URI be secure? What problems could I face with regards to malicious editing of data? Are there attack vectors on such a setup that I have not considered?

Note: I intend to tighten the firewall to only allow access to the proxy port, etc. The focus of this question is on the security of the reverse-proxy idea!

Reverse proxy is one way to do it.  There are some other plugins that you could put on your elasticsearch cluster that are a bit more robust:

Shield - Commercial license only, elastic.co

  Shield is a plugin for Elasticsearch that enables you to easily secure
  a cluster. With Shield, you can password-protect your data as well as
  implement more advanced security measures such as encrypting
  communications, role-based access control, IP filtering, and auditing.
  This guide describes how to install Shield, configure the security
  features you need, and interact with your secured cluster.

SearchGuard - Commercial and Free licenses, from floragunn

  Search Guard offers the same functionality as Shield, adds additional
  features on top, at a much lower price point and with a more flexible
  licensing schema. Additional features include:

  OpenSSL support Kerberos support HTTP Proxy Authentication support
  JSON Web token support Source code available – run your own security
  audits Licenses for Search Guard are based on production clusters, not
  nodes. That means that you can scale your cluster up- and down as
  necessary, without affecting the license costs. Development-,
  staging-, integration- and QA/AUT-systems are covered by the license
  as well at no additional cost.


What are the compatibility implications of generating a new TLS key? The guide I'm following says to use openssl genrsa to generate a TLS key, which I did. I've changed the CSR generation command to use SHA256 instead of SHA1, but I'm still not sure if this is the optimal solution.

The oldest clients I would like to support are Windows XP with SP3 (cries)  and Android 2.3 (preferably, but I don't really need this), or if that causes serious pain, Android 4.0.

What is the optimal key type for this? I'm assuming RSA, but ECDSA keys look nice too (except for compat problems).

Everybody uses RSA. If you stick to RSA, you certificate should be acceptable everywhere. Use a 2048-bit key size. ECDSA is nifty and very hipster, but won't work everywhere yet.

A RSA key is a RSA key. However, a certificate is also a signed object, and a signature algorithm begins with some hashing. Thus, a certificate will contain references to a hash function. Some modern browsers have apparently decided to scream and wail and shout when they see "SHA-1" in a certificate; therefore, to avoid dropping out of fashion, you need to use SHA-256. This should work on XP since SP3 (but not before). Take care that this is about the signature on the certificate, so really it is the problem of the Certification Authority that signs your certificate.

Whether you sign your certificate request with SHA-1 or SHA-256 as supporting hash function, should not matter. The CA extracts the public key from your request, pushes it in the new certificate, and then will use SHA-1 or SHA-256 depending on its configuration, regardless of what you used yourself to sign the request. At least that is how CA are supposed to work; some CA do weird things at times.


How to protect Linux partition from access from Windows partition? In a dual-boot environment (windows? and linux mint 15) What would be best best way to prevent access to the linux partition(s) when the system is booted into windows 7?

The goal would be to prevent windows malware from modifying the contents of the linux partitions while the system is booted in windows.

Both systems are installed on the same physical drive.

Best option is just to encrypt the Linux partition, e.g. with LUKS. That way the Windows 7 partition can't actually access any of the data on the other partition. Technically it can still read and write to the partition (there's no way to prevent this) but the data it sees is all encrypted.