Can robots.txt for your face be made effective? As Google Glass slowly starts shipping, I've recently came across an article on stopthecyborgs.org that mirrors my anxieties that Google Glass currently does not feature a robots.txt for my face. It is absurd that while I can protect my website's privacy, as it currently stands, I cannot do this with my face anymore.

Personally, I would like any attempt-to-recognize-my-face to be an opt-in feature, not an opt-out feature.  From a privacy stand-point, the glass should only transmit any data about people if it recognizes an 'OK you can post me' sign on them, before sending any transmission. It poses a much greater security risk if it is an opt-out feature than if it's opt-in. But currently, there are no provisions at all, for either opt-in or opt-out, that I know of.

If Google Glass gets widely adopted, this effectively opens up the possibility for a total corporate surveillance (and if CISPA and similar attempts are not stopped, possibly also opens up to US governmental surveillance).

As some people resist the idea that eliminating privacy should be a good thing, the question is if a robots.txt functionality can be implemented that protects privacy against the glass and it's future, more miniature, competitors.

As some countries are already trying to enforce policies to forbid to hide your face with a scarf, this becomes a problematic task to do on your own, especially in summer.

Are there any attempts to research if people are aware of or troubled by this threat?
Does Google have a public stand-point over this matter?
Has anyone studied or proposed potential technical (or other) solutions to this problem?

Although Google Glass makes the issue look whole new and technological, this is actually very old news. To make it short, there is no privacy in public places.

Indeed, whenever you go out on the street, you show your face to the World at large, opening up the possibility that any bystander recognizes you. This is by design. That's how civilization in general works. To make it more precise, individuals are, by nature, able to conceive their own plans and act on their own (some people would call it free will). In a society, people must cooperate to handle shared resources, be it food, water, or simple space. Laws define the boundary of free actions, but enforcing laws is expensive; there just are not enough law enforcement agents to verify that everybody acts lawfully (including the agents themselves). Society can remain lawful only because most people are basically honest and law-abiding. Why are most people honest ? Mostly because they were educated that way, and kept under, let's say, continuous formation, by social pressure, which in turns relies heavily on non-anonymity.

It is depressing, but well recognized, that when people feel that they are anonymous, many of them will begin to act as jerks (not all of them, perhaps not even most of them, but sufficiently many to become a big issue). In pre-urban societies, there is no privacy. For instance, consider how indigenous North Americans lived before the arrival of Europeans: they lodged in longhouses, which are communal buildings, meaning that in order to be alone, they had to walk away from the village. Later, when housing could provide some one-person rooms, it became possible to have a bit of privacy -- but not much. In an 18th century New England village, everybody knew everybody, and the people as a whole felt entitled to have strong moral opinions on what everybody else does at all times. Gossip was not only tolerated, but actually encouraged, in that it allowed moral pressure to be exerted.

Later times have brought the luxury of privacy, mostly because of the sheer size of cities: it is no longer possible to know everybody and be known by everybody, so you keep on meeting total strangers who you do not recognize, and who do not recognize you. Space is separated between public space, morally shared by everybody, and private space, claimed to be "his own" by some individual. Laws theoretically apply to everybody regardless of where they are, but some laws are specific to the public space. This includes, of course, laws about decent clothing (you can be naked in your home, not in the street), but also, and that's where I was going, about concealing your identity.

A "robots.txt for your face" is called a mask. That's hardly new technology. And there are laws about masks. That page lists laws in various US states; many other countries in the World have similar regulations, and they got some revival recently, in some European countries which passed bans against integral Muslim veils in public areas (e.g. in Belgium). Although these recent laws were fueled by some controversial undertones (some people are against Islam in general; some people view it as a tool to emancipate women;...), the official and theoretical core of these laws is the basic principle which I have alluded to above: in public areas, you shall not be anonymous (potentially). This means that while there is no obligation to shout your name, address and blood type every ten seconds, it should still be possible for bystanders to see your face and be able to recognize you later on, should an inquest about some crimes be run. Late actuality in Boston has shown this principle at work: in times of crises, witnesses (and amateur videos and photos) can be used to identify suspects.

Whether all of this is morally good or not is an open debate; but, right now, continued operation of society relies on this potential non-anonymity of citizens when in public areas. Changing that is akin to people all wearing masks when going outside. This is a revolution of all social structures. Controlled experiments of that kind have been performed for centuries; these are called carnivals: valves to evacuate social pressure overflows, under strong boundaries to avoid the whole thing degenerating into chaos. It is conceivable that a society with strong anonymity in public places is possible, but it would still be a far-reaching change from today's state of affairs.

The Internet brings on a twist on all this. Indeed, on the Internet, people's identity works as a whitelist, not a blacklist. A mask is a blacklist: it blocks some specific features of your identity. On the other hand, on the Internet you show only that which you are willing to show. One billion Facebook users are apparently willing to show a lot (and, to their own surprise, a lot more than what they actually expected), but it is still mostly a conscious push effort.

This yields the pervasive feeling that Internet provides anonymity by default. This apparent automatic privacy, and the lack of biological feedback when you interact with other people over the Internet (typed text is not as rich as voice modulation and facial expressions), tends do disinhibit people. A cursory look at comments on Youtube will show that the Internet seems full of jerks... which is an illustration of the possible clash between "civilized society" and "anonymity". Being anonymous is not bad in itself, but it opens the possibility for people to show how much disrespectful they are, and, for some of them, that "how much" can reach high summits.

When you mix the Internet and social behaviour, you get interesting clashes. Disparaging comments in public forums, abrupt discovery of the lack of assumed privacy of your Facebook data, and Google Glass, are three facets of that kind of clash. Google Glass is not qualitatively different from hiring a private detective, to identify every people you encounter in the street; but it is much cheaper to the point that it makes it possible even in big urban societies. This may force us to reconsider some social rules.

For instance, some people (like you, apparently) react to the possibilities offered by Google Glass by looking for a mask -- which laws do not permit (depending on the country, of course; in Japan, they allow wearing masks, and many people do -- but they have their own ways with social pressure).

Ultimately, Google Glass brings us back to the "Village" stage, where everybody knows everybody. So it is not new; we have experience about what that means. And it is not specific to Google Glass either.

There has not been much rational effort toward individual privacy. Most of it came as an unexpected boon from the size of cities. In recent centuries, the way to escape the stifling ambiance of small villages has been to move to either isolated places where you could be all alone, or to crowded places like big cities. I don't expect it to change much. If we consider the example of social networks, we will see that most people don't really care about their privacy with regards to people they don't know. People post their photos on Facebook for the benefit of their friends and acquaintances, and are not overly worried that the whole World can see them as well. What worries people is what people they know will think about it (e.g. see the panic spread on the face of a college student when he learns that his dear mother has decided to "go on the Internet" and will thus gain access to all the photos demonstrating how the said student organizes his evening homework).

Indifference is the new "big city" for anonymity. My guess is that this is how society will react to privacy issues raised by Google Glass and similar technologies. In the (recent) past, you had privacy by virtue of nobody being able to associate your name with your face. In the future, you will have privacy by:

assuming that complete strangers do not care about associating your name with your face;
yourself not caring about whatever associations complete strangers can come up with.

It is up to you to decide whether you will be elated or depressed at this prospect.


Security concerns with pre-pay system I am looking at setting up a pre-pay system for the food retail industry. Retailers will be able to generate random 10 digit codes and supply these to customers to enter into an app to gain the value assigned to the code. My database is similar to the following

  +----+-----------+-------------+-----------+-------+
  | ID | code      | activated   | user      | value |
  +----+-----------+-------------+-----------+-------+
  |  1 | iijwd923j |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  2 | aidwd923j |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  3 | jksjwdijk |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  4 | jiejdedow |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  5 | iwqjdwdqd |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+

Lots of columns omitted as they aren't required here. When the retailer generates the code it is hashed and salted before going into the database. When the code is entered into the app their id is assigned to the code and it is activated. The retailer can also activate or deactivate the code should codes go 'missing'. This is done by the index.

Do you foresee any security issues here?

The basic principle looks pretty good.

A few thoughts:

When a token is used, don't delete it. Mark it as used, store a "used" date, and delete old tokens after 6 months. Otherwise the same token serial number might be re-created by accident, because the system has no record of it ever existing.
Can any single instance of this prepay system run across multiple physical sites? If so, you're going to have to take synchronisation of data into account, otherwise a user might re-use their token on another machine.
If each vendor system needs to communicate to some kind of base station, they'll need a secure way of doing so. Physical security in the way of an ethernet cable is OK in small stores, but it pays to be secure - make sure you implement SSL for such traffic, with client and server certificates installed on the appropriate machines.
You'll probably want to tie each code to a specific vendor, whose ID is randomly generated. Otherwise a store assistant could print off a bunch of codes and go shopping at another vendor that uses your system. Make sure the ID generation uses a high quality random number generator!
Make sure appropriate security provisions are taken for the system that runs the database. Lock the machine down with group policy, enable and properly configure Windows Firewall, install an anti-malware package (Microsoft Security Essentials is good if you don't like the idea of running 3rd party solutions), etc.
Properly configure your database server software. This includes making sure that it only listens locally (don't bind to 0.0.0.0) or only uses local pipes if possible. You should also use strong credentials for the server, and minimal privileges. If at all feasible, reduce all queries down to stored procedures and only allow the account to access those procedures - give it no privilege on any table.
Make sure you implement an auditing system that logs the cashier that performed the transaction, the time, the order ID that it belonged to, the total price of the transaction at the time (product prices change!), the store ID, and the plaintext code that was used. You don't need to secure the code at this point - it's useless.
In the case of a refund where the customer is to be given back their token, generate a new token. Don't ever re-use the old token number.


Can I get SSL certificates for my OpenPGP key? How can I use letsencrypt to get a signed public key for use with OpenPGP? So I can prove in court the key is mine etc., and not have to rely on the OpenPGP web of trust.

How can I use letsencrypt to get a signed public key for use with OpenPGP?

This is not possible for several reasons.

letsencrypt does not Verify Idenitity

  So I can prove in court the key is mine [...]

letsencrypt only verifies domain ownership, with other words whether you have control over the domain. They do not verify any personal information.

Server and Client Certificates

OpenPGP does not really know the concept of server certificates, at least not in a standardized way. At the same time, letsencrypt only issues server certificates. They cannot validate user IDs.

X.509 and OpenPGP are not Compatible

letsencrypt issues X.509 certificates, as used for HTTPs. While both make use of the same cryptographic algorithms, neither the X.509 key format is comptaible with the OpenPGP key format, nor are their signatures (certifications). The problem already starts with how the entities identifying keys (in both cases: fingerprints) are calculated.

While it is well possible to extract the RSA keys (with other words, the numbers used as input for the algorithms), the same RSA keys would have different incompatible representations and formats.

Trust Systems and Certification Authorities

X.509 and OpenPGP have different trust systems. X.509 has a hierarchical approach, with a (some people say too large) set of trusted root certification authorities (recursively) signing both other certification authorities and individuals. The result forms a kind of trust tree.

OpenPGP uses another structure, the more general graph ("web of trust"). There is no central trust instance but your own key, and you have to verify and trust other's keys before. You can somewhat compare this to manually choose, installing and trusting the root certificates into your system's (browser's) trust store before being able to verify any certificates.

  [...] and not have to rely on the OpenPGP web of trust.

You can very well map the hierarchical trust system into OpenPGP, and there indeed are certification authorities in the OpenPGP world: CAcert also signs OpenPGP keys, the German Heise Verlag does so in their "Krypto-Kampagne" (German website), and also in Germany you can get your key signed using the electronic features of the German identity card (German website).

This means still relying on the OpenPGP web of trust, but using certification authorities to "bootstrap trust". For example, everybody trusting CAcert will be able to verify your key based on their signature, without any further "web of trust work" to be performed.


Can you wipe a USB flash drive so securely that it's impossible to recover deleted files through forensic analysis? Internal SSD can be wiped with TRIM, but USB sticks are external SSD. They're apparently difficult to wipe securely enough to make forensic analysis of the device impossible. This question has been asked before, about 4 or 5 years ago and the information is probably outdated. Looking for up-to-date advice on how to securely wipe files on a USB from a bootable media.

Is it possible to have a setup that can securely wipe USB with TRIM? Anyone know of any programs that will securely shred files on USB, making them impossible to recover via forensic recovery software?

Unlikely. SSD/usbs have firmware that automatically shuffles the available storage to account for errors in sections of the flash storage. Its possible that your important files are now stored on a bit of flash that effectively does not exist in the eyes of the OS and therefore can not be securely wiped.

The easiest way to be fully sure that none of your data is recoverable is to use full disk encryption from the beginning. Without the key, the data on the drive is effectively random and useless. That way if you ever sell or lose your drive, no amount of analysis will get any data out of it as long as your key was secure.

I'm also not sure TRIM can actually be used to securely wipe drives but I will leave that up to someone who knows more about it.


Is asymmetric encryption vulnerable to man-in-the-middle attacks? I'm looking for ways to send private messages over a public channel, and in doing this I stumbled in asymmetric encryption, which is just perfect for what I was looking for at first - A and B communicate directly, over a public channel.

However, it is now my concern that the security of the message might be compromised by man-in-the-middle attacks of this kind.

  Alice and Bernard are computer users connected to the Internet. Alice uses a proxy, Paul, to connect to the Internet and send messages to Alice.
  Paul wishes to read communications between Alice and Bernard. So, when Alice attempts to send Bernard her public key, Paul stores it and forges a new one, also from "Alice", and sends it to Bernard. He does the same with Bernard.
  When Alice wants to send Bernard a message, she's actually sending it to Paul, who decrypts it, modifies it and sends it to Bernard.

Asymmetric encryption provides security for messages exchanged between Alice and Bob only insofar as Alice knows Bob's public key and Bob knows Alice's public key. Otherwise, attackers could publish fake public keys and, in effect, pose as Alice when talking to Bob and vice versa.

An historical view of the issue is the following: in older times (say, 50 years ago), Alice and Bob could have talked "securely" only if they knew an initial shared secret. If both Alice and Bob know a shared secret K, then they can use it to encrypt their messages and also to check their integrity (with a MAC). Encryption is against passive attackers (who try to learn the message contents) and MAC is against active attackers (who try to alter the message contents). For a complete secure flow, Alice and Bob would also have to include some sort of numbering in the messages, so that dropped, duplicated or reordered messages are detected.

An initial shared secret is usually hard to establish. Especially when there are more than two Alices and Bobs. If there are n people who must securely talk to each other (securely against external attackers but also against the n-2 other users), then there will be a need for n(n-1)/2 shared secrets, and each user will have to store n-1 secret values (one for each other user to which he may want to talk to).

Asymmetric cryptography makes the problem easier (but not easy). With public/private key pairs, each user stores one private key, and just needs to know the public keys of the other n-1 participants. Public keys are, as the name says, public. They can be shown to the whole world without any ill effect. Presumably, distributing public elements is easier than distributing secrets, because only active attackers are to be feared.

The analogy is that of the Wall. Imagine that there is, in some specific place (say, the central plaza of a town), a big wall made of marble. Everybody can come and look at the wall. On the wall are engraved the public keys of Alice, Bob, Charlie, Dave, Ebenezer,... so that everybody can learn these keys without fear of interference. The whole is guarded and only the official town engraver can add or remove or modify a public key on the wall; and he will engrave, say, Fred's public key only if Fred himself shows him the said key and some valid ID (driver's licence...).

A big wall can be inconvenient, especially for users who do not live in the town where the Wall is located. To allow for remote operation, a nice scheme has been designed: the official engraver is also given a camera, a printer, and a stamp. When the engraver has finished engraving a new public key, he takes a photo of it, prints it a few times, and signs them (with the official stamp). Now, if Alice sends to Bob such a photo, Bob may trust that he has a genuine copy of the part of the Wall which contains Alice's public key: we assume, here, that the engraver's stamp cannot be counterfeited. It is not a problem if some bad guy opens letters and sees that photo: it is public anyway. Making sure that the stamp cannot be counterfeited may prove troublesome, though.

Here comes the really nifty part, which turns this photo business into a complete public-key infrastructure. Instead of a stamp, the official engraver will use a digital signature: the engraver also has a public key, engraved on the Wall too. If Bob knows the engraver's public key, then he can verify any signature computed by the engraver over any photo. That way, by knowing a priori a single public key (the engraver's public key), he can make sure whether any given photo is genuine or not, allowing him to learn the public key of just any other user.

In normal PKI terminology, the photos are the certificates and the engraver is the Certification Authority. Bob must still start somewhere, i.e. know a public key, but only one (the "root") and for an unlimited number of users; it will even work for user's public which do not exist yet. In a full-blown PKI, there may be too many users for a single engraver to manage them all, in which case we can extend the principle with a Master of all Engravers who signs the public keys of subordinate engravers. The Master is then the "root CA" or "trust anchor", and the subordinate engravers are "intermediate CA". To avoid abuse, the photo of the public key for a subordinate engraver is duly marked as "this is the public key of someone who can act as engraver".

Ultimately, once the system with photos works, nobody actually comes to look at the Wall anymore. Only the photos and the signatures are used, and they are sufficient. We may then avoid building the Wall itself (marble is expensive, after all); the "engraver" simply writes down the public key on a piece of paper, duplicates it, and signs the copies directly.

The PKI model explained above is what is done on the Web, with X.509 certificates. Each Web browser (or operating system) knows a priori a few dozens of root public keys, from which the validity of the certificates for the millions of existing HTTPS-powered Web site can be ascertained by verifying the signatures on them. This is a very centralized model; it is called a hierarchical PKI.

Other models exist, in particular the Web of Trust. In the WoT, everybody can act as an "engraver". Since Bob cannot assume that every single user is as trustworthy and reliable as an official engraver, Bob will accept a given public key as being Alice's only if Alice can show many certificates for that key; i.e. Alice could convince Charlie, Dave and Ebenezer that a given key was indeed hers, and Bob happens to know the public keys of these three guys. In that sense, the WoT is more heuristic in nature than a hierarchical PKI. In fact, this is a matter of a definition of identity: in the Wall model, Alice is Alice because she was given an ID card from some "authority" (say, a central state); in the WoT, Alice is Alice because sufficiently many other people know her as "Alice".

The definition of identity is crucial. What does it mean, that Alice and Bob want to "talk securely" ? Bob wants to talk to the "real Bob" which means that she has a preexisting notion of who Bob is, and what makes Bob distinct from, say, Charlie. If Bob is a complete stranger, then it makes no sense to want to talk to Bob exclusively; there is no "Bob" distinct from "Charlie". This notion of identity is what will dictate what kind of PKI you need. If identities come from a centralized structure, then a hierarchical PKI is appropriate. If identities come from mob approval, then a WoT is the right model.

Or maybe you don't want a PKI at all, after all. For instance, Bob may be, from Alice point of view, "the guy who knows the secret password P". Then we are back to the historical setup which predates asymmetric cryptography. We can still do some advanced science, though. Passwords are poor keys because they tend to be guessable through what is known as a dictionary attack. If Alice and Bob just use P as encryption key, then spies may record the message, then try to decrypt them with potential passwords. In order to fix that issue, Password Authenticated Key Exchange algorithm can be used. With a PAKE protocol, Alice and Bob authenticate each other with regards to their common knowledge of P, but a sufficient amount of asymmetric cryptography was injected in the protocol to prevent spies from learning any data which they could use to test a potential password. If Charlie wants to try a potential password P', then he will have to talk to Alice (posing as a fake Bob) or to Bob (posing as a fake Alice), and he will have to do it again for each P' he wants to test. Surely, after a few such failed attempts, Alice and/or Bob will notice that something is amiss. This is how PAKE protocols allow the secure use of low-entropy secrets (i.e. passwords) without needing any kind of PKI.


Isn't RBAC just an implementation of MAC? So I've been reading up on MAC vs DAC vs RBAC and there is something which I do not understand. Everywhere you read, it tells you that these types are different (disjoint) but isn't RBAC just a type (implementation) of MAC?

From what I gather, MAC is a generic control policy in which the administrator manages all access rights. In RBAC, rights are assigned to roles but ultimately roles are still managed by the administrator right? The admin decides which user has which role and he is also the one which can change permission for all roles so ultimately the administrator is still the one managing all access rights, correct?

Also I've watched this video on YouTube Implementing MAC Example, and this model worked as such: data was classified into categories according to its sensitivity (i.e. top secret, secret, confidential etc) and the company was divided into departments. The account control was implemented as a set of labels L = (sensitivity level, department) which meant that users from that department have rights on files of that sensitivity level. Very basic example, I know, but I don't understand how this is different from RBAC. The department of a user is basically his role and the labels show what rights each of the departments has. Honestly if I were to be asked "what type of account control was presented in the video" I would answer RBAC but the video claims it presents MAC.

Can someone shed some light on precisely what differs between the two and why one isn't just a subcategory of the other?

Thanks in advance.

Think of the two models as accomplishing similar objectives, but through a different perspective. What's even more confusing is that in practice they may be combined.

Think of MAC like a simplified version of the US Government classification system -- you have Confidential, Secret, Top Secret for example.  If one only has a Confidential clearance, they may not access secret or top secret, but when one has a Top Secret clearance they may receive access to documents on all levels.  One key element of MAC though is that it's handled centrally and enforced by the computer system -- so users, sysadmins etc cannot escalate privileges on their own without approval by the central authority of the organization.

In contrast, a role-based access control would be more granular.  For example, if using role-based access control, someone working for the US Government in Human Relations would have access to memos, dossiers and other information on employees as their position requires.  However, they wouldn't have access to other information at the same classification level that is outside of their scope of work -- like, financials for equipment purchases.  So, role-based access control limits the scope of information.

The systems can be combined in practice, and many systems may have a combination of role-based and mandatory-access controls.  However, RBAC is seen as usually more suited for commercial environments while MAC is more associated with sensitive environments such as defense.

That said, in terms of the video you identify, the question is tricky.  However, the fact it contains both sensitivity level and department means it's RBAC -- as department is involved (that's a role).  Because sensitivity level is involved, then it's not DAC (discretionary access control) but rather MAC being implemented in an RBAC fashion.


Automatic Password Reset - is it a good idea? I am designing a new web application. Each user of the application has an account bound to his e-mail address. The e-mail address is also the username of the user's account.

Users log in using their e-mail address and PIN. The problem is I cannot force users to use passwords that are strong enough; 6-digit PIN is the strongest password they are able to enter when logging in because of some stupid hardware restriction.

I am thinking of resetting the PIN to a random one after specified number of failed attempts as a countermeasure against brute force attacks. This new PIN would be sent to the registered e-mail address.

Is it a good, or a bad idea? Does it provide any extra safety? How much safer is 6-digit PIN which is reset after each 20 failures than a plain 6-digit PIN (how many more guesses do I need on average)?

Are there any other pitfalls I should think about when implementing this automatic reset feature?

Theres no problem with this, but a better solution in your case is to use a random "hardware PIN" used only when communicating with the "stupid hardware", that is stored inside account, possibly encrypted with a hash of the user's password. (and to verify password at login, use hash(hash()) of password). Thus you can use a normal password for the web frontend, and thus does not need to enforce hard try limits. (instead you can enforce a timed try limit)


If a server only opens port 22 and 80, do we only have those two ways to hack it? If a Linux server only open SSH port 22 and HTTP port 80, must we go through one of these two ports to hack into server from the internet?

Not really. I'd say it depends on your threat model. There might be other threats that don't need to use those ports in order to compromise your server. The first example that I can think of right now is a supply-chain attack. When you update any software on your server, if the updated software has been compromised by a supply-chain attack, your server will get infected. Or if you install example-program by mistake instead of example_program (note the hyphen instead of the underscore), and example-program was malicious and had been given that name on purpose to confuse you, then your server will be compromised. I think something like this happened recently... oh, yesterday (Bitcoin stealing apps in Ruby repository). Other examples? Maybe some MITM in the outgoing connections from your server. Then let's not forget about phishing, or anything involving social engineer.

So to be precise, if you asked me "in general, can I only be hacked by a remote threat through open ports?", my answer would be no. Whether some threats are likely or not though, depends on your threat model, which in turn depends on what your server does, how you are managing it, who you are, etc.


How to set up security on my phone I am using my friends Wi-Fi and I don't want anyone else using the same Wi-Fi to be able to see what I am doing on my phone. How do I put up some kind of  security so that people in the same network won't be able see what i am sending and receiving?

I don't want my personal business being looked at by someone else. This person has done it before.

What should I do?

We can't tell what your friend is doing to see the business on your phone, so I'll create a straw man and assume one of three things is happening:

Assumption 1) You are running a jailbroken phone / Android wherein your friend put applications on your phone. In that case, (s)he may have access to your phone even if you aren't on the Wi-Fi. If this is the case (that you are running a jailbroken phone or a phone with cracked software), you should factory reset and never download untrusted applications. It could be that your friend is messing with you and you trusted software that you should not have trusted.

Assumption 2) Your friend is monitoring the router traffic. If this is the case, (s)he will be able to see what sites you visit and, if you visit sites without transport layer security in place (like, banks or social media pages that don't have HTTPS), then your friend could sniff where you are going and what credentials you are sending along. This makes sense because you'll be using the router to send the traffic to the internet. Like Navi mentioned above, you can use a VPN service to encrypt your traffic. Then, even though your friend will sniff what's going through the router, (s)he won't be able to understand the sites or credentials. Advice here is to use a reputable, paid VPN service, as if you use a free VPN service you run the risk of further security issues.

Assumption 3) Your friend is messing with you and is looking over your shoulder, maybe with a camera in the room. In this case, don't do important stuff at the house because clearly this person is messing about with your privacy. Or search the room for a hidden camera and unplug it.

--

Assumption 3 is unlikely, but never underestimate shoulder surfing, as it's how ATM skimmers get pins.


PHP eval code sandbox break I noticed a heavily downvoted comment in here: http://php.net/manual/en/function.php-check-syntax.php

function eval_syntax($code)
{
    $braces = 0;
    $inString = 0;

    // We need to know if braces are correctly balanced.
    // This is not trivial due to variable interpolation
    // which occurs in heredoc, backticked and double quoted strings
    foreach (token_get_all('<?php ' . $code) as $token)
    {
        if (is_array($token))
        {
            switch ($token[0])
            {
            case T_CURLY_OPEN:
            case T_DOLLAR_OPEN_CURLY_BRACES:
            case T_START_HEREDOC: ++$inString; break;
            case T_END_HEREDOC:   --$inString; break;
            }
        }
        else if ($inString & 1)
        {
            switch ($token)
            {
            case '`':
            case '"': --$inString; break;
            }
        }
        else
        {
            switch ($token)
            {
            case '`':
            case '"': ++$inString; break;

            case '{': ++$braces; break;
            case '}':
                if ($inString) --$inString;
                else
                {
                    --$braces;
                    if ($braces < 0) return false;
                }

                break;
            }
        }
    }

    // If $braces is not zero, then we are sure that $code is broken.
    // We run it anyway in order to catch the error message and line number.

    // Else, if $braces are correctly balanced, then we can safely put
    // $code in a dead code sandbox to prevent its execution.
    // Note that without this sandbox, a function or class declaration inside
    // $code could throw a "Cannot redeclare" fatal error.

    echo "Braces: ".$braces."\r\n";
    $braces || $code = "if(0){{$code}\n}";

    if (false === eval($code)) {}
}

eval_syntax("file_put_contents('/home/yourname/Desktop/done.txt', 'OVERWRITTEN');");

I tried to bypass the code and lead to malicious user-input execution with eval, but I couldn't. I wonder why it got downvoted.

As you can see if curly brackets are not matching, it doesn't add the 'if(0){' . $code . '} and executes the user input as-is with mismatching curly brackets which will throw exception and won't really run.

If curly brackets are a match, it calls eval, but since its inside if {0} "sandbox", it doesn't do anything. How can someone bypass this?

I know eval is insecure, but I want to know what's the trick here. How can you bypass security of if (0) and braces check in the code above?

I tried to add // { so it will imbalance the curly brackets and it won't add the if (0) and call eval, but token_get_all ruins that.

I think this comment from the code you posted sums up my thoughts:

    // We need to know if braces are correctly balanced.
    // This is not trivial due to variable interpolation
    // which occurs in heredoc, backticked and double quoted strings

Keep in mind that the result of improperly executing the code check is a remote code execution vulnerability.  Working on non-trivial items is of course the norm for engineers, but if you are working on a task that is extremely difficult and a mistake leads to the most serious kind of security vulnerability - well, clearly that is a recipe for disaster.  In fact it's worth pointing out that the comment you posted was the authors second attempt at this.  His first attempt at contained at least one mistake that (presumably) was vulnerable to "sandbox escaping" and required him to start over.  I'm certainly not going to trust the security of my application to a one off script written in a comment box on some random page on the web.  Especially since (unless I'm missing something) this comment happens to be on a page describing a language built-in that does the exact same thing.  I would trust the language built-in before some random guy on the internet.

Regardless of whether or not anyone has found an exploit yet, it doesn't change the fact that this is generally a bad idea in the first place.  What if there are other escaping options that the author hasn't thought of?  For instance, plenty of exploits out there have relied upon confusion over different encodings.  It might be possible for an attacker to inject in a brace using an encoding different than the one in the file, but still supported by PHP, which will therefore not register as a brace in his checks but will be recognized as such by PHP, allowing an attacker to break through the brace balance check.  Granted, that particular attack avenue may not actually be possible, but I'm mainly trying to emphasize the general point.  There can be many hard-to-catch "gotchas" in situations like this, and the result of missing one of them in this code is a remote code execution vulnerability.

When faced with "Get it perfect or be extremely vulnerable" my first preference is "Just don't do it".  That is followed up by a strong "don't trust a random comment on the internet", especially if there is an easily-accessible language built-in that does exactly the same thing but (presumably) securely.

Edit to add.  It's worth making a comment about eval.  You said "I know eval is insecure, but"...  This is not strictly true.  eval usage is generally frowned upon for a few reasons:

If nothing else it tends to have poor performance
If used improperly it certainly can create real security issues
It generally violates best programming practices

However, like any tool, it can have its time and place.  So to be clear the issue isn't that eval is insecure.  The question is whether or not eval is being used securely (and properly) here.  For all the reasons outlined above I don't think that it is being properly used here, but that is different than a blanket "eval is insecure" statement.


My Ipv6 is under attack by the smurf6? When I go to whatsmyip.org under my host name I get "Your.Ipv6.Is.Under.Attack.By.The.Smurf6.Info". What does this mean? I'm using private internet access as my VPN so I'm guessing PIA is under some sort of attack? What should I do?

As @bonsaiviking commented, this is a form of DNS Registry Spam, and unfortunately it is very easy to do. The upside is, it's not an attack on your domain, and it shouldn't cause anyone actual problems (unless you are trying to sift through DNS records...)

The example of google.com given at the razzed.com link is as follows:

  whois google.com

  Whois Server Version 2.0

  Domain names in the .com and .net domains can now be registered
  with many different competing registrars. Go to http://www.internic.net
  for detailed information.

  GOOGLE.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
  GOOGLE.COM.ZZZZZ.DOWNLOAD.MOVIE.ONLINE.ZML2.COM
  GOOGLE.COM.ZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM

  ...many lines left out

  GOOGLE.COM

  To single out one record, look it up with "xxx", where xxx is one of the records displayed above. If the records are the same, look them up with "=xxx" to receive a full display for each record.


Can school administration see what I'm browsing on my personal computer at home? I'm wondering what type of access a school administrator might have to my browsing history/watch while I am working and teaching.
I work from home on my private wi-fi network, and I use my personal device, not a school device while I teach. The only thing I do is sign in to my school's Gmail account for my district access. I don't allow Google to sync and add all of my extensions, however.

If you're on your own network, it's not likely. The only way they would be able to do that is if they have some sort of management software installed to your computer. Without that, they won't be able to see anything.


Os command injection privileges I have a question about privileges when performing an Operating system command injection.

If an attacker succeeds in getting a reverse shell on a remote server through netcat (netcat -v -e '/bin/bash' -l -p 5550), does he/she have admin privileges on the victim machine or some sort of escalation is needed?

thanks

Usually, you need some sort of escalation.

If you can run the command netcat -v -e '/bin/bash' -l -p 5550 all you've done (effectively) is have the remote machine open a port for you as the user that was running whatever process ran the command. That is to say, if you managed to inject your netcat command into a www process, you are likely logged in as the 'www' user, and not (if the remote machine has been remotely secured) as root.


PCI SAQ C 1.2.1, 1.3.5 and remote server/software I'm hoping someone here can help me.  I'm attempting to get the small nonprofit I work at PCI compliant, as we have been paying an additional $20/month in noncompliance fees to our processor since we started taking credit card YEARS ago (apparently I'm the only person to look at statements).

I'm not an IT person, I do accounting/billing.  We process credit cards two ways.  First, 95% of our credit card payments are entered into our software which then speaks to the processor.  We access this software through a remote server physically located in Denver.  Second, the remaining 5% of our credit card payments are entered on my computer keyboard directly into the processor website (this is for recurring payments, which we have to enter manually into our software after the payment has processed).

So my questions are:

Am I correct that given the way we take payments we should complete PCI SAQ C?
Do I need to involve both the county IT people that we contract with for services in our offices and the software IT people located in Denver, given the way we take payments?  If so, do I need to ensure that answer to each question matches for both of them?
Most importantly, when the questions referenced in my title talk about limiting outbound traffic (all inbound is limited per our county IT people, I'm having difficulties getting answers back from our software IT people in Denver), does that mean that the computer(s) we use to process credit cards need to be completely limited to only process credit cards?  This would be quite an inconvenience, and I don't know many small businesses (hotels especially immediately come to mind) that limit their computer functions in this way.  If I'm misunderstanding the requirements, can someone explain them in more depth?

Can't comment yet, but will answer as well as I can w/o knowing more info about your setup in regards to the Company in Denver.

That depends on what you mean by remote server.  For the 95%, are you going to a web site and entering the credit card information, or are you using remote access tool (Remote Desktop, Logmein, Teamviewer, etc..) to connect to this machine in Denver?

Will need more information on this question to give an better answer.

PCI Questionnaires are by Merchant.  Additional sites come into play, if all the sites are processing using the same merchant #.  However, generally most PCI compliance scans are per merchant #, which usually is per site.  Wal-Mart might have thousands of stores, but each store/site is a different merchant #, and each store would do it's own questionnaire.  You would want to talk to both IT departments about questions you will have during the questionnaire.  Firewalls, passwords expiration, AV updates, and so on.

However, not knowing all the information about your setup with Denver makes it difficult to give an accurate answer.

The question I can help you the most with as it can't really be any different regardless of how your setup between County and Denver is.

Any computer that processes a credit card over the internet, should be on a closed network.  The only internet send/request that device should make is for processing credit cards.  Exclusions for OS/Software/Antivirus/Firmware Updates/and some others.  Basically, no browsing & no email should happen on those computers that process a credit card.  Even if you have remote access to your computer that processes credit cards, that remote access should be turned off only when needed.  There has to be 0 chance that an employee gets on the wrong website, clicks the wrong email, anything that could allow something to happen.  Any other computers that are on the same network should not be browsing or emailing.

Analogy I give to customers about this is:

You can have a house that you've built a circular fence made of brick encompassing your house.  The brick can't be climbed, however at one point in the brick there is a small hole where you can see through it.  In PCI Compliance view.  You failed.

For hotels/restaurants it can be difficult, but that's what it's supposed to be.  Do all hotels & restaurants follow this procedure.  No.  They're supposed to.  Generally all the credit card locations my company manages (over 100), have an office computer strictly for internet use.  The computers for running credit card transactions are on a separate network with a firewall in place, and many security settings to only allow CC processing and nothing else.  There are several sites that I manage, that either don't want to pay for security, or don't care.  Those people sign a waiver, not holding my company liable.

Hope that helps somewhat, and apologize for not commenting first.  If I can get more information on your setup with Denver, I will edit my answer.


Difference between Art And Dalvik Security on android? What is the different between ART And Dalvik security, cause Google using Art after Kitkat (4.4.2) ?

Just for these two options?

Refrence

  Ahead-of-Time (AOT) compilation, which improves speed (particularly
  startup time) and reduces memory footprint (no JIT)
  Improved Garbage Collection (GC)

and what about the security?

On a general basis, the distinction between just-in-time and ahead-of-time compilation is not relevant to security. One can see things as performance trade-offs. For an application, that consists in a sequence of small instructions meant for the abstract sort-of-Java virtual machine:

In pure interpretation, individual instructions are parsed when they are to be executed, and the parsing of any instruction is done every time that instruction is executed.
In AOT compilation, during a preparatory phase (e.g. when the application is installed in the phone), the instructions are translated into the opcodes that the actual hardware CPU understands. Thus, the "parsing" is done once. Performance is much better, at the expense of a one-time translation done at installation.
In JIT compilation, you get something in-between these two models. Translation is not done in advance, but it is still done by whole chunks (a complete function in one go) instead of instruction per instruction. Compared to AOT, more compilation occurs, basically whenever the application is launched, instead of once. On a rather theoretical basis, JIT compilation may optimize things based on the actual execution pattern and could produce a better (faster) sequence of native opcodes than AOT; in practice, this effect tends to be nullified by the constraints under which JIT compilation must operate (in particular, since JIT occurs when the application is being used and the user is waiting, the JIT compilation must be fast).

In all of the above, the security properties of the Java VM are maintained: all array accesses are still checked, all method calls are verified to happen only on objects that indeed offer the said methods.

If we want to nitpick, then we might argue that ART somewhat reduces security, not because it uses AOT compilation, but because it is new, and new software tends to have more bugs than old software (a large user base represents a lot of testing, so old software has been naturally tested thoroughly). Conversely, we might pretend that AOT compilation is simpler to implement than JIT compilation (because AOT does not have to deal with translating a live application and already allocated objects) and therefore an AOT-based JVM implementation would be less likely to have bugs than a JIT-based JVM. But these considerations are just idle speculation under the usual assumption of "all other things being equal", and it is known that all other things are never equal.


How effective is Expect-CT against content inspection in an enterprise context? HPKP was used to ensure that a browser accepts to connect to a site only if the public key he has on file is the one presented by the target site. I saw it as a way to make deep content inspection more complicated (some sites would simply not accept the connection so there is nothing to inspect).

It seems however (from the Wikipedia page) that

  Most browsers disable pinning for certificate chains with private root
  certificates to enable various corporate content inspection
  scanners[6] and web debugging tools (such as mitmproxy or Fiddler).
  The RFC 7469 standard recommends disabling pinning violation reports
  for "user-defined" root certificates, where it is "acceptable" for the
  browser to disable pin validation.[7]

So no protection anymore against deep inspection (I am not sure what the mechanism is for in that case but anyway).

This probably does not matter anymore taken that

  The mechanism was deprecated by the Google Chrome team in late 2017
  because of its complexity and dangerous side-effects. Google
  recommends using the Expect-CT as a safer alternative

Certificate Transparency is a public log of issued certificates

My questions:

How does this log help to ensure that the certificate I see is the one actually presented by the target site, and not an intermediate one (where my session is terminated on the deep inspection engine, which replays the connection)
If it indeed helps to do that, how does the "enterprise" restriction highlighted for HPKP above comes into play (if at all)?

The aim of certificate pinning is to protect against malicious man in the middle attacks and not against legal content inspection as done in companies and also desktop antivirus for protection, where the certificates are issued by an explicitly trusted local CA. it does not matter here that legal protection methods might also be used to invade the privacy - you need to discuss such things with your employer instead.

Insofar it makes sense to handle Expect-CT the same way and it is also documented to behave that way. From MDN: Expect-CT:

  Root CAs manually added to the trust store override and suppress Expect-CT reports/enforcement.


When it is possible to locate/trace SMS sender? I have read this question (which is closed) and already answered.

Quoting the answer:

  There is no location transmitted within a normal SMS message (unless
  added by the author) so as the recipient of an SMS you won't normally
  be able to determine the location of the sender.

  The location of a cell phone can be determined with varying precision
  by the Mobile Network Operator and any third parties with access to
  the MNO's system or data. The location precision depends on the
  capabilities of the device, the cell tower(s) it connects to and the
  quality of the signal.

So this makes the answer to the question HOW to locate the sender.

But lets say that the attacker goes to an unknown location with his turned off cell phone, inserts the prepaid SIM card in, turns the device on an sends an SMS message or a call with is (something illegal) i.e. death threat. He delivers the message, removes the SIM card and turn off the cell phone.

My question using the quoted answer: When can they trace him?

Do they need to detect his registration to the mobile network tower as he turn his mobile phone on?
Or is it enough that he logged in to the mobile network and left enough data to analyze it later do determine where he was.

Triangulation.

All that's needed is for them to be connected to the mobile network.

The mobile network operators can look at the signal of the phone to a cell tower (which is stored in records) to determine the distance of the phone to the cell tower. If it's connected to three or more cell towers, they can get a location of the phone accurate to an area of about 3/4 square mile.

The accuracy of the location depends on some factors such as how many cell towers are in the area the technology the operator uses. If the cell towers are positioned close to the phone, the resulting location will be more accurate than the phone being located far from the cell towers.


Cracking a password Protected pdf file using John the ripper What exactly happens after I provide the hash from the pdf file to John for cracking the password?

Does John extract just the password hash from the file and work on it, or is there something else?

Generally the target hash you want to break in the case of a PDF is the user hash, which is derived from the user's password. A PDF will do two things when a password is entered for an encrypted PDF -

It will derive a symmetric key from the user password. This is the key that the document is encrypted with.
It will derive a hash from the password and will compare it to the user hash in the documents metadata to check if the password is correct.

PDF is strange in that it actually derives the symmetric key before it computes the hash, in fact the symmetric key is used in the computation of the hash. The process of producing the hash is as follows:

Derive the symmetric key from the user password.
Concatenate the following values and pass the result to the MD5 hash function:

A 32 byte padding string (defined in the spec)
The 16 byte document ID (contained in the documents metadata)

Encrypt the output of the MD5 call via RC4 with the symmetric key from step 1.
Do the following for i = 1 to 19:

Create a new RC4 key by XORing every byte of the symmetric key from step 1 with i.
Take the output of the previous RC4 call and encrypt it under the new RC4 key.

Append 16 bytes of arbitrary padding to the output of the last RC4 call. This is the user hash. (It's not clear why the user hash is padded at all, since the comparison to validate the user password throws out the padding bytes of the user hash and just looks at the first 16 bytes.)

What I would assume that John the Ripper does is it will feed passwords (defined by whatever rules you give it to generate passwords) into the above algorithm until it computes a user hash that matches the one in the document metadata (i.e. the hash that you provided). Since the hash derivation uses only MD5 and RC4 (and not a lot of rounds of either) it is quite easy to try a lot of passwords in a short amount of time, so PDF is quite susceptible to brute force and dictionary attacks. In fact the whole algorithm is rather bizarre and doesn't instill much confidence in the security of password protected PDFs.


Enforcing password change When a site gets hacked, or otherwise, the web site forces you to change your password. This is done by simply telling you to change your password, not enforcing it.

Why do they do that? For instance, they could:

Disable your credentials, and send you an e-mail for password reset.
In case you missed the email - or you aren't using the service very often and chose to ignore the password reset email - just keep the account deactivated until sign in is attempted, then send the password reset email, with hyperlinks to report possible unauthorized sign-in tries.

I've implemented the functionality you describe in the past as follows: Along with every account in the database, a Boolean value is stored. This property might for instance be named IsPasswordChangeRequired.

When the sign in form is submitted, the web server first checks whether the user credentials are valid. If this is the case, it checks the value of the IsPasswordChangeRequired property. When that's true, an alternative version of the sign in form is served, i.e. one that contains fields to enter a new password.

The server could also respond by redirecting to a change password page.


How to prevent unintended REST API usage? For a university project, I am supposed to implement an API that allows storage and retrival of strings. Clients accessing this api can be mobile phone apps and low power embedded devices. The data stored is not sensitive, but I don't want attackers to alter or delete it. It will most probably not be used outside of our limited experiments, but I would very much like to understand how this would be done the right way.

I have the following constraints:

For usability reasons, it would be nice if the user is not annoyed by having to create an account after installing the app. Instead, I want it to fetch an id/token on first launch, which is generated by the server that authenticates and identifies this user. This id/token has then supplied on all following requests
My embedded devices can not use TLS due to storage, ram and cpu constraints

Given these restrictions, should I treat this API like a "public" API, even though I don't actually want it to be public? Is there anything I can do against (from my side) unintended use, besides rate limiting access?

Things I have considered:

I thought about at least having the part where you get a API id/token done over https, thus hiding where you can create an account, and potentially also requiring a secret key to be supplied as well. However, this looks much like security through obscurity to me, and will probably be prone to reverse engineering. But it might be better than nothing? Additionally, I think I should use tokens with limited rights after the sign up process, especially for my embedded devices, since those probably can not handle using https all the time. Otherwise I risk having my account identifier stolen, which could be used to delete all data or overwrite it. These embedded devices will be used only in trusted (home) wifi environments, but that should not prevent me from doing things right.

So to me, the situation looks like this:

I can not reliably prevent people from using my API in ways I don't want it to be used
I can and should protect existing users data from modification

Generating an API-Token without the user knowing is absolutely not uncommon. I do this all the time and this is not a problem itself. But sending the data unencrypted is a problem. If this is a allegation given by your professor you can't do anything about it but if you just don't want to use it because of the given reason of performence I have to dissagree with you!

Using https is nothing that really slows down a mobile device that much. Many people use https all the time on their mobile phones and don't even notice that encryption is used because it's not such a big differnce in time needed.
If you really need a fast performence you can finetune the https options of your webserver. The performance intensive part is the initial handshake which includes asymmetric encryption that is used to exchange the masterkey. The masterkey is the symmetric key that is used for that session. You can set the livefime of the masterkey to a higher then default value on the serverside to avoid the performance intensive part of following ssl connections.


Do the Greenbone scan reports actually differ from a typical OpenVAS scan report? My company is planning to use a Greenbone appliance in the near future and wants to analyze the results with another tool. I have access to OpenVAS with GSA so I am able to test the analysis now with existing scans. But I'm not sure if I can continue to use my tool for analysis as soon I will only have access to the scans from my Greenbone appliance.

This leads to the question: Do the Greenbone reports actually differ from a typical OpenVAS scan report?

I just got an answer to this question from a salesperson working at Greenbone. The OpenVAS-reports and the Greenbone-reports have indeed the same structure. So if you are using a parser which works on OpenVAS-reports, it will also work on the reports generated by the Greenbone appliance. The only differences are - as the salesperson put it - in quality. But this is something you should evaluate yourself, as I am in no position to justify this claim.


Shellshock plus sudo/su environment whitelist bypass - big problem? The question is: How big a problem is this? Looks pretty big to me.

With the shellshock bug it is possible to bypass the whitelist of known-harmless environment variables in sudo, as well as other routes to execution of code as high-privileged users. For example variables MAIL and DISPLAY are by default propagated by sudo in many configurations (last time I checked - I don't think the latest Debian does).

In the presence of Shellshock, if an unprivileged user, partially privileged user, or malware with unprivileged code-execution can supply any propagated environment variable whatsoever to a shell running as root, he can execute arbitrary code as root.

User with limited sudo rights is malicious
User sets environment variable such as MAIL to shellshock exploit code
Any call to popen, system or bash by any sudo'd command by such a user will now result in arbitrary code execution as root.
result is that any sudo rights at all become root access to the system - it does not matter how restricted his access was

Or:

User gains access to unattended terminal of user with some sudo rights, or
Malware gains code execution as an unprivileged user who has some sudo rights
Malware/User sets propagated environment variable such as MAIL to shellshock exploit code
Any call to popen, system or bash by any sudo'd command by such a user will now result in code execution as root.
Does not require knowledge of password - password can be entered later by the victim user after access has ceased.

Sudo blocks environment variables that might be bash function definitions (2004-11-11 env.c: strip exported bash functions from the environment), even if the variable name is whitelisted. That's why sudo isn't included in the list of common attack vectors for Shellshock.

A bash script invoked by su to a restricted account can be an attack vector. But there are other problems with a shell script invoked via su. su doesn't strip environment variables such as IFS or PATH (bash doesn't import IFS from the environment, but some other shells do) — or BASH_ENV, which is the name of a file where bash reads commands when it starts up. A shell script invoked via su to a restricted account would need an intermediate wrapper. This wrapper should take care what variables and values it lets through.


What's the purpose of the lock and unlock feature in password managers? I'm afraid this could be a very stupid question, yet I cannot think of an explanation. Password managers (keepass, etc.) often have a button that lets you "lock" the database, so if you need a password you will have to unlock it again by entering the master password. The database could also be locked automatically after some time, or when the screen saver starts, etc.

It's clear why you should unlock the database the first time you use it after you turn on your computer, because it's encrypted. But why should you ever need to lock / unlock it again afterwards? The first thing that comes to mind is "what if an attacker accesses you computer while it's turned on and you are away", but for that matter there should be a screen locker, otherwise you are screwed anyway. It doesn't seem to prevent problems with malware or cold boot attacks either.

What threat is this trying to mitigate then? I can only think it can be useful to protect against a very low-level attacker with no skills at all, in case you leave your computer and forget to lock the screen. This kind of attacker would be able to take a look around (and read info from your unlocked password manager) but they wouldn't be able to install malware or compromise the machine in any other way. Or maybe I'm missing something.

"Locking" the database (in KeePass, "Lock" just plain closes the database) means that the decryption key for the database and any decrypted passwords from the database are no longer accessible in memory.  Without that protection, something like KeeFarce can be used to extract that information:

  KeeFarce allows for the extraction of KeePass 2.x password database
  information from memory. The cleartext information, including
  usernames, passwords, notes and url's are dumped into a CSV file in
  %AppData%

Something like that could be run by someone who got malicious code running on your machine.  One of the first things an attacker will do, once they get code running on your machine, is to look for credentials that it can use to extend their access to other systems.  This fits that bill.


Access LAN services through malicious web page Suppose that a user on a corporate network has access to a private FTP server, or intranet site, that's only available on the Local Area Network, available at http://internal.example.com. If an attacker gets this user to view a malicious website, is there anything, or any way to stop the attacker from including a script on the page that accesses this internal site, and even possibly running an exploit on it (as internal sites often have more lax security), all from the user's privileged network position?

Even if the attacker doesn't know the exact nature of the internal services, things like port scanning can now be done with javascript: http://blog.andlabs.org/2010/12/port-scanning-with-html5-and-js-recon.html

I think I figured it out. This potential attack is addressed with Same-origin-policy. A browser will only allow scripts to access resources from the same origin. https://en.wikipedia.org/wiki/Same-origin_policy


How to pass a localhost check for an incoming request? I'm trying to send a request to an http server hosted on a machine. The http server is in C# and drops any packets that are not from localhost:

public void Request(HttpListenerContext context) {
    if(!IPAddress.IsLoopback(context.Request.LocalEndPoint.Address))
        this.ConnectionRefused()
    ...
}

I had the idea of using scapy and spoofing the TCP src IP for 127.0.0.1, and the machine receives the packet (confirmed in wireshark), but the request doesn't seem to be triggered. I am wondering if anyone knows how I can make an http request to this port bypassing the Loopback check.

You "pass" a localhost check by sending the request to localhost (or 127.* or ::1). For example, you can make a web browser do this by navigating to http://localhost/ or http://[::1]/. The C# code snippet you posted for the server is checking the local IP address, so for a server that's the IP address the server received the connection request at, and from a client's perspective it's the IP address that the client is trying to connect to (the destination).

If you try sending such a request from any machine other than the one you're attempting to connect to, you'll route the request to your own machine, which is not what you want (but is the point of the loopback address). If you try crafting raw Ethernet packets that just happen to contain TCP/IP traffic, and set the IP destination to 127.0.0.1 but try to transmit the packet to another machine (via MAC address), one of these things will happen:

You'll get an error from your network stack, because the packet was recognized to be IP traffic and is being transmitted wrong. Most network drivers probably won't do this, though, and if they do you can (in theory) edit that behavior out.
Your packet will go out on the network, but be rejected by the first node it arrives at (probably a switch or router, unless you have a direct connection to the other machine) because, again, it is invalid; it's bound for the loopback network but comes from an external network. This might be what you're seeing in Wireshark.
Your packet will be accepted by a router or switch, but passed to that router/switch's loopback network (after all, that's the destination IP address) rather than passing it on to any other host (it doesn't know where next to send the packet). This would be a security bug in the device and well worth reporting to the manufacturer if found.
Your packet will go to the destination computer (if directly connected, or possibly if broadcast through a network hub), and be initially accepted by the network stack as a TCP SYN packet. However, when the server tries to respond with SYN/ACK, it will fail because it is trying to send an invalid packet (originating with localhost but bound for an outside host). This is still probably a security bug in the network driver / IP stack, because UDP packets don't require a handshake like that. Very much worth reporting.
Your packet reaches the destination host and is accepted (as above), and you get a TCP SYN/ACK from the server, inviting you to complete the handshake with a final ACK and start transmitting data. You'd probably need a raw socket listener for this, because the OS network stack isn't going to recognize the incoming packet as part of a TCP handshake it was working on (though you could, theoretically, patch it to do so). This indicates a serious security bug in the server's network stack.

Note that in none of these cases, except the last one, is there any chance of the C# web server ever seeing the request come in. HTTP is transmitted over TCP, and TCP servers aren't even notified that somebody is connecting to them until the handshake completes. So, unless you've got a really serious bug in your network stack and are connected pretty directly, this is never going to happen.

Now, if you want to know how to reach a server listening only on loopback from outside the machine, the solution to that is to find some program on the same host as the target server that does listen to outside traffic, and will either relay requests to specified destinations (a proxy), or that can be used to create new web requests (this is a Server-Side Request Forgery (SSRF) attack, and one common way to create them is through an XML eXternal Entity (XXE) attack).


Public Key Pinning and subdomains Shortly I have intend to install new webserver and I'd like to secure users a little bit more. I already have domain, (virtual) server and everything else that matters when configuring a server. Basically this one will be used as webserver for personal storage of our family members, so we can share documents with each other independent of our current location. Because they are not very familiar with technology and stuff, I would like to secure the connection a bit more. Alongside web application for file storage I will create some easy website and in the future I think the webserver will also host blog. I decided to structure the website like this:

storage.domain.tld - for our personal storage
domain.tld - there will be some easy website (HTML file with CSS and JS files along)
domain.tld/blog - after some time I think this address will be used for blog

I will use StartSSL to sign my certificate which will be installed on webserver. Because HPKP requires backup certificate, I will also create additional certificate in case of any failure in the future. I think that after some reading I correctly understand how to configure HPKP, but I'm still not sure how to deal with subdomain and what exactly could be a problem if there is misconfigured HPKP header.

So first about subdomains... Most of our family members will just use storage.domain.tld. StartSSL enables signing of certificate for main domain and one subdomain. Will browsers recognize HPKP header on subdomain if I set it only on domain.tld and add includeSubdomains in it? What to do if browsers recognize HPKP header only on the domain you actually visit? I would also like to see some suggestions on this topic, because I'm out of ideas what to do here.

And the second thing about misconfigured HPKP. When I will set up everything, I think to set max-age of HPKP header to something around 60 (1 minute should be enough to test out if HPKP works correctly). After success I think to extend max-age to half year. If I understand correctly the browser just checks if public key in HPKP header is the same as the one of webserver. If there's a match, everything should be OK. So there is no connection to any other service for checking correct settings of HPKP? If I use browser in private mode and I visit my site with misconfigured HPKP, will this problem disappear if I remove HPKP header and visit site again in non-private mode?

I will appreciate all suggestions and comments to my questions. Thank you in advance!

Will browsers recognize HPKP header on subdomain if I set it only on domain.tld and add includeSubdomains in it?

If the  user never visits domain.tld  and the HPKP header is only send on requests to this domain then the browser will never see the HPKP header. But only after the browser has seen the header it has any effect. Once the browser has seen the header it will also affect the subdomain since you've specified it, but the header will not magically travel to the browser when doing requests for the subdomain only. Thus you should add the header to all affected domains to make sure the browser gets it and gets also the updates.

  So there is no connection to any other service for checking correct settings of HPKP?

Correct. HPKP uses only the communication between the browser and the server sending the HPKP header, i.e. your server. Everything is solely under your control. And if you mess it up only you can fix it.

  If I use browser in private mode and I visit my site with misconfigured HPKP, will this problem disappear if I remove HPKP header and visit site again in non-private mode?

I have no source for this but I doubt it. HPKP will be either fully shared with the private mode and thus the problems persist there, or no sharing will be done in which case the problem happens not in private mode but still happens in the non-private mode. I don't think that sharing will only be done in one direction and especially not from private mode to non-private mode.


Wi-Fi Pineapple Device - is it that easy to steal people's info? I've been doing research on the internet relating to cybersecurity and I came across an article talking about a "Wi-Fi Pineapple".

The article made it seem like anyone can buy this and basically steal peoples information in a Plug-and-play type fashion.

http://blog.privatewifi.com/wifi-pineapple-redux-hacking-toy-offers-no-legitimate-use-tricks-hotspot-users/

I was wondering how accurate this is, is it really that easy?

Most importantly, If one wanted to learn how to use a Wi-Fi pineapple, what concepts would I need to learn and what should I start learning first (networking, programming, Linux, etc,)?

Yes, it is that easy.

To use a WiFi pineapple it's almost the case that you just buy one and turn it on...

Be aware, though, that while you can use it in limited config to highlight security issues, almost every use case could be illegal where you are.

Be aware that if someone detects you using one, bad things could happen. https://www.csoonline.com/article/2462478/hacker-hunts-and-pwns-wifi-pineapples-with-0-day-at-def-con.html

Talking of DefCon, this guy has the extreme version:

https://theoutline.com/post/2017/this-guy-hunted-wi-fi-hackers-using-a-giant-backpack-made-out-of-radios?zd=1&zi=hl5dxkob


How can Draytek products not be affected by KRACK as they claim? According to Draytek on their website,

  When DrayTek wireless products, such as wireless routers and access
  points, are used as wireless base stations, they are not affected by
  the KRACK (Key Reinstallation AttaCK) vulnerability; therefore patches
  or updates are not required.

I found this quite surprising. There is no further information explaining how they reached this conclusion, but at this stage I have to be inclined to believe it - it surely would have be signed off by various legal and engineering teams.

My question is, how would this be possible? Had they already discovered the flaw and mitigated against it (which would raise questions about them not publicly disclosing it)? Did they simply not implement the WPA2 standard correctly and this is happy coincidence?

I appreciate that it's possible that no one can conclusively answer this without inside information, but it will be interesting to see if more vendors claim not to be affected.

The Key Reinstallition AttaCK attacks the client - not the access point. As they state clients connecting to their devices can be affected.
*Further to @Darrens point this may not answer the question. Whilst the attack is based on re-transmitting a message to the client since the problem is in the protocol and both ends can detect the attack arguably both should be fixed.
**Reading further there appear to be additional attacks attacking the AP. Reading up further now. Its possible Draytech don't use these features.
From the main release page

What if there are no security updates for my router?
Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details.

***Having re-read the entire release I can't see anything that suggests an attack targeting the AP directly. So I believe the view Draytek is taking is that since the attack is targeting clients the patch should be here. Whether that is the correct view is arguable either way.


Is it that easy to crack a Windows SAM file? My friend told me that he can easily crack a Windows SAM file using Ophcrack.

Assuming that I have access to the whole config folder (the one which contains the SAM file) of a Windows machine, is it that easy to crack Windows passwords? Is Windows that unsecured?

With physically access its not very hard to crack or "erase" a windows machine password even if it has a bios password.

In windows XP in a most case if not fixed, you can login as a default admin in Safe Mode.

Ophcrack works by using LM hashes through rainbow tables. The program includes the ability to import the hashes from a variety of formats, including dumping directly from the SAM files of Windows.


What is the risk and mitigation of accidentally typing a YubiKey password in an open forum? I have a YubiKey in my laptop (for testing) and accidentally broadcast my YubiKey password out to the Internet.  Since this is only a test key, and has no access to anything of value, here are some sample OTP keys:

ccccccbhknbgunfejcduuficrglhbckgbbugjegrbbbj
ccccccbhknbgncbjurrufidrvjvjnbglduvnjtccjhif

My understanding is that in the default configuration, the leading characters is an identifier (unique ID) of sorts :ccccccbhknbg.  I'm unclear if this is an encoded value, or if it's a raw ASCII value.

What is the risk of sending these passwords out on the internet?  Was any privacy lost?

Does it matter if it's connected to the YubiKey cloud, or if it's part of a stand-alone configuration?

How can I recover from this? Can I regenerate any identifiers?  How can I invalidate the passwords?

There are some explanations on what YubiKey does here. Basically, the password which the YubiKey "types" (from the point of view of the computer, it is a keyboard) can be either a static password, or a one-time password. If it is a static password, then you just revealed it, and it is time to be very sorry (and promptly change that password).

The one-time passwords, what YubiKey produces follows HOTP. The cryptography in HOTP is such that it is not computationally feasible to recompute the "master secret" from one or several one-time passwords produced with HOTP. Moreover, each password is internally computed from a counter. The YubiKey and the server both maintain the same counter, and the server allows for some limited lack of synchronization. Namely, when the server's current counter has value n and receives a password as authentication attempt, it will internally generate the passwords for values n+1, n+2,... up to, say, n+100 (that's configurable). If a match is found with (say) password n+17, then access is granted and the server's counter is set to n+17; otherwise, connection is rejected and the server's counter is not changed.

Therefore, what you inadvertently published "on the Internet" is a password which will grant access to the corresponding server, until your own next authentication on that server, because that authentication will update the server's counter to a further counter value. In a way, using OTP with counter value k invalidates all OTP values with values j < k. Which leads to the following recovery procedure: if you published an OTP value, quickly connect to the server so as to invalidate that published value. Afterwards, you can just ignore it; once invalidated, it is harmless.

(Note: if you repeatedly generate a lot of "blank" passwords with your key without authenticating to the server, your YubiKey may go out of synch with that of the server -- the key using counter values way beyond what the server would currently accept. Don't let your 3-year-old play with your YubiKey ! In a similar situation, for infrared car keys, counter synchronization is forced through RFID when you start the engine.)


Can I use 777 file permissions inside server virtualisation (that only I have access to) without worry? For this question, please assume I have followed every possible security measure to secure my Linux server. Only I have access to the web server via one open SSH port. If there are security issues then that's a separate issue.

I'm using a cloud server - which I believe is server virtualisation.

Now, I take my brilliantly secured server and I set a file/folder to 777 that's NOT publicly accessible (e.g. a cache folder for a server-side framework).

777 I believe allows 'world' access, but because I'm the only person that can access the server then does it matter that I set the folder to 777 world access?

I'm guessing if the file was in the public area of a web server then this wouldn't be a good idea, but I can't see an issue if it's in the non-public area. In fact, surely I could 777 every non-public file and rely on the fact that only I have access anyway? Of course I'm not going to so this, but my point is surely that file permissions are superseded by the fact nobody else can access the server anyway.

Also, does it make a difference that I'm using server virtualisation? Is this less secure? Can other people who are sharing the same server as me see my files because I'm using 777 permission?

Basically I often get file permission problems when the server-side framework's code needs to write to folders (e.g. cache). 777 fixes it every time, but I want to ensure that I'm making the best decision and not just taking the easy way out.

Under the premise that the system is so well-secured that there is only one person which can connect to it via network, then file permissions do not really matter anymore. The operating system can only enforce them against local users anyway. When an attacker can not log into the system or influence some public service running on the machine to do their biddings, they won't be able to access files, even when they are world-readable.

But this premise is illusory.

When you run a webserver on the box or some other service which can be accessed by other people, this services becomes an attack surface. An unknown vulnerability in the webserver (or in a buggy web application running on the webserver) could allow an attacker to take full control of the webservers process. The attacker can then access any file the webserver can access. That's why you usually run a webserver under its own user and use file permissions to make sure that this user can only read and write the files it has to for operating that webserver. When the worst case happens and an attacker indeed takes over the webserver, any damage is contained to the files and directories directly relate to it. But when file permissions allow the webserver to read, write and execute any file on the machine, an attacker can literally replace the whole operating system and lock you out.

When you use virtualization, the host-system can access anything which happens in your virtual machine anyway. File permissions won't be enforced, because the attack would bypasses the operating system which runs in the VM and directly access the virtual hard drive file in the filesystem of the host machine.


How can I protect browser cached files to be accessed in a case of a stolen hard drive? For the usual reasons we want to cache certain resources browser side, e.g. list of products bought in the past.
Context is a web application, accessed via the internet.
This list is confidential in my case, and I want to mitigate the case where an attacker get physical access to the (os password locked) machine or to the hard drive.
Are there standard strategies/JS libs/browser support for such scenarios? It seems browsers in general will cache files in an unprotected way (not encrypted essentially).
Full disk encryption or any os level strategy is not an option obviously - no control over who uses my web application. I still want to protect their data.

If you control the system
Besides cached files that you see there can be other places where browser data can be found:

System swap file
Temporary files (this is not the same as cache)
Data in the deleted (some files can be restored after deletion)

That's why, if you have some sensitive data in cached files, caring about cache files only is not sufficient.
That's why consider using whole disk encryption. On Windows it can be BitLocker, on Linux some solution based on LUKS like dm-crypt.
If the whole disk is encrypted, then you don't need to care about any temporary files and deleted files.
If you don't control the system, e.g. cache on user device
A solution depends on what threats you see.

If disclosure of cached data means that user will loose let say 100'000 USD, then a very efficient solution is to inform users how they can encrypt their disks.

If disclosure of cached data is less expensive: Generate a key pair. Send public key to the server. On the server encrypt data with public key. In browser, before displaying data, decrypt them with user private key. Such data in cache cannot be decrypted by anyone. To access private key user will be asked once for a password. If device is stolen, nobody will be able to use private key because this requires the password. If the password is random and long enough, it will be unbreakable.
Separate data from code. Encryption of code makes no sense. Encrypt the data only.
But: When browser decrypted data and displays them to the user, they are present in the plain form in the browser DOM. If the device swaps memory, such data can be written to the swap file in the plain form. Means, this approach is not as secure as the full disk encryption.

If the data disclosure will not cost much, i.e. if the data disclosure does not give an attacker much benefits, then experienced attackers will not spend their time on retrieving such data. Then you protect against simple threats only, e.g. against advanced users that are aware of browser cache, but don't know much about technologies used in browser. Then obfuscation might be sufficient. Simple viewing of cached files will not give such unskilled "attackers" any info.


Isn't Youtube supposed to forget what I did during an incognito session? When I go into incognito session and then use Youtube, I always thought that it's like coming to the site as a totally new person. How surprising it was when one day I watched a cabaret (not a very trendy, nor fashionable thing to watch) in incognito mode and a day later, on the same browser, on the same computer, in incognito mode I received a recommendation for me to watch the same cabaret, on the main page. I wasn't logged in. Neither am I logged in on YT in non-incognito session, but there I didn't receive any cabaret recommendation, so YT treats these two sessions as different users and give different recommendations.
I could think that YT knows something about my net, so they could basically recommend me anything that I watch on any computer in the range of the same wifi net, on any device, but YT doesn't do it.
So how did Youtube know that I had watched a cabaret a day before and that I was in incognito mode too? How does it all work? I reckon he wouldn't know if I had used a different browser?

First note that just because something can be explained by YT tracking you in incognito mode, this does not mean that this actually happening. Just because there is an apparent explanation does not mean that this is the only explanation or that it is the correct one. Note also that you have a biased perspective, i.e. you argue based on a single video which you've watched in incognito mode and which got recommended to you, but ignore all the videos you watched in incognito mode and which did not get recommended to you.
I doubt that YT actually knows what you've already watched in incognito mode and therefore recommends you the same thing again. But YT (or Google in general) tracks your general interests, not only on YT itself but over many sites using Google Analytics embedded in a significant part of the web pages.
It is probably correct to assume, that watching this video somehow aligns with your interests. And that you've implicitly shown these interests by watching other videos on YT or by visiting other sites while not being in incognito mode. Or the video was included in a site you've visited recently. So the recommendation does not completely come out of the blue and there is no need to actually track you in incognito mode to recommend you this video.


Why can I log in to my Facebook account with a misspelled email/password? I've been playing around with different login forms online lately to see how they work. One of them was the Facebook login form. When I logged out of my account my email and password were autocompleted by my browser. Then I decided to misspell my email and see what would happen if I tried to log in.

To my surprise I logged in with no problem after changing my email from example@gmail.com to example@gmail.comm. I then started experimenting with different spelling errors and I had no problem logging in as long as it was not too far off my real email. I tried changing the domain name as well example@gmadil.coom, my email prefix ezfxample@gmail.com etc.

Then I also tried misspelling my password and as long as it was not too far off my real password I could log in no problem (with the password it worked when adding one random letter before or after the real password, but not when adding a letter in the middle of it).

I also checked the actual data sent in the request by looking at it in Chrome DevTools and in fact it was the wrong data sent.

How can this be? Should I be worried about my account's security?

Facebook is allowing you to make a handful of mistakes to ease the login process. A Facebook engineer explained the process at a conference. The gist of it is that Facebook will try various permutations of the input you submitted and see if they match the hash they have in their database.

For example, if your password is "myRealPassword!" but you submit "MYrEALpASSWORD!" (capslock on, shift inverting capslock). The submitted password obviously doesn't match what they have stored in their database. Rather than reject you flat out, Facebook tries to up the user experience by trying to "correct" a few common mistakes such as inserting a random character before or after, capitalizing (or not) the first character, or mistakenly using capslock. Facebook applies these filters one by one and checks the newly "corrected" password against what they have hashed in their database. If one of the permutations matches, Facebook assumes you simply made a small mistake and authorizes your session.

While worrying at first glance, this is actually still perfectly secure for a few reasons. First and foremost, Facebook is able to do this without storing the password in plaintext because they are transforming your provided (and untrusted) input from the form field and checking if it matches. Secondly, this isn't very helpful for someone trying to brute force the password because online attacks are nigh impossible thanks to rate limiting and captchas. Finally, the odds of an attacker/evil spouse knowing the text of your password and not the capitalization are abysmally small and so the risk created as a result of this feature is equally small.

Should you be worried? No, probably not.

Further reading: https://www.howtogeek.com/402761/facebook-fudges-your-password-for-your-convenience/


Why does sslstrip+ fail to intercept the traffic from websites like facebook and gmail? I have been reading an article about sslstrip and mitm. Before the introduction of HSTS it was possible to strip ssl and send an insecure http page to the victim. Anyway it was overcome by using HSTS which collects the url of the sites which uses ssl and prevents the user from accessing the insecure http version of that site.

But in sslstrip+ (sslstrip2) a new method the attacker use a different domain name like http://wwww.facebook.com/ instead of http://www.facebook.com/ so that the browser will not find the domain in the hsts list and allows an insecure http connection with facebook (the attacking proxy of course).

But I just cant use sslstrip+ successfully in certain websites like mail.google.com, www.facebook.com etc...

It is said in Man-in-The-Middle Framework (MiTMF) - The tool that is available for linux (I installed it in kali linux) that it can evade HSTS also when we use --hsts handler (It uses sslstrip + when we use --hsts handler).

But this is not working well with the sites such as facebook and google. Anyway the tool mitmf redirects me to http://social.facebook.com/ (non-existing website and of course this may not be there in HSTS list of browser) when I visit http://www.facebook.com/ from victim's computer.
But soon leads to a could not find www.facebook.com error. I think the url http://social.facebook.com may not be present in the hsts list of browser still I am unable to access the fake url of facebook from a victim machine.

Why does sslstrip + (I am not talking about the old sslstrip by Moxie Marlinspike) fail in these cases? Can someone explain the method which is used by these sites to evade sslstrip+ ? I googled a lot but didn't end up with an exact answer.

That's because Facebook, GMail and other websites  are able to inform the browser that it is supposed (or not) to be secured with SSL thanks to HTTP Strict Transport Security (HSTS). This fixes the key problem with previous SSL implementations and what made SSLstrip possible.