remote desktop connection to a potentially compromised machine I am using rdesktop client on Linux to connect to windows machines. If some of these machines were compromised by some evil malware/virus/worm/trojan, is there any way for the malware to "jump" to my computer over the rdesktop connection?

I have always thought this is impossible, but recently I have read that similar technology, x2go is inherently insecure.

EDIT

To clarify my question, I am mostly interested whether the rdp protocol (or session) can be potentially dangerous for the client.

I don't understand the internals of the rdp protocol. But it seems to me, if the rdesktop client is just rendering images/bitmap then there is not much a potentially compromised server can do. If, on the other hand, the rdesktop client is interpreting some commands sent from the server, it could potentially be exploited.

For analogy:
Modern browsers do not just display static HTML webpages. Instead, they interpret Javascript, Flash, ... Is a rdesktop client similar in that it interprets potentially dangerous commands from the server?

If the only think the client does is rendering images, than apart from some bug in rendering library, it cannot be exploited. That would be comparable to a image viewer viewing jpg images.

EDIT 2

Are there any configuration options for the linux rdesktop client which I could use to make the session more secure? For example, I don't need "disk-redirection" or sound. Actually, I only need picture of the screen and clipboard (ctrl+c, ctrl+v).

From what I could read in man rdesktop, disk redirection and sound are not turned on by default. Are there perhaps some features which are turned by default, and which might bring potential security problems?

From a theoretical standpoint, you are connecting to a remote machine and it is sending data back to your machine. While in the normal context, this is just display, location type data, it is possible that some sequence of bits could be processed in such a way that it causes an exploit in your rdesktop or other tool used to make the remote connection.

With any connections and any type of program this is possible, a browser, an FTP client, etc.

If you are concerned about connecting to a remote machine here are some things you could try to reduce/mitigate your risk:

Load up rdesktop or your tool in a sandbox, virtual machine, live CD, etc. That way, if there is an exploit it does not compromise your core machine
Ensure that you are running the most up to date version of rdesktop or any client-side tool.

In terms of the malware jumping from machine to machine, it would need to know of and take advantage of some vulnerability in rdesktop and then use that mechanism to copy itself. If there is no exploit in the rdesktop application, it would be unlikely it could just "jump" by transferring the visual image. If you have some special version or enable some type of file sharing or file transfer, shared clip board, etc then it would be possible for the malware to utilize one of these channels.

A quick web search finds CVE-2008-1801, CVE-2008-1802, CVE-2008-1803, which describes a vulnerability in connecting to a vulnerable remote desktop server (the remote machine you would be connecting too).

In response to your edit:

It doesn't matter what the payload of the data is, file transmission, image, chat message, its all data. There is also control data, mouse position, refresh information, etc - a lot of data is needed just to keep the communication open and send updates. The compromised server can abuse the protocol by sending data which when processed by the client will cause a buffer overflow, etc. The data could be malformed or well formed. It's a matter of how those bits are interpreted. Even Photoshop or a Video editing program can have vulnerabilities when opening and processing data.

CVE-2012-4170 is an example of an exploit resulting just from the processing of an image.

To gain a better understanding of the RDP protocol:

Summary of RDP on MSDN
A more in depth walk through

In short, there is a lot of data being sent back and forth, and a lot of different and complex processing, there are lots of places an attacker could poke around for an exploit and a compromised or malicious server could send specially crafted packets to be processed by these bugs once found.


Salted password + hash - is it really useful? I am new to the topic and wanted to know the concept of having salted hashes before going down to the technical details.

From what I have understand

password - plaintext
hash password - plaintext password being encrypted by a hashing algorithm that is irreversible (one way)
salted hash password - random text + plain text password being hashed
/ hash (salt+plaintext)
a rainbow table is list of pre-calculated hash results from a list of dictionary words, comparing the hashed passwords against the list in the rainbow table for a match will reveal the actual password being used by the user.

Hence, 2 of the same plaintext passwords will not have the same hash value due to the random value of the salt.

The salt is sometimes stored with hash password.

From the above,

I am assuming that there is no max password attempts - How does having a salt prevent a malicious user from attempting to to brute-force the password into the system by just trying random password (e.g over a dictionary list)? They are using the same legit login mechanism as compared to the actual-user by just attempting/inputting different password per login.
If the salt prevents a rainbow attack by having random data appended to the plaintext before the MD5 hash, the very 1st criteria is that the rainbow attack has a list of hashed (salt+password) to compared with. Now, isn't the system already compromised when the malicious user has that list of hashed passwords?
If the salt and hashed password are stored together, wouldn't that malicious user (instead of using a rainbow table) just recompute his list of dictionary text + the salt retrieved to derive the hash results, and compare them against the hashed password in the retrieved list?

It is just that now the rainbow table is built based on a single salt value for a particular hashed password entry. For another password entry, another precomputed rainbow table based on that associated salt will have to be use.

Is my understanding wrong? So what does salt really help?

From your initial understandings:

A rainbow table is, for a given hash algorithm, an exhaustive map from hash outputs to inputs. Given that the table must cover the entire output range, and that a good hash algorithm makes it difficult to predict input from desired output, and expensive to compute the output, it should be very expensive to generate.

As to your questions:

Salting your hashes does nothing to prevent brute-force attacks against your login page. It instead protects against your (or someone else's, if they're using the same hash algorithm as you) DB being compromised and the attacker knowing the hashes. Once they have the hash, they look it up in the rainbow table to find the input that will generate that hash, and enter that in your login page. It doesn't even matter if the input is not the same as the user's password, as they will both hash to the same value.
As noted above, rainbow tables are expensive to generate.

If you use no salt and a common hash algorithm, the table already exists and all accounts are compromised. This is cheap to do.
If you use 1 salt for all your users or a unique hash algorithm, the attacker will have to generate 1 rainbow table and all accounts are compromised. This is a expensive, but perhaps the payoff of getting all accounts is worth it.
If you use a unique salt for each user, the attacker will have to generate 1 rainbow table for each user, regardless of what algorithm you use. This is expensive, and the payoff is 1 account. Hopefully this is not worthwhile.

Salting does not protect against dictionary attacks

The aim is to make the attacker do as much work as possible, enough that it'll be easier to just find the user (or if the attacker is a very clear thinker, your sysadmin) and beat them with a rubber hose rather than commit non-trivial resources to computing rainbow tables.

As an aside, MD5 is not a good hash algorithm in this context, it is far to quick to compute.


A destructive force can always leak information through HTTP packets. Should I bother configuring outbound rules on my firewall? I know my way around firewalls, but I am in no way a security expert. And recently, I am wondering how to effectively configure the outbound rules of any company's firewall.

For the question's sake, let's assume there is a state-of-the-art antivirus software installed on every client computer and web access is proxied and scanned for virus activity. Let's assume they are perfectly configurated, but an unknown virus, or specifically designed application (that does not require root rights) is executed on the computer in user space.

In theory, I would track all software that is used and configure the firewall to let through destination ports HTTP(S)/80+443, "Message Submission"/587 and IMAPS/993, as well as any destination port, that is necessary for LOB applications.

But that could easily be 10 to 20 destination ports, or more. They would have to be documented and updated, which would cause a great amount of work and is prone to errors, when any malware could just encapsule any information in a HTTP packet and send it to port 80 of the receiving end.

And that were, what I would do: If I were to write a virus to leak company information, or to join them to a botnet, I would not even bother connecting with the receiving/controlling server through port 6667/IRC, as it's usually blocked. I would simply encapsule all information in a HTTP packet and connect to destination port 80/HTTP.

I read about Deep Packet Inspection, but it seems to me, that I would have to know exactly how the destructive packet has to look like. In other words, I would have to create a DPI filter, that is able to differentiate between a file that is legally transferred via HTTP from a user, and a file that is illegally transferred via HTTP from malware.

With this thought, I don't see why I should do any more work on any firewall than allow any service from LAN to WAN.

You're confusing several things.

First, pretty much every standard protocol (save for FTP which you should avoid like plague) has only a handful of standard ports. Since these ports are standards, they will not change often and therefore will not need to be updated.

Now, some applications will require specific ports to be opened, Typically, that's handled through an exception process: the application owner will submit a request to the firewall team for an access to be open. Usually, this request is limited to a specific range of internal systems, going to a specific range of external system with a specific list of ports. This request can then be filled as documentation and, if it is granted, the firewall configuration can be updated accordingly.

But your questions shows that you're approaching this incorrectly. What you're asking would be like asking if locking your home door is worth the effort since you know that some people have access to bulldozers. The proper process for designing a strategy for protection is:

Identify the assets you want to protect
Identify the threats you want them protected against
Identify the proper measures to mitigate those threats
Audit your result
Go back to step 1.

You seem not to do any of these except step 3.


Teaching "Secure by Design" I'm a Security Architect, and I'm used to defining the security of project as a specification that gets carried out by others. I have been recently tasked with teaching new coders how to design and program using the principles of "Secure by Design" (and in the near future "Privacy by Design"). I have 30-45 minutes (yeah, I know), and the talk needs to be language-agnostic. This means I need to present actionable rules than can be applied by the web devs, application devs, and infrastructure devs.

I came up with 5 Basic Rules and a Supplement:

Trust no internal/external input (covers sanitation, buffer overflows, etc.)
Least Privilege for any entity, object or user
Fail "no privilege"
Secure, even if design is known/public
Log so that someone unfamiliar with the system can audit every action

Supplement: If you violate a Rule, prove the mitigation can survive future programmers adding functionality.

Each of those rules can be augmented with examples from any language or application, for specific guidance. I believe this handles most of the general principles of "Secure by Design" from a high-level perspective. Have I missed anything?

The canonical resource for the concept of secure-by-design is "The Protection of Information in Computer Systems" by Saltzer and Schroeder. The essence is distilled into their 8 principles of secure design:

Economy of mechanism
Fail-safe defaults
Complete mediation
Open design
Separation of privilege
Least privilege
Least common mechanism
Psychological acceptability

These principles, laid out in 1974, are still fully applicable today.


Checking if TLS 1.1 and 1.2 implementation in a webserver is upto standards I am testing a webserver[proprietary] which offers SSL support and they say it supports TLS 1.1 and 1.2 which i have verified by firing requests from IE with only the target protocol enabled .

However , how can i check if the TLS protocols implemented in the server are free from known security issues ?

what are the key features to check for ?

Is there a tool which can be used for this purpose ?

This SSL test from SSL Labs covers quite a few properties of TLS.


netcat reverseshell hanging after connection I put a reverse shell on a machine in my lab enviornment and it seems to just hang after there is a connection in netcat - I'm not sure why this is.

I've tried different ports but no luck. See screenshot below - any ideas are much appreciated

I suggest that you try using either ncat or netcat instead of nc.
Plus Ncat support -e function for executing, and i do not think that nc does in the current version.


Considerations when displaying OpenID and WS-* output to an end user I'm creating a "Learn OpenID and WS-*" website and am using all the best practices in making the site secure.

I would like to create a page that decryption the current session's OpenID or WS-* token, and display it in a special diagnostic page.  What should I expose and not expose to prevent a replay attack? I'm not concerned with information disclosure.

Is it sufficient to place it on a HTTPS page accessed using validated POST requests?

My intent in asking this question is to learn how valuable certain fields are in a given authentication response.

What are you wanting to protect against when showing the token? Replay attack? Information disclosure? Etc?

if the site is simply for the sake of testing token handling, then its acceptable to show the whole token as-is because they shouldn't be using a token from a production system.

If an attacker has the full token then they can replay it, allowing them to potentially impersonate the user. They could also replay it against other applications potentially if the token is not encrypted (or the applications share the same decryption key). Also, if the token contains claims with secrets or PII then an attacker could collect that information.

With all that being said, the token is useless for authentication if you strip out the signature (well, assuming the application actually validates the signature).

EDIT: If you want to show the full token but prevent replay attacks, just keep an entry for that token by taking a hash of it. WIF supports the token cache, which is designed partially for that reason, but you'd have to right a custom implementation.


How can I prevent my FTP from being hacked? My FTP was hacked, a file has been uploaded and the host suspended the website temporarily. I'm only using an admin page that points to an .xml file (to load and modify the text of my website). I don't have any databases.

I'm going to add a htaccess/htpasswd, but will it be enough?

How can I protect my FTP so I don't have the same problem in the future?

I wonder how you know that FTP was the method by which the unwanted file was uploaded. FTP is definitely problematic in that it defines no countermeasures against eavesdropping. You can find out about using a different protocol. You could consider the discussion of alternatives at SFTP, FTPS and SecureFTP differences and security implications. You will also want to ensure that you use a strong password (or passphrase). Roughly, a strong password is not in the first billion guesses. That way, if an attacker can find a way to try 100 guesses per second, your password can still resist attack for a month.


Is there any reasonable argument against immediately validating a new customer's email address? Would it not be useful for account providers that allow online/phone signup/ordering to immediately verify the email address supplied to them?
I was forced to ponder this recently when I became the apparent victim of identity theft.  Someone used my name and email address when opening an account with a US-based Internet service provider and placed an order for service at a US mainland street address.  I am neither a US citizen nor live in the US, and do not have any reason to need or want an Internet service there.
I became aware of it when I received two emails; first an "Order Confirmation" followed by a shipping advice for equipment being sent to the street address in question.  I contacted the company via their web "chat" but was advised that my only recourse for cancelling/closing the account was to submit to them via postal mail a compendium of supporting evidence to prove my identity including a comprehensive collection of personal ID (photocopy of driver's licence, proof of address, etc.).  I was dumbfounded to learn that the account/order was placed against my name and email address without any validation of the email address being performed.  It seems to me that if this one simple procedure had been performed then the entire apparent scam could have been thwarted and the company would have avoided aiding the perpetrator and a great deal of personal distress and effort for me could have been averted.
Am I overlooking anything?  Is there a reason why validating a new customer's email address prior to activating a new account and proceeding with order processing isn't a practicable precaution?  I realise that there are circumstances in which it may not be effective, but it would at least have been useful in this scenario and saved a great deal of consternation and wasted time.
Full disclosure: about a week later, after submitting ID theft reports to local and US authorities, and visiting my bank to take measures to ensure my bank accounts would be protected, I spoke with a member of this company's "Security Team" and learned that in this case it appears to have been a genuine mistake.  The customer's name and email address differed to mine by a single letter which was phonetically similar - either the customer had mis-typed their information or had been mis-heard by a phone operator.  The mistaken identity had been resolved on the account - but I had not been informed despite having lodged two complaints with their online customer support.

Sure, they probably don't want to bother people with unnecessary steps. Why would you bother asking them to validate their email address after a lengthy sign-up process with lots of fields already? You want customers to have a good experience and finish signing up for the service without hurdles, who cares if their email address is valid. Worst case you send them a letter, which will have to arrive because the service (in this case) is delivered to a home address. If it's not a valid home address, then it would also be fine to cut the service as there can be no service. The most important detail to the ISP will be the payment details, not whether they're accidentally sending the order confirmation to another email address.
I am sorry you had to deal with this, but I'm not sure there is a definitive answer to this question. Many reasons can be thought of, the most obvious one being usability.


I just found many facebook entries on my registry? I don't have a Facebook account but I was messing with my registry deleting old stuff and I found a bunch of Facebook keys and folders.
Facebook is notorious for being a tool for spy agencies and has poor privacy. So I'm concerned about the entries.

How I can figure out why and what these entries are doing on my system, and why its coming back when I delete them?

That was not the only one, but I already deleted the others. For now it hasn't come back, yet... Still I think it's very weird. I did Google it and couldn't find anything about Facebook creating entries on registry or why, even when you don't have Facebook at all. Also, my OS is Windows 7.

If they keep coming back, it means that you have some software running checks on them. You should take some tool to analyze the running processes on your machine.

Use Process Explorer to look at the current running processes (so that you can find out which one is recreating the reported keys and Autoruns to check the list of programs initiated automatically at startup (search if the above process is configured to startup with windows, or if you have something suspicious installed).

Only by researching the name of the binary you will be able to discover what it does and figure if it should be there or not.

A common source of issues like this is the installation of software that comes bundled with adwares (the ones that have to be unchecked during the "next->next->finish" sequence).


Why include DNS client cookie in DNS server cookie computation? The proposed standard for DNS cookies specifies that the server cookie is to be computed as follows:

  The Server Cookie SHOULD consist of or include a 64-bit or larger
     pseudo-random function of the request source IP address, the request
     Client Cookie, and a secret quantity known only to the server.

The reasoning provided for the inclusion of the client cookie is as follows:

  However, NAT devices sometimes also map ports. This can cause
     multiple DNS requests and responses from multiple internal hosts to
     be mapped to a smaller number of external IP addresses, such as one
     address.  Thus there could be many clients behind a NAT box that
     appear to come from the same source IP address to a server outside
     that NAT box.  If one of these were an attacker (think Zombie or
     Botnet), that behind-NAT attacker could get the Server Cookie for
     some server for the outgoing IP address by just making some random
     request to that server. It could then include that Server Cookie in
     the COOKIE OPT of requests to the server with the forged local IP
     address of some other host and/or client behind the NAT box.
     (Attacker possession of this Server Cookie will not help in forging
     responses to cause cache poisoning as such responses are protected by
     the required Client Cookie.)

  To fix this potential defect, it is necessary to distinguish
     different clients behind a NAT box from the point of view of the
     server. It is for this reason that the Server Cookie is specified as
     a pseudo-random function of both the request source IP address and
     the Client Cookie.  From this inclusion of the Client Cookie in the
     calculation of the Server Cookie, it follows that a stable Client
     Cookie, for any particular server, is needed. If, for example, the
     request ID was included in the calculation of the Client Cookie, it
     would normally change with each request to a particular server.  This
     would mean that each request would have to be sent twice: first to
     learn the new Server Cookie based on this new Client Cookie based on
     the new ID and then again using this new Client Cookie to actually
     get an answer. Thus the input to the Client Cookie computation must
     be limited to the server IP address and one or more things that
     change slowly such as the client secret.

What is the attack that this is supposed to protect against? And how does it achieve said protection?

The three attacks mentioned in the document are:

DNS Amplification Attacks
DNS Server Denial-of-Service
Cache Poisoning and Answer Forgery Attacks

But as far as I can tell the inclusion of client cookie in the server cookie calculation cannot be addressing any of those.

DNS amplification attacks where attacker and victim are behind the same NAT will still be possible. When the attacker has received the server cookie, he can simply start spoofing the IP of the victim while using client cookie and server cookie exchanged with the server previously. Because client and victim are behind the same NAT, the change in client IP address will be invisible to the server. Thus the client cookie still maps to the same server cookie, and the attack will succeed.

In the case of DNS Server DoS, the aim of the cookies is just to ensure that the server will know the correct IP address of whoever is performing the attack. When attacker is behind a NAT, the server will see the IP address of that NAT regardless of what spoofing the attacker performs behind the NAT. And the cookies don't change that.

In the case of forged replies, the protection is provided by the client cookie of the victim which remains unknown to the attacker. So regardless of how the server cookie is computed, this attack would fail. Moreover forged replies are by definition not generated by the server thus there will be no validation of the server cookie anyway.

So if the inclusion of client cookie in server cookie computation isn't done for one of those three reasons, then what is the purpose of it?

If I understand it correctly adding the client IP address to the servers cookie is used to protect against source spoofing attacks against a client which is behind the same NAT as the attacker.
If the server cookie is only associated with the external IP address of the NAT then the internal attacker could make a valid request to the server to get a server cookie which is valid for all clients behind the same NAT. Then the attacker could create a request with the spoofed source IP address set to the internal victims IP address. The NAT gateway will replace the source IP to the external IP when talking to the server. The response from the server will then be forwarded by the NAT gateway back to the alleged sender of the request, i.e. the victim. But since the request contained the server cookie the server assumes that it communicates with an authenticated victim and will switch off amplification protection.
By associating the client cookie with the server cookie and including both client cookie and server cookie in the request the server can validate that the request is really from the same client which got the server cookie before and not some other client behind the same NAT gateway. Only if the attacker is able to get the client cookie he will be able to mount an attack against the client. But to do this the attacker must be able to sniff the network traffic which needs more resources and permissions and is thus explicitly excluded in the attack scenario. From section 9 of the draft:

Security Considerations

DNS Cookies provide a weak form of authentication of DNS requests and responses. In particular, they provide no protection against "on- path" adversaries; that is, they provide no protection against any adversary that can observe the plain text DNS traffic, such as an on- path router, bridge, or any device on an on-path shared link (unless the DNS traffic in question on that path is encrypted).


Directory listing for icons and image folders I am testing web application on Apache server, which allows to list directories such as https://192.168.100.00:443/icons/ and https://192.168.100.00:443/images/. This directories contains only images.

Should I recommend to disallow directory listing for all directories as a best practice?

This totally depends on what the owner of the server wishes to use the directory listing for - there may be a need to have it on.

That said, in many cases directory listing should be turned off if there is no need for it to be on, this is because its a potential vulnerability that could be easily mitigated


AWS serverless architecture compliance with PCI DSS 11.3 penetration testing segmentation I am wondering how to comply with PCI DSS requirements (11.3) to test segmentation controls using penetration testing in AWS serverless architecture.

We are using components such as AWS Lambda, AWS API Gateway, AWS Cloudfront, etc., which are serverless, so there is no OS we can connect to and from which we can start penetration testing.

I was trying to read through AWS documentation regarding PCI responsibilities and there is no mention about segmentation controls. Also in PCI guidance regarding cloud computing there is written that it is client's responsibility to perform segmentation tests.

Is there any idea how to comply with this in AWS serverless architecture?

Very interesting question.

In theory you could deploy your lambda into a VPC, and then your lambda exists on a network segment with other lambdas that are sensitive. But where are you storing your data, backing it up, logging your data? So many questions!

So yes, you'd probably need a pentest, or at least someone to take a long hard look at your serverless environment to ensure no data is leaking out.

Things like:

Is the lambda writing sensitive data out to cloudwatch logs?
Is Cloudfront caching any sensitive cardholder data? Do you have lambda@edge running there that might come in contact with sensitive cardholder data?
Are you backing up the data to S3 -- who has access to that S3 bucket?
Where are you storing data? In RDS, or DynamoDB or a traditional DB. Is that DB on the same network as the lambdas?
Are there any EC2 that are directly connected to/from the lambdas?

In order to run a penetration test on AWS, you need to first explicitly get their permission. Link here


Wired Deauth-Like Attacks [story] Good Evening Guys, I just got out of a lan house which uses a system named Geto (Geto Lan House Management System 4.0), and I was wondering if it is hackable. [/story]

While searching for possible vulnerabilities, I found out that this system works like a RAT, machines are installed as servers running the software, which connects to the client on lan and receive info such as "unlock" and "lock".

So I was thinking, if the "rat-like system" is configured using a local address, and the main host uses a fixed ip address, can I force a reconnect for everyone on the wired network? If so, I could force my internal address to change and force everyone to reconnect on the same address, but this time I would be the "commander".

[idea] I would connect to the wired local network and search for the possible client (controller) machine, after obtaining the ip address, I would launch a deauth-like attack, forcing everyone to obtain a new ip address, during this time I could force my ip address to be X (Which was the client address before). As soon as it's changed, everyone would be reconnecting to this address, which would be now mine, and I would be running the client on my machine, thus "taking-over" all the machines. [/idea]

So here comes my questions:

1- What are the possible flaws on this?

2- Is there any "deauth-like" attacks for wired connections?

All of this is being done assuming the following:

1- The client (Controller) computer is the only one using a fixed ip address.

2- All other computers (servers) are connecting to the client and they don't use a fixed address.

3- I have a machine of my choice (eg. my computer), with total administrator rights connected to the wired (or wireless, which also exchange ips with wired) network.

Thank you and have a good day.
- Fabricio20

  Before anyone says I'm asking for a way to hack the lan-house, I'm not, this is just an idea that came to mind while walking home.

1- What are the possible flaws on this?

That depends on the exact configuration and security measures of the network because to migrate this you will need to mess around with some protocols. I can imagine some ways to migrate this but every solution relies on some protocol weaknesses and the exploitation of these might be detected by an IDS.

On the other hand it might happen that you can't simply "take over" the controll if ssl is used to verify the identity of both sides.

  2- Is there any "deauth-like" attacks for wired connections?

In the way you described it: Yes that can be done by exploiting any protocol weakness that allows a MiTM attack. The only difference is that in this case you don't forward the received information but act as the server that was ment to be reached. In a local network this can be done by one of these attacks for example:

Port-Stealing
APR-Spoofing
DHCP-Rogue-Server (Requires you to be "nearer" at the victim then the real DHCP-Server. Ideally you are connected to the same switch but the DHCP-Server is not.)


How would you totally isolate a laptop from any network? I've been thinking hard about that Faraday's cage, but what if someone needed to use the computer ? Also, the laptop wouldn't be trusty, so you never know exactly what's inside, what could emit information through any network. This would be really helpful in case of audit works, to prevent industrial spying for example.

Put it in a locked room in the basement, remove the hardware that it could use to attach to a network (cat-5 cable, wifi antenna, use a UPS that isolates from mains). Now you have to limit the users ability to attach to some network through the exposed UI, I'd suggest a guard in a separate users room as shown in my previous answer here.


Is Verizon Still Injecting Perma-Cookies into Customer Traffic? This article was published in 2014. Is Verizon still doing this to customer data? It makes sense to assume they are, but I'm hoping for some kind of official news article or something to validate its continued existence.

Despite a 2016 FTC settlement against an advertiser abusing the X-UIDH header and a 2016 FCC settlement (PDF) with Verizon, Verizon's legal pages indicate that it is still in use in some circumstances.

There have been changes to FCC rules within the past couple of years, impact on this issue unknown.

There are some user controls in the form of opt-outs and opt-ins to various Verizon advertising preferences that affect the X-UIDH header:

  Verizon Wireless stops inserting the UIDH after you opt out of the
  Relevant Mobile Advertising program, unless you have also opted in to
  the Selects advertising program. The UIDH will continue to appear for
  a short period of time while we are updating our systems. If you
  choose to participate in Verizon Selects, the UIDH will be present
  even if you have also opted-out of the Relevant Mobile Advertising
  program.

It's only possible for Verizon to inject the header on HTTP traffic. HTTPS (try EFF's HTTPS Everywhere browser add-on to use as much HTTPS as possible), or Tor, or a VPN, will block this behavior.

You can check for the X-UIDH header on any unencrypted (HTTP; not HTTPS) website that displays all of your HTTP request headers.


PREROUTING interfaces SSL MITM I'm trying to make SSL MITM attack but do not really understand how to configure my interfaces to preroute traffic.

I have a laptop, connected to a PC via Ethernet, the PC is connected to the rest of the network vie Ethernet as well.

The PC is running Linux. It has a bridge lets call it mimtbr, and I connected to the bridge the laptop's eth - leth, and the PC's network - pceth.

Then I configure iptables:

sudo iptables -t nat -F
sudo iptables -t nat -A PREROUTING -i leth -p tcp --dport 80 -j REDIRECT --to-ports 8080
sudo iptables -t nat -A PREROUTING -i leth -p tcp --dport 443 -j REDIRECT --to-ports 8443

And on localhost I have a running sslsplit listening ports 8080 and 8443.

And PREROUTING doesn't work. The laptop can connect to any web-site directly.

Can someone suggest me what I'm doing wrong, please.

I didn't work out how to make it with bridges and solved it another way.

Using DHCP daemon I assign to the laptop an IP and redirect all the traffic via PC. In this case I just configure proper NAT and PREROUTING works smooth then.


Encrypt backup files and send them to AWS S3 I have a backup routine via crontab on Ubuntu.
This routine generates a compressed tar.gz file and sends it to AWS S3.

But I want to encrypt these files and be able to decrypt them when necessary on another machine only if I have the private key.

While searching I found gpg, and I execute the command below to compress the backup file:

gpg --output my-backup-file.tar.gz.gpg --encrypt --recipient secret-key-mail-address@example.com my-backup-file.tar.gz

Is this a safe and good way to encrypt these files?

Check out s3cmd.  There is an option to encrypt files on the client side (using keys that are managed on the client side), then copy or sync the encrypted files to s3 buckets.


How is HTTP PUT and DELETE methods insecure, if they really are? If I really need to use these methods, how do i make sure they are secure?

Edit: Is there a link or source where I can see how to make sure that 'PUT' and 'DELETE' methods are not able to delete or update resource, but services and servlets are still able to use PUT and DELETE.

Following services are using PUT and DELETE HTTP methods

https://developers.google.com/drive/v2/reference/files/delete

http://developers.facebook.com/docs/reference/api/Comment/

http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectDELETE.html

http://www.salesforce.com/us/developer/docs/api_rest/index.htm

http://developer.tradeshift.com/rest-api/#tsapi.conventions

http://developer.linkedin.com/documents/groups-api#create

https://developer.paypal.com/webapps/developer/docs/api/#delete-a-stored-credit-card

So, clearly there has to be a way of making sure that PUT and DELETE can be used without putting resource files to harm like HTML, CSS, JS, or images.

PUT and DELETE are not intrinsically insecure, they are used without problems at many REST services for example.

In my practice the main problem related to these HTTP verbs (apart from the common authentication and authorization problems) was that the server operators weren't aware of their existence introducing the possibility of HTTP Verb Tampering. In summary this means that access control was implemented based on a HTTP verb blacklist but some lesser known verbs were missing from this list allowing access control bypass.

I'd like to note that many web servers implement their own custom (sometimes undocumented) HTTP verbs, so this kind of "Verb-Based Access Control" doesn't seem like a very good idea anyway.


What methods are there of protecting a VPS from DDOS attacks? I was just wondering what would be the best way to stop a VPS from being attacked, bandwidth would be a problem in this case so methods that reduce the amount of incoming attacks and stop sending outgoing data would be great. I've been looking for some open source linux projects that can auto detect on an assumption of an attacker however I can't seem to find any success. Just wanted a good idea of some solutions or methods of reducing or stopping a DDOS attack.

There are many OS-level solutions to protect against application- and transport-layer DoS attacks, like SYN cookies, Apache modules, etc. However, to protect against a full bandwidth flood, unfortunately there is little you can do, as it is a function of the pipe of your VPS provider.

One good solution (which will also help you with the other kinds of attacks at the same time) is to point your domain at a DDoS-protection provider like Cloudflare: https://www.cloudflare.com/

They can basically soak up attacks of almost any size. The key, however, is to make sure that no one can determine the real IP address of your server once the domain is behind Cloudflare.


Decrypting Des encryption I am interested in learning different encryption techniques and i am trying to understand one implementation in-particular.  I have set the password in the application and now  want to understand how i got to the result?

password result 5hfGisIwnlQ=

The application uses java.crypto.cipher and DES encryption.

I have found a string called key =
  ucnTRFY<jhvbu,fwy8\u00a3329+3yrwiefDY#FGVoD@IOHa?widNCD(ZH3*82YU9%Fjpo

The application seems to encrypt like this:

  private SecretKey getKey() {
    byte[] desKeyData = new byte[8];
    for (int i = 0; i < 7; ++i) {
        int j = i * 3;
        desKeyData[i] = (byte)(key.charAt(j) ^ key.charAt(j + 2));
    }
    return new SecretKeySpec(desKeyData, "DES");
}

public byte[] encrypt(String password) {
    if (password == null) {
        return null;
    }
    byte[] encryptedBytes = password.getBytes();
    if (!doEncryption) {
        return encryptedBytes;
    }
    SecretKey key = this.getKey();
    try {
        Cipher cipher = Cipher.getInstance("DES");
        cipher.init(1, key);
        byte[] bytes = null;
        try {
            bytes = password.getBytes("UTF-8");
        }
        catch (UnsupportedEncodingException ex) {
            // empty catch block
        }
        encryptedBytes = cipher.doFinal(bytes);
        this.encrypted = true;
    }

and decrypts like this

public String decrypt(byte[] encryptedBytes) {
    if (encryptedBytes == null) {
        return null;
    }
    String password = null;
    try {
        password = new String(encryptedBytes, "UTF-8");
    }
    catch (UnsupportedEncodingException ex) {
        // empty catch block
    }
    if (!doEncryption || !this.encrypted) {
        return password;
    }
    SecretKey key = this.getKey();
    try {
        Cipher cipher = Cipher.getInstance("DES");
        cipher.init(2, key);
        password = new String(cipher.doFinal(encryptedBytes));
    }
    catch (NoSuchAlgorithmException e) {
        logger.error((Object)e);
    }
    catch (InvalidKeyException e) {
        logger.error((Object)e);
    }
    catch (NoSuchPaddingException e) {
        logger.error((Object)e);
    }
    catch (IllegalBlockSizeException e) {
        logger.error((Object)e);
    }
    catch (BadPaddingException e) {
        logger.error((Object)e);
    }
    return password;
}

I am most interested in what this is doing?  private SecretKey getKey()  And that the arguments are in here cipher.init(2, key)?

Before this I implemented an application using Bcrypt. What are the advantages and disadvantages of each method?
FYI this is how i implemented Bcrypt. if (BCrypt.checkpw(userId.getText() + passwordfield.getText(), passwordhashadmin)

This code is very bad.  If you're copying it from elsewhere, you need to stop doing so.  If you're writing it yourself, well, you shouldn't use it in any system that's actually security critical—you should seek expert assistance if that's the goal.  The only justifiable purpose to code like this is as an educational exercise.

Let's dive in to the problems.

Use of obsolete and insecure DES cipher

DES is a 1970s cipher with 56-bit keys.  That is much too small a keyspace for security; brute force search of DES keys was already demonstrated over 20 years ago.

Hardcoded cryptographic key?

  I have found a string called key =  ucnTRFY<jhvbu,fwy8\u00a3329+3yrwiefDY#FGVoD@IOHa?widNCD(ZH3*82YU9%Fjpo

If this is a string constant in a real-world program, then that's really terrible.  Programs should never hardcode cryptographic keys; they should read them at runtime from secure storage.  The only scenario where it's acceptable to have a hardcoded key like that is in a trivial demo program.

Even if the string comes from a file instead of being hardcoded, the fact that you're able to read it already should make you wonder whether it was adequately protected.  If it's a secret key, how come I'm reading it on the interwebs?

Obfuscated/convoluted key deserialization

DES takes its key as a byte[8].  The program computes that byte[8] from the key string in a really convoluted manner:

private SecretKey getKey() {
    byte[] desKeyData = new byte[8];
    for (int i = 0; i < 7; ++i) {
        int j = i * 3;
        desKeyData[i] = (byte)(key.charAt(j) ^ key.charAt(j + 2));
    }
    return new SecretKeySpec(desKeyData, "DES");
}

This doesn't do anything other than make the code needlessly complicated.  A well-written real-world program would obtain the desKeyData by reading it directly from a binary file or by deserializing it from a string representation of a binary array (e.g. hexadecimal digits, Base64).

Passwords should not be encrypted

The code is encrypting a password.  This is an insecure method of password storage.  See the top answer to of our top passwords questions, "How to securely hash passwords?".  That should answer your question about bcrypt as well.

Use of insecure cipher mode

This line of code:

Cipher cipher = Cipher.getInstance("DES");

...initializes the Cipher object in ECB ("electronic codebook") mode.  This is almost without an exception a bad idea.

Unauthenticated encryption

As a general rule, you should only use ciphers that protect both the authenticity and confidentiality of the messages.  Modern ciphers protect not only against an attacker reading the content of the messages, but also against forgeries.

ECB mode doesn't do that.  And you'll find lots of example code using modes like CBC that don't do so either.

Use of numeric literal instead of mode constant

This line is needlessly hard to read:

cipher.init(1, key);

It should be this:

cipher.init(Cipher.ENCRYPT_MODE, key);

Bad exception handling

Lots of lines like these:

catch (UnsupportedEncodingException ex) {
   // empty catch block
}

Or these:

catch (BadPaddingException e) {
    logger.error((Object)e);
}
return password;

Security-critical code needs to be exceptionally clean.  If anything fails you should generally assume the worst and cause the whole operation to fail, not swallow an exception and keep going like nothing wrong happened.

(Also, that upcast to Object in the second example is trivial and can be removed.)

Code discipline (method contracts, state avoidance, type safety)

All that logic with the doEncryption and encrypted boolean fields makes me nervous.  It sounds like this code is inside a class whose objects can be in four states:

Contains encrypted data, does encryption/decryption when requested to
Contains unencrypted data, does encryption/decryption when requested to
Contains encrypted data, ignores encryption/decryption requests
Contains unecrypted data, ignores encryption/decryption requests

...and the class's methods and external clients then have to be mindful about its state so as not to expose an unencrypted password by mistake.  The following bit of code in the encrypt() method is the most symptomatic example:

if (!doEncryption) {
    return encryptedBytes;
}

So if I'm using this class and I call encrypt(mySuperSecretData) method, it might actually not encrypt it at all?  What is the contract of the class and the methods?  Is that contract really confusing or allow for the class's clients to easily misuse it?

Why have such a complicated class with these many self-defeating options?  Maybe instead you should have separate types PlaintextPassword and ScrambledPassword so that when you try to pass a PlaintextPassword to a piece of code that expects a ScrambledPassword, it become an error at compilation time and not a security failure.  With careful design and discipline you can gain much greater confidence that the program will not expose sensitive data by mistake.

This is part of the same theme as the previous point: security-critical code needs to be exceptionally clean.  If I have to pause and read carefully the if statements and a || b conditions across those two methods to figure out whether there's a risk that they were incorrectly written and will reveal secret information in some scenarios, then I have to ask whether all that logic can just be removed.

Conclusion

This is the wrong level from which to approach cryptography.  If you're interested in practical uses of cryptography, you should seek out a good, high-level cryptographic library that offers an easy interface, with good, safe default choices made for you an really good documentation that you can count on to tell you exactly how to use it.

The default Java cryptography API isn't that. Java has lots of cryptography support, but it all tends to be terribly hard and dangerous to use.  It requires a lot of knowledge to use it safely, and that knowledge cannot be acquired by tinkering around with random code samples that you find somewhere—because if they're not just flat-out wrong, they're at least often outdated and no longer reflect best practices.  Learning to use Java cryptography APIs generally requires reading third party materials that allow you to understand sound cryptography fundamentals.


Good file encryption tools Could you please help me find a good file encryption tool? The target OS is Linux, but tools for Windows are welcome, too. FOSS tools are preferred. The tool must be reliable both for the recovery of the original data (on decryption) and security-wise. The encrypted file is to be used only by myself.
It would be very nice if the tool had a slow and/or a resource-intensive password derivation scheme like the used in bcrypt, scrypt or KeePass.

Notes:

I'm not interested in an encrypted filesystem.
I'm not interested in an encrypted (virtual or not) disk or partition.
Plausible deniability is not an issue.

Additional question: considering that the encrypted files could be made available freely online, some problems arise (eg the evolution of the computational power). What other security measures (besides the encryption per se) would you advise to be taken (eg password/key lenght, tool configuration etc)?

Because encrypted files are not compressible, the most useful place to put encryption is in a compression program; that way you can compress the content and then encrypt it.

Modern tools generally use well-vetted algorithms such as AES. Avoid classic ZIP encryption because it uses a bad algorithm. 7-zip is a great tool because it's FOSS, cross-platform, and very widely recognized. It uses 256-bit AES, which is currently "unbreakable" enough that a brute-force attack is the most efficient attack algorithm.

7-zip, including encryption, can be integrated into GNOME's built-in archive manager (and may be installed already!), making the whole process largely transparent. The p7zip command handles command-line access. The file extension is .7z


What is the name of the crypto system used by ICANN's DNS recovery system? I once heard about a type of crypto system that behaves in the following way: I have x secret keys that work together to decrypt messages encrypted with a public key d. If I get at least n of the x secret keys together, I can decrypt messages encrypted with d in their entirety. If I have anything less than n, I get no information about those messages.
When this system was being described to me, I was told that an example of this system in the real world is ICANN's system for recovering the DNS registry in the event of some catastrophic failure. In their case, x = 7.
I heard about this a little while ago, and I don't remember exactly what the system is called. I have tried to research it with the ICANN website, but I can't seem to find an actual name of the system that I can use to then do a deeper dive into this. Does anyone know the name of the system I just described? Also, since I am trying to dive rather deeply into this, I would also appreciate any resources (research papers, open-source implementations, additional real-world examples, etc.) that could be listed.
Thank you!

IANA operation details on the root key ceremonies and procedures are at https://www.iana.org/dnssec
You may be interested by section §4.2.2 of https://www.iana.org/dnssec/dps/ksk-operator/ksk-dps.txt
   Access to and management of cryptographic hardware is based on the
   principle of successive barriers in three tiers, requiring at least
   seven trusted persons from four different roles.  These barriers are
   as follows:

   Tier 5:
         Physical access to safe room requires one person from the Key
         Ceremony Administrator role in combination with one person from
         the Internal Witness roles.

   Tier 6:
         Physical access to cryptographic hardware (HSM) and activation
         material requires one out of two of the Safe Security
         Controller #1s, and one out of the two Safe Security Controller
         #2s in addition to the Trusted Persons required at Tier 5 and
         7.

   Tier 7:
         Activation of a HSM requires three out of seven Crypto Officers
         to extract activation material from above safe deposit boxes
         using their physical key.  Safe deposit box operation that
         involves opening of any one of the deposit box requires three
         out of seven Crypto Officers to be present.

   Restoration of the contents of a HSM requires at least six trusted
   persons from two different roles, as follows:

   Secret share:
         Reconstruction of the secret key used for encryption of the
         application keys requires five out of seven Recovery Key Share
         Holders.

   Encrypted application keys:
         Physical access to the encrypted application keys requires one
         person from the Ceremony Administrators role, one person from

And section §5.2.2:
5.2.2.  Private key (m-of-n) multi-person control

   The RZ KSK Operator has implemented technical and procedural
   mechanisms that require the participation of multiple trusted
   individuals to perform sensitive cryptographic operations.  The RZ
   KSK Operator splits activation data needed to make use of the RZ KSK
   private key onto separate smartcards controlled by trusted
   individuals (Crypto Officers) selected from members of the Internet
   community not already part of root zone management operations.
   Specifically, organizationally separate parties, not affiliated with
   PTI, ICANN or Verisign.

   A threshold number of smartcards (m) out of the total number of
   smartcards created and distributed for a particular hardware security
   module (n) is required to activate a RZ KSK private key stored on the
   module.  The threshold number of cards needed to sign using the RZ
   KSK is three out of seven.  The smartcards are protected in
   accordance with Section 5.4.2.

Typically, when you create a key on an HSM, you can generate various Officers access to it, and decide how many of them will be required to unlock the private key. You can find example at Standards for secure key backup of master keys with secret sharing
Note that is it not about "for recovering the DNS registry  in the event of some catastrophic failure. "
DNSSEC adds cryptography in the DNS in the sense that each zones signs its records with some key and some (other) key are stored in the parent and so on until the root. IANA (ICANN) handles the root procedure-wise and for the ceremonies and such, while Verisign manages the day to day operations of it (technically of the A root nameserver, which is the one from which all other ones derive their configuration).
So the question is more around how the root key is protected, and what happens when it is lost. But even outside of those edge cases, the root key ceremonies also need multiple crypto officers to unlock the key when it is needed (twice per year). You will see in mainstream media sensationalist articles about the 7 people to have the keys to the Internet (example of such bad writing: https://www.theguardian.com/technology/2014/feb/28/seven-people-keys-worldwide-internet-security-web), while https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/ will give you both a more accurate description with more real technical details.
You can see at https://www.iana.org/dnssec/tcrs the current list of crypto officers (needed for bi annual key rotation ceremonies) and the "recovery key share holders".
The first one are needed to just unlock the private key, the second ones to reconstruct it if it gets lost/damaged/unrecoverable/etc., per §5.2.4:
5.2.4.  Private key backup

   Encrypted copies of the RZ KSK private key(s) are backed up onto
   portable media held by the RZ KSK Operator and sent by courier to the
   other facilities.  The key used to encrypt the private key(s) is
   backed up using a five out of seven threshold scheme with smartcards
   distributed to trusted individuals (Recovery Key Share Holders)
   selected from members of the Internet community not already part of
   root zone management operations (specifically, organizationally
   separate parties, not affiliated with PTI, ICANN or Verisign).  The
   Recovery Key Share Holders keep the cards in tamper-evident bags,
   stored in geographically dispersed locations under their control.


NSS / OpenSSL tradeoff on an embedded linux application which uses a TPM via pkcs11? I am on a trade-off between the use of OpenSSL or NSS in an embedded Linux application that makes use of a TPM (HSM).

EDIT: I need a SSH server and Apache using TLS, both using the keys protected by the TPM.

I am looking for satisfying the following constraints:

Good support of PKCS#11 (at least management of Elliptic Curve keys)
Not too many dependencies
Cross compilation friendly

As far as I could find, NSS natively supports PKCS#11, and OpenSSL needs an external engine, libengine-pkcs11-openssl, which supports only RSA keys. So an OpenSSL choice would lead me to add functionalities to this engine. Are there other PKCS11 engines available for OpenSSL with better support than this one?

Concerning dependencies, NSS requires the Netscape Portable Runtime (NSPR). In total, NSS and its dependencies have 2.5 x more lines of code than OpenSSL. This is a drawback and possibly a show-stopper for embedded applications, except if parts of it useless for the application can be easily dropped from the compilation via some defines. Is it possible?

Concerning cross-compilation, the wikipedia comparison says NSS is cumbersome. Does someone have a how-to to propose or a link please?

More generally, advice of people having experienced one or both of them with a TPM is welcome.

Depending on what you are trying to do, you might get away with using neither NSS nor OpenSSL. PKCS#11 is an API that provides functions for running cryptographic primitives over keys; it is conceivable to use that API directly instead of through an extra library.

You would need NSS or OpenSSL if you need some non-PKCS#11 functionality, e.g. support of X.509 certificates or SSL. But if your application only calls for, say, raw signatures, then using PKCS#11 directly can be a reasonable thing to do.

As for lines of code, they don't nearly matter as much as binary size for embedded systems. The ratio of lines of code to binary size is not fixed; it depends on language, coding style, amount of comments, auto-generated code upon compilation... In fact, the fastest way to get the information you seek is probably to try both library (and possibly the no-library option) and see for yourself how well they fit your environment, compilation process and size constraints.


Reusing the IV, but not the key There are a few questions on this site asking about reusing the same initialization vector for example for AES encryption under the same key, see for example this question.
Now, let's not respect that advice and reuse an IV. However, to make it a bit more complicated, let's use a different key. For example both of these keys could be derived from a password using different salts or similar methods.
Is it safe to reuse an IV for different keys? For example, does that compromise the plaintext message or the keys?

Whether using a fixed IV is acceptable depends on the mode of operation you're using.  Some modes only require that the IV be unique under a given key, such as CTR mode, while others, such as CBC, require an unpredictable IV.  Attacks on CBC are known with predictable IVs.
The adaptive chosen plaintext attack mentioned exposes the plaintext, but not the keys.  In general, a secure block cipher itself should not be vulnerable to exposing the keys even if some correspondence between the plaintext and ciphertext is known, which is usually what happens with IV misuse.  I'm not personally aware of any common AEAD modes which require an unpredictable IV, but in general IV misuse with AEAD modes can compromise both confidentiality (expose the plaintext) and integrity (permit tampering).
The easiest way to avoid reusing an IV in this way is to take the random value you would normally use for the key and run it through a key derivation function (KDF), like HKDF, to derive both a secret key and an IV.  If you're already using a password-based KDF to generate the key, you can also generally generate the IV using the same KDF.  Since this is so easy to do, there's little reason to reuse an IV in a practical environment.


Concerns about a typical JWT setup From my understanding, the current standard when using JWTs for user sessions is to have a short-lived (expires after maybe 15 minutes) access token and a long-lived refresh token (expires after 24+ hours) which can be used to obtain more access tokens.
There seems to be a handful of reasons for this, the main ones being:

To decrease server load regarding authentication and session management.
To prevent an attacker from having long term access if they somehow obtain an access token.
To prevent new access tokens by revoking refresh tokens.

My concerns are:

Why do people think 15 minutes is short enough to prevent an attacker from doing whatever they want? A lot of damage can be done in 15 minutes.
If an attacker can obtain an access token, then they can most likely obtain a refresh token as well. This would allow them to obtain any as many access tokens as they need (until someone figures out that the refresh token has been compromised).

Am I missing something here? Or are JWTs not really meant for security? Are they really only meant to decrease server load?

Access and Refresh Tokens (which aren't always JWTs) provide an additional layer of security and usually related to access.
As for your concerns, the expiry is not a sole defense against an attacker. You still need to enforce encrypted communication and secure storage of the tokens.
That is, if you have an attacker who gained access to your system in away that they can read your credentials, it's game over. No matter what kind of tokens you use. Even 5 seconds are plenty of time for a scripted attack.
The expiry serves two purposes:

It forces the system to re-interact with the identity and access management. This allows you to invalidate not-yet-expired Tokens from the Server Side (for example, if the User changes their password or clickt an Sign-me-out-everywhere button).

And it ensure that if you forget to explicitly invalidate them, they expire automatically.

A setup with Access and Refresh Tokens, as for example defined by the OAuth 2.0 Framework, provides additional security if implemented correctly.
You only need your Username and Password on an explicit login. Your client software (App or Browser) should never store these, as they are the keys to the kingdom. For example, your Google Username and Password allows you to access Mail, Calendar, Dokuments, App Store and all other Services provided by Google.
Access and Refresh tokens, on the other hand, can be scoped: they give you only access to a subset of the services you can normally access. An Access Token could be limited to use with email. If an attacker gained access to that token, they still can't access your Calendar, for example.
JWTs on the other hand are usually used as an Id Token, where you want to get more information on the user accessing the resource.  Have a look at the documentation on the Auth0 Website on Tokens. The differences of the tokens are subtle.


How to decide what information should be shown to an user? For instance:

Object ids (e.g. users ids)
emails
Addresses, are part of them
Photos
Videos
Usage
Reviews
Number of associations
etc.

The user can be:

The user owning the data
Another user
An anonymous user

The application is:

A community of users separated in groups that can interact with the users of the other groups

Does anybody have a general pattern/rule to identity what should be published and what should not?

Like commented by @tim this is a very broad question. I think it boils down to two things:

Look at the privacy laws in your region (GDPR in Europe for example). These are legally binding and should always be adhered to especially when talking about personal data (like combination name, birthdate, address). These laws normally (and should) contain the want for a privacy statement that explains what data is stored and how the data is used/shared. These laws always include what I will say in part 2.
Principle of least privilege (or how you would say that for data) should apply. Everything you show publicly (and everything that you store!) you should ask yourself: "Do I need to show it for correct use of my application?"

So actually read the law (or articles that summarize it) and try to limit what you show and do not hide behind the: "they gave the data voluntarily so it is mine now to do with whatever I want!".

Further, your explanation of the application is a bit vague so I am not sure what it should do. But let's answer the more detailed questions:

After adhering to point 1 and 2 all data that you need and a user has provided you can be shown to the user that owns that data.
If you want to share videos/photos or other personal media you can but be sure to have a clear privacy statement that explains the who and how of data sharing.
I would say never share anything with anonymous users. Unless it is the whole idea of the application then again clearly state it in your privacy statement.
Never share: addresses or phone numbers, and I would say do not store them unless absolutely necessary.
E-mail addresses: make those opt-in to share. So a button that someone can choose to share this (default is OFF)

I hope this helps you google around for templates and how other sites have implemented their privacy (-by-desing), here are some links:

GDPR wikipedia

Privacy policy/statement template


Should users need to complete a CAPTCHA upon changing their password in their account settings? On Last.fm, I need to complete a CAPTCHA in order to change my password. I want to change my password because haveibeenpwned lists my account as appearing in the last.fm breach. However, the CAPTCHA appears to be impossible to solve, so I had to forfeit the account instead (deleting my account does not require a CAPTCHA). This made me wonder:

Why should one have to fill out a CAPTCHA in the first place, when one already logged in successfully and is just trying to change their password? What attack does it prevent?

As mentioned by AndrolGenhald, it could be to provent automated takeover of accounts with compromised credentials. Even without the last.fm breach, I imagine that whenever credentials are breached for any site, robots try out the credentials on a bunch of different websites, possibly including last.fm (this is why it's bad to reuse credentials).

While last.fm, like other sites, could put a captcha on their login page, it would be much more inconvient since users typically log in much more often than they reset their passwords.

In the end, they are blocking robots from doing the thing that would be the easiest to automatically do to hacked accounts: reset the password


Is it secure not to have csrf protection in login forms? I have noticed that WordPress doesn't have csrf protection for their admin panel login /wp-admin/. Does it actually posses any potential risk? Is there any possible ways there an attacker could exploit this?

Is it necessary to have csrf tokens for login forms?

It is generally suggested that CSRF tokens are applied to login forms to prevent session donation attacks. The idea is that you can trick a user into visiting a link, and they become logged in under an account that you control. They then perform some action involving storing some secret information to the account, without noticing they're logged in as you, and that gets saved to your account.

A simple example might be a file upload site. If you can trick them into being logged in as you, they might upload a sensitive file into your account rather than theirs, and you can then steal that file.

For Wordpress this probably isn't so big a deal, because it's not particularly applicable to the functionality that Wordpress provides, and the wp-admin panel isn't really a "general user" area that an attacker would have a valid account for.


Can a TPM chip check if the bios is still in it's factory setting? Can TPM (trusted platform module) be used to verify if a used laptop's bios, the bootloader and related components have not been tampered with in the past, i. e. whether those components are still in their factory setting state? Or can a TPM only detect whether there has been a change with those components after it has been activated (by me)?

A TPM can only tell if the BIOS and related components have been changed since the TPM was activated. If something has been changed, it can't tell what was changed or when it was changed, nor can it tell if the BIOS was tampered with before the TPM was first activated.


How long does it take after a card is skimmed (unknowingly) at an ATM for the thief to be able to steal cash from the account? My 21-year-old college sophomore daughter's SECU checking account debit card was skimmed 2 weeks ago at an ATM.  She realized it the next day when she tried to use her debit card for a gas purchase.

She withdrew $20 the night before at an ATM with her card and somebody else withdrew $200 right after her.  She reported the missing money, shut down the account and cancelled her debit card immediately when she realized it.  She made a police report and the SECU called when they had the ATM photos for her to view.  The first photo was of her using the ATM and the second photo showed a man she'd never seen before.  The SECU had already captioned the second photo: "Girl hands card to guy to use".  She was outraged.  She asked me to go back with her to see the photos and the caption was still there.  The bank reps actually told me twice that there was absolutely NO OTHER WAY for anyone to get money from my daughter's account unless they had her card in their hand and knew her pin number.  I asked the question twice because I had heard a little about skimming fraud and knew this WAS possible.  I have since then read everything I can get my hands on about the topic but still have a question I am hoping you will answer for me....  Because the second withdrawal (and photo of unknown male) was recorded exactly one minute after the $20 withdrawal my daughter made (and her photo recorded) the SECU says that there is NO WAY that this was a skimming incident.  They say that this could not take place in one minute and that the card had to have been handed over to this unknown male by my daughter.  End of story.  She is absolutely furious and humiliated.  I am furious!!

I cannot help but think that if someone has devised a way to retract credit or debit card info and use it for their own purchases, that it is certainly possible that the transaction time can be manipulated as well.  I have also learned that it is during these late Saturday night/Sunday morn weekend hours that the computers are backing up/processing transactions and that often the time recorded is off.  Am I right or wrong in my assumptions?  Is it possible for a thief to skim a card at an ATM and retrieve money from the account recorded only one minute after the valid owner of the account used the card??

I very much appreciate any knowledge you might share with me concerning this matter!

Here is what I think happened.

Two conditions which are found often around universities:

This is ATM at which you swipe your card and the card remains in your possession while the transaction occurs on the screen. This is not the kind which eats the card and keeps it and spits it back out at you.
The ATM software after giving cash for withdrawal and printing a receipt -- resulting in me the user thinking the transaction is done -- then asks "would you like another transaction?"

I've seen this before and I've pointed out to people this behavior when I use the machine behind them.

What happened is that this 1 minute later person was waiting for someone to walk away with the screen on the "would you like another transaction?" prompt. They approach and say yes and can withdrawal money from the account.

There is no skimming required for this type of theft.


Malware-like site opening from within Facebook When I visit a link to an external site (like Huffpost) from within Facebook, I get redirected to a scammer site after scrolling a little bit.

Notice the URLs eu.unitize370vu.pw and eu.jargonize22bt.pw.

I am confident not having a virus on my phone, I don't install every app and nothing from unknown sources. What is this and where is it coming from?

I am using the latest and up to date Android.

It is a bit hard to believe that if your phone is infected, they'd need to show you ads. They can do far worse things. :)

If you're using FB in a browser, it could be one of two things:

It could be AdTech going bad (i.e., some advertising network
injecting ads).
ISPs are known to intercept traffic to inject ads
too.

I would try a different browser. I recommend FireFox Focus (a fairly new browser) as a remedy for such Ad nuisance.


User Authentication for a public website in 2015 I am creating a new website for online shopping in .net and was wondering if i have another option beside Forms authentication to validate the users in a safe and secure way (this has been around for a while, haven't we upgraded yet?).
Keeping in mind tomorrow if i am extending my services on mobile and other devices how easy it would be to reuse same stuff?

If i have to use Forms authentication what are my options to implement it (is it only the default .net forms auth)?

Thanks,
Raman

Authentication by forms is still the norm. However, you may want to consider allowing your users to take advantage of a single sign solution.

For instance:

OpenId
Try rolling your own SAML (a single sign on protocol) based solution.

Keep in mind that this just let's your user share their sign in with another service. At some point they will have to sign in with a form somehow.

Or in some cases, it may be appropriate to auth cryptographically via private keys and the like. For instance, Github offers an option to authenticate via a private key. If this appropriate for your set up, you will most likely already know.

I also urge you to consider the option of allowing two factor authentication. Again, this does not obviate the need for a form authentication, but will make your form log-in's much safer.


Irreversible hashing without collision We are looking to allow users to log on with a smart card. The smart card reader can read the smart card ID and send it to us.

We are, however, not allowed to store the smart card ID. Not in plaintext, not in a reversible encoding. An irreversible hashing is allowed.

Then again, we need to make sure that each ID hashes to a unique result, as to avoid collisions.

How can we satisfy both unique and irreversible properties?

For a hash to be collision free, each unique input would need to map to a unique output. If each output is unique, that means it can be reverse-mapped to a unique input. That would not be hashing, that would just be an encoding. Collision-free and non-reversibility are mutually exclusive by definition.

The important point is how likely a collision is, and the answer for modern hashes is negligibly unlikely. If the output key space is larger than the input key space, you're extremely unlikely to ever find a collision, and even if it's not it's still so unlikely as to not be worth considering in the real world.

I would guess though that those smart card ids aren't very complex, likely decimal numbers all of the same length (e.g. 1234567890). That means there aren't that many possible inputs and it's probably possible to calculate the hashes of all possible ids in a feasible amount of time, creating a lookup table to reverse the hashes. If that's the case, you'll want to be using a slow hash like bcrypt, scrypt, PBKDF2 etc. to make this infeasible.

The more I think about it the less the requirement makes sense. The secret here should be between the card and the reader, and the trust needs to be between the reader and the system it's connected to. Why is it a security problem if the id of a card is known? What can somebody do with this id if he obtains it? If the answer is that the id is a secret and somebody can do whatever he wants if he knows the id number, that's poor security. The security here should come from the fact that one needs to have physical possession of the card, which means the secrets are all between the card and the reader. Beyond that there's only an authenticated user with an id, which is a simple necessity to make the system work.


Zlib DEFLATE decompression bomb Can you give me an example of a short data string that, when decompressed using Zlib's DEFLATE method, expands to something much much longer?

More precisely: what is the nastiest decompression bomb that one can build for Zlib's DEFLATE?  The figure of merit here is the compression ratio.  If the compressed file is n bytes long, and after decompression it yields something m bytes long, then the compression ratio is m/n.  I am looking for something that maximizes the compression ratio, where hopefully the compressed data is very short.  Can anyone give me an example of such a decompression bomb?

Related: This post claims that DEFLATE can asymptotically approach a compression ratio of 1032; is that the best one can do, or can one achieve a higher compression ratio if we pick a carefully chosen sequence of compressed bytes?  Libpng defends against decompression bombs by imposing resource limits, but they don't give a concrete example of a specific decompression bomb.  See also zip bombs, the corresponding attack but for the ZIP file format.

The source of the "1032:1" figure is given on the zlib site where it is told that:

  The limit comes from the fact that one length/distance pair can represent at most 258 output bytes. A length requires at least one bit and a distance requires at least one bit, so two bits in can give 258 bytes out, or eight bits in give 1032 bytes out. A dynamic block has no length restriction, so you could get arbitrarily close to the limit of 1032:1.

This is a quote from Mark Adler, one of the two designers of zlib. Having myself implemented a library for Deflate, I can confirm that, given how the algorithm works, this asymptotic limit is indeed true (you cannot go beyond, but you can get as close as you wish). Deflate works by encoding "copies": each element is either a new byte, or a copy of a past sequence; copies can overlap (i.e. you can copy a sequence of length 30 at distance 4, yielding 15 times the past sequence of 4 bytes); Huffman codes are applied on the sequence of elements. To get a minimal length "copy" you need it to overlap a lot, and each copy is worth at most 258 bytes. So the data which is to be compressed will have to be a long string of identical bytes.

As @Steffen says, compressing with gzip a long sequence of zeros will yield a more than 1000:1 compression ratio. It does not have to be zeros; any sequence consisting of the same byte value over and over will do the trick; but a Linux machine has a /dev/zero, not a /dev/fortytwo.

"Compression bombs" were already active quite a long time ago; I saw it employed to kill Netscape back in 1996 (at that time, Netscape handled background pictures, but Mosaic did not; a very small GIF file could encode a huge background, which Netscape allocated as a single big pixmap in the X11 server).


Source port and destination port Just fiddling with wireshark and telegram as part of some learning exercise on security.

I realised that the source port for the telegram app is 58939 and the destination port would be 443.

Why is that so? Is it even possible to port forward the packets to port 443 from my telegram app to fiddler which can decrypt https packets?

58939 is one of the 'ephemeral ports' these are used for specific connections between client and server so only 1 of the ports is limited (the destination) and not 2 (even besides the fact that 443 is below the 1024 Root only limit of ports)

your second question is one of not understanding your tools. fiddler can be operated as a proxy. so you can do this 'intercept' simply by configuring your proxy. (a.k.a. a classic case of not following the ancient wisdom of 'RTFM'


Are dialers obsolete? My antivirus picked up an infection by Dialer/Coulomb. The definition of a dialer is a piece of malware that dials a number that charges money. How would it do this, is this from when modems were connected to the phone lines? Can this still happen if the computer is connected through wi-fi to a cable modem?

If you don't have a modem attached to a phone line then the "dialer" is harmless, but nothing tells you that it's only a dialer and not a general-purpose rootkit/remote administration tool.

Note that mobile broadband cards (either as external USB devices or built-in) still appear as a modem and most of them can do phone calls, so if you have mobile broadband then it may still use your mobile subscription to call the number (which may be even worse because calls from mobile are usually more expensive).

Better safe than sorry, so my advice is to follow this guide and reinstall.


Determining if System or Network was scanned with a Network or Vulnerability Scanner Everywhere I read is to be careful using network scanners and that vulnerability scanners should only be used in active reconnaissance as  scanners tend to be noisy.

How would a network administrator or security technician determine if one of these scanners was used? Could this be determined using log files or programs such as packet analyzers?

I have tried searching but I have had trouble finding anything on this. Mostly all I can find is on conducting such scans.

You can detect them with Intrusion Detection Systems if it's network being scanned.

If it's web server, you can look into access log and grep for errors.

Example IDS is Snort. It can run passively by reading forwarded packets from switch (switch port mirroring), or it can be in front of the network (act as a router).

For experimentation, Snort can be installed on the server itself although this one is not recommended


Multiple passwords with hashing To protect passwords a website uses a hashing function before storing the password (This is just an example of a very simple hash function):

f(x) = x mod 10

Passwords are hashed before they are stored in the database and then when a user logs in the password input field is hashed and compared with the one in the database.

If the user's password is 17, then 17 mod 10 = 7 is what is stored in the database. If the user types in 17 when logging in then it will hash to 7 and work correctly. However, couldn't 27, 37, 47 ... wouldn't there be lots of passwords also hash to 7 so they would correctly authenticate?

All hash functions - except perfect hash functions - have collisions, because hashing normally maps a larger set of inputs to a smaller set of outputs.

That being said, mod 10 is an awful function for hashing passwords as the amount of collisions are unacceptable in practice.

Apart from that, it is also unacceptable because it is too fast, and because it is incredibly easy to find a matching input (because you can just use the hash as password, it will always match). You can also not really reduce collisions by increasing the divisor. If you would eg set it to 1000, all input less than 1000 wouldn't actually change.

This is a nice example that not all hash functions are acceptable as cryptographic hash functions.

Cryptographic hash functions need to be preimage resistance, second preimage resistance, and collision resistance.

mod is none of those:

Pre-image resistance: Given a hash h, it should be difficult to find any password p such that h = h(p). It's not. p = h will always work.
Second pre-image resistance: Given a password p1, it should be difficult to find another password p2 such that h(p1) = h(p2). It's not. p2 = p1 + divisor will work.
Collision resistance: It should be difficult to find two passwords p1 and p2 such that h(p1) = h(p2). It's obviously not, given the two previous points.

For acceptable functions, see How to securely hash passwords?.


Multiple people have the same iPhone IP address I am an admin of an immigration forum. Security is my job One and protecting our members's info is my highest priority. Recently, I discover that there are 3 members who have posted from the same IP addresse and the same iPhone browser info. My questions,

Is it possible that different people would have the same IP address for their iPhones?
Can different people have the same iPhone plan would have the same IP address?
I can find out the location of an IP address of the iPhone, but does that mean the owner resides at that location?

They could be using a network carrier which does not assign an unique IP address to each user but instead has only one external IP and uses Network Address Translation to allow multiple users to browse the web with that address. Such providers are quite rare in North America and Europe, but more common in other parts of the world.

There are countries where iPhones are sold exclusively with a plan by a single carrier. In that case all iPhone users from that country would have the same ISP and when that ISP uses NAT, also the same IP address.

In that case, a geoIP database would give you the location of their provider. These databases have very varying accuracy anyway. For my current IP address, all databases I tried return just the city I live in, which has a population of over a million.

Another explanation for multiple users sharing the same IP could be that they are using the same proxy server for anonymity. But having the same mobile phone and also using the same proxy service would be quite a coincidence.

bottom-line: There is a possibility that you are dealing with different people. However, it would be quite a coincidence. When you have other reason to believe that you are dealing with one user with multiple identities, it is quite likely to be the case.


Conducting Ethical Phishing Attack For research purposes, I'm conducting an ethical phishing attack in my institution. I have permission from the institution for the same. I've created the phishing site and the email content, and I'll be recording who and how many users visited the phishing site. I intend to send links to a phishing website in the email like this.

Where do I host this site and how do I send this email?

I've seen some free hosting sites. Do email providers give low reputation to such free hosting sites?

Also, for sending the email, should I choose popular email service providers like gmail, hotmail or should I use disposable email? What will increase the chances of the email reaching the users?

This question is, in part, “How do I get my phishing emails past spam detection?”  Answering that isn't really in our best interest and you shouldn't spend too much time on it.  Instead, get your sending server whitelisted locally so your test is not run through any spam filters.

The easiest solution is to use a well-known testing agency like Cofense PhishMe, Wombat, or KnowBe4, and they'll do the heavy lifting and walk you through the rest.  This may not be ideal if you have a really small budget and/or if this is part of a student project.

A good in-house phishing test must

Have permission:

Approval from an executive or director, not just IT or Engineering
Relevant infosec and netops teams should sign off on this test

Use external servers:

Send the test from an external IP address range
Bypass anti-spam scanning by whitelisting the test's sending IP(s)

Identify itself as a phishing test in its headers:

Add an X-PHISHTEST header with your contact info for escalations
Leaving this indicator allows security groups to safely ignore reports  The X-PHISHTEST header triggers a “phishing attack” verdict in some spam detection solutions and prevents the “free pass” for reported phishing reports from meddling with real attack detection.  Note the need for whitelisting above.

Have a good landing site:

Consider a vanity domain like <institution>-support.com
Embed each user address in the link's query string
Log users' clicks and the IPs they clicked from for your report
Tell users that they fell for your trap and educate them
Link or host content similar to the APWG's Stop.Think.Connect.
Reveal the test at the document root or without a query stringso security researchers can understand your intent

Bad phishing tests

Will get into trouble with testers' management
Can get larger accounts suspended
Might get caught as spam and therefore fail to reach the targets
Risk annoying yet not educating the user base
Will confuse anti-spam filters when trained as phishing

Answers to your specific questions

Where do I host this site and how do I send this email?

So long as you follow the above rules about a good test and a good landing site, you shouldn't run into problems. As noted above, it is a good idea to alert your network operators (this includes your web hosting company) before you conduct this test.

I've seen some free hosting sites. Do email providers give low reputation to such free hosting sites?

You're probably referring to spam detection systems, which are nowadays extraordinarily complex, pulling in as much metadata as possible and combining it all with lots of secret sauce and machine learning. You really want to bypass spam detection with whitelisting. Client-side anti-spam is rarely powerful enough to discriminate in the manner you're worrying about.

Also, for sending the email, should I choose popular email service providers like gmail, hotmail or should I use disposable email? What will increase the chances of the email reaching the users?

Again, you need to bypass anti-spam, at which point much of this doesn't matter. A cheap vanity domain like <institution>-support.com likely comes with the ability to send within your provider's hosted environment.

I consider GMail and Hotmail to be disposable. Many penetration tests register accounts like <institution>-support@gmail.com and use good friendly from names like <institution> Support (which is the only thing mobile email clients display).


KeePass - Backup to Telegram? I am looking for ways to backup my KeePass file to prevent loss. Of course, I saved it to my computer and my phone. But what if I lose access to my computer and my phone at once? Where should I back it up? Telegram seems to be the best solution! I can send the file to myself and only thing I need to access my Telegram account is my SIM card - which - if I lose it - can be replaced by my operator. What do you think about it?

For the course of this answer I am going to assume that Telegram actually does store your files for you (in cleartext) and actually allows you the recovery using a new valid SIM card for an indefinite period of time. When in doubt contact the Telegram support and ask for clarification.

Yes, this works and would be secure.

KeePass databases are encrypted and authenticated files which can only be unlocked given the correct set of credentials (e.g. keyfile, password, ...), thereby storing it at an untrusted location is perfectly fine.

However, I'd recommend a more involved backup solution. The first step would be to backup a specifically crafted KeePass file on Telegram, which only contains your credentials for standard backup targets (e.g. dropbox, google drive, AWS S3, ...) and can be secrured using your normal master password.  The next step is to setup automatic backups in your normal KeePass database to those locations. This has the advantage that you can recover your password database in case you lost all your physical backups but also provides an easy-to-use solution which doesn't force you to do a database backup by hand upon each change.


Can a compromised car stereo spread vulnerability to a connected phone via bluetooth I have an older cheapo JVC car stereo with bluetooth.  I used an app to check for Blueborne vulnerability ("Blueborne Vulnerability Scanner," no longer available) which said the stereo was high risk.  It is very unlikely to get any kind of software update to protect against Blueborne, due to its age.  (I don't know if they even built in a way to update firmware.)  It has no network connection except the bluetooth, but it does have permission to access my phone's contacts, phone and call history.  The stereo has the option to run Pandora and iHeartRadio, but I have never set up the internet connection that would be necessary for those to work.

Clarification:  This stereo is an aftermarket module that doesn't interact with the car in any way except receiving power, driving the speakers,  and detecting the headlights on/off status through a dedicated line tat older cars have for that single purpose.  I am not concerned about blueborne compromising my car - just my phone.

Question:  Is it possible that someone could inject malware into my phone via an attack on the stereo?  Is it realistic?

It's possible, but it would depend on a lot of factors:
Most cars have two different processing units - one for the music system itself and a second for the car's internals - brakes, gauges etc. In many cars, there's no connection between the main audio player and the car itself - just power cables. This makes it possible for you to replace the music system that your car shipped with with another one. In this case, it's also likely that there won't be any external control for the music system's controls - this means no controls for volume on your steering wheel etc.

However, in the off chance that your manufacturer has your car rigged up to a central processing unit, and has all the devices in the car controlled by it, there's a pretty good chance that someone could really mess your car up by exploiting the Bluetooth vulnerability. Even if they aren't able to execute commands remotely, a DoS condition in a vehicle that you put your life in isn't very comforting.

So to summarize:

Look out for any connections between the player and the car's systems themselves. You can do this by just checking to see if you can control the car from your music player or the player from controls that are not directly on it.
If you can, physically remove the unit from its dock and check to see if there's any wires that aren't just supplying power. If there are, they mostly go to your car's internal processor and are likely a threat.


Is it possible to prevent WiFi password brute-forcing? Are there any measures I can set, except using a better password, to prevent someone brute-forcing a WiFi password?

Yes, Not using a Password would negate all brute forcing of the password...

But if you do I would recommend that you instead setup a Kerberos Network authentication setup with TLS certificates (and LDAP). But this would be a lot harder than just use a simple password exchange.


Google Authenticator - Counter Based I'm trying to understand How google authenticator - counter based work. I have tried googling around finding a demo or at least how this work. I understand its a one time password but not like TOTP. I am already working on TOTP but i'm terribly having issue with time sync, because i'm working on an offline PC. So the windows time - well every 2 days or so the time keep shifting two or three seconds ahead.

Anyways, I am looking for a PHP code for HOTP counter based . I have found one or two examples but they have so many missing files.

Please, I would like to find a tutorial about that in PHP language or at least a basic idea to start with.
BTW i found this http://www.ietf.org/rfc/rfc4226.txt  .

TOTP is indeed a time-based variant of HOTP. In both cases, the sequence of possible passwords is derived from a secret key, and a "changing value". With TOTP, the "changing value" is the current time, which both ends of the protocol supposedly know (current time is public knowledge). In HOTP, the "changing value" is a counter, which is incremented after usage. Both parties (client and server) remember the last used counter value.

If the client and server become desynchronized (e.g. the client sent a password and incremented its counter, but a network issue killed the connection and the server never received it), then there is a process for resynchronization: upon receiving a password, the server compares it not with the next password (according to its counter), but with the next 100 or so passwords, thus allowing for a counter desynchronization of a 100 or so.

This mechanism is well suited to car keys, which:

Do not have a common source of time (no clock in the key).
Need to work with a unidirectional communication (from key to car, not the other way round).
Have a "manual resynchronization" if they got badly out of sync (your 3 years old nephew played with the key for an entire afternoon, getting the key counter way beyond the car counter, even with the +100 offset; you can no longer open the car remotely; but when you ignite the engine, the car and the key communicate through short-range RF to reset the counters).

As for code, a simple google request on "hotp php" points to this and that.