LastPass Key Derivation Security Question I have done some research about password managers and of course stumbled upon LastPass. There are plenty of questions and answers about the security of LastPass, but as far as I am aware none of them talked directly about this specific implementation. When I read this I was quite surprised

  LastPass has opted to use SHA-256, a slower hashing algorithm that provides more protection against brute-force attacks. LastPass utilizes the PBKDF2 function implemented with SHA-256 to turn your master password into your encryption key. LastPass performs x number of rounds of the function to create the encryption key, before a single additional round of PBKDF2 is done to create your login hash.

This is how it should work (if understood correctly) according to their Website

Use PBKDF2 on the Master-Password, with the username as salt
Iterate at least 5000 times (or higher if configured)
Master Key is the result of the iterations
Do one additional round of PBKDF2 and send this to the server for authentication
Server does additional 100.000 rounds of PBKDF2 with a different salt
& scrypt with unknown parameter since the security breach
Store and/or compare in/with Database (use HSM for some part here or under 5.)
Send reply to client with vault (encrypted)
Client decrypts with Master Key

While in theory everything is nice and secure, we know LastPass had security breaches in the past. The Master Key is only hashed one more round before being send to LastPast. Assuming that an attacker could potentially get access to LastPass infrastructure and read the values received before step 5.), does this significantly endanger the Master Key?

I would think maybe, but we cannot do a dictionary attack on the key, so the classic attack vector on PBKDF2 does not apply. Unless we have really strong custom hardware, so that we can do a dictionary attack on the master password, despite the 5000 rounds.
But on the other hand being just one round away from the Master Key seems a little too close for comfort.

Is there any realistic threat for the Master Key under such circumstances?

First, keep in mind that 99.99...% of sites transmit your password to the server in clear-text over (over an SSL connection, of course). There the server actually has your clear-text password during authentication. So even that one hash increases security.

Taking a step back, the reason that we perform numerous rounds for hashing or key derivation for passwords is that we are going from a relatively small set of possible inputs (ie: passwords chosen by us dumb users). As the set size is small, you need to increase computational expense of a dictionary or brute-force attack by making the calculation of each hash (much) more costly. We do this by repeating the hash over and over.

In the Lastpass situation that you ask about, the input to the hash is the output of another hash. So the input space is relatively well distributed across the full 256 bits. At least it will be after you salt the passwords (without salt this would be susceptible to a pre-compute attack). That means that a brute-force attack would have to test the full 256 bit space to reverse the one hash. This is too large for precomputation attacks (eg: use of rainbow tables).

Now if an attack is developed that allows you to reverse SHA-256, that would increase the risk in this situation, along with many, many others.


What kind of damage does the HummingBad Android malware do when it fails to gain root access? There is this Android virus out there called HummingBad, and it seems the first thing it tries to do is try to get root access.

There are so many device models out there, and the rooting process is different for each model. Even white hat hackers struggle sometimes when trying to find exploits to root a certain device. Therefore, I assume that HummingBad sometimes succeeds and sometimes fails in gaining root access.

When it fails, what kind of damage does it still do?

Let's say someone installs an infected APK with HummingBad. It tries, and fails, to get root access.

Can the failed exploits it has attempted still damage the firmware in some way, even if root access didn't ensue?

Does the virus have any "Plan B" to just be a "normal" Android malware, without root access?

In the case of HummingBad, if rooting fails, the next step is an attempt to socially engineer the user into giving it the required access by posing as an Android update.


Entering payment information in Android Apps I'm concerned how android apps that integrate payment processing deal with secure financial information.When purchasing through these apps the apps show the Webpage of the bank asking for credentials.
The page is same as the one which opens when we pay through the Web browser,but there the data is secured by HTTPS.
We never know if the app uses HTTPS and can the app read the password or CC info we enter into the page shown in the app UI.

Thoughts?

If the app opens the payment page within the app, there is no way of knowing whether this is actually a HTTPS secured page or whether it is an unsecure site or even just part of the app itself which may grab your details and send them off to the malicious developer of the app.

The same goes for apps that ask for your Facebook details in order to login.

At the end of the day, you have to trust that the app is not tricking you into entering your details.


Could an OS or app store and send my old IP after I start using a VPN? If I connect to a VPN, go to some websites, post something or browse something, is it possible for my OS (Windows 10) in this case to:

Store my IP before I connected to the VPN, say "old IP".
Get my new IP after I connect.
Send both to some servers which log all internet traffic so it could match me up thus destroying any kind of anonymity.

Does this kind of simple leak have a name? Should I assume it happens? How would I prevent against it?

Is it possible?

Yes. From context, I can tell you mean the public IP address(es) of your network (vs. RFC 1918 LAN IP). Since that isn't actually stored anywhere on your computer, determining this requires an active approach: the OS/app would connect to a peer on the Internet (could be microsoft.com in the case of Windows) in order to ask: "What address do you see me coming from?" STUN uses this approach. A less accurate method (pinpoint you to a region instead of a particular IP) that doesn't require coordination with some Internet server could be an early-aborted traceroute to obtain the IP of your ISP's last-mile hop.

Does this have a name?

Probably not. I'd call it some sort of "leak" like you did. It certainly hurts privacy.

Should I assume it happens?

Probably not for Windows. There's no reasonable way to do this without generating obvious network packets that draw attention. Even encrypted packets draw suspicion if they're headed somewhere you didn't authorize. Windows 10 does send a lot of data to the mother ship, but server-side client fingerprinting across ad networks for the sites you browse are more robust attacks against your privacy; note that a VPN is no use against browser/OS/user-agent/behavior fingerprinting.
You are also probably safe from this behavior if you use an open-source app/OS, as you (or the community at large) can review the code for anything nefarious. You can't do this for closed source code, so anything could theoretically be there.

How would I prevent against it?

The attack isn't very commonplace because it's fragile and risky compared to alternatives. If you pinpoint the servers or protocols used in the exfiltration, you could block the traffic using a host firewall (or your network firewall, if you can't trust your OS).


IP Spoofing between subnets I'm new PT.

In a test I was required to do,
I was given a port in the segment of 172.13.x.x. I was asked to test if I'm able to reach a server at 172.16.x.x.
I was wondering (considering there's either a router/ layer-3 switch / firewall !), if it is possible to inject packets using IP Spoofing to other networks.

For example, if I spoof the "source" IP to an IP of the segment 172.16.x.x, will spoofing work? Will injected packets reach to 172.16.x.x? Will I receive packets back?

There are actually 3-4 questions in your post, and they can mostly be answered with just networking answers.

  if I spoof the "source" IP to an IP of the segment 172.16.x.x, will spoofing work?

It depends what you mean by "work", but the principle of spoofing is to fake packet and see what happens. You can fake what you want, the idea will be then to properly analyze how the network reacts and if there is any possible weakness in this reaction.

  Will injected packets reach to 172.16.x.x?

Possibly.

Normally, if properly configured when receiving a packet the layer-3 device connecting the two LANs should check if the source IP address is expected on this incoming interface.

Normally, and depending on the exact topology, it should detect that no packets with source IP 172.16.x.x should be received on the interface connected to the 172.13.0.0/16 network and react accordingly (drop the packet for instance).

However, this layer-3 device may be wrongly configured and could therefore allow such packets.

  Will I receive packets back?

By doing only what you describe, this one is a no for sure: the layer-3 device will have strictly no reason to route a packet with a destination IP 172.16.x.x to its 172.13.0.0/16 interface.

If you are required to be on the 172.16.0.0/16 network to reach the server, this would either mostly restrict you to UDP attacks (if the layer-3 device does not correctly check source IPs) or find a way to convince the device that you are a legitimate route toward other hosts belonging to the 172.16.0.0/16 network (which would very heavily depend on the exact network devices and configuration, but for instance facing poorly managed switches you can try to exploit some layer-2 attack and jump onto the VLAN associated to the 172.16.0.0/16 network).


Can any password hash ever be secure? My understanding is the the main reason MD5 is insecure, is that it can be calculated too quickly, allowing too many attempts to be tried. People recommend instead using a hash that has been designed to be deliberately slow, to provide better security.

However, that only provides security at the current computational speed. Once computers become faster, then these will be no better than md5. So I wonder, is it even possible to have a hash function that is secure, irrespective of the time it takes to execute?

So I wonder, is it even possible to have a hash function that is secure, irrespective of the time it takes to execute?

No, of course not. Think of a hash function as something that takes in any string and outputs a short fingerprint of that string. If I have a computer fast enough to list all possible strings and compute their fingerprints (aka hash values), then I can build a lookup table mapping every hash value back to the string that produces it. With an infinitely fast computer with infinitely large memory I can build a lookup table which breaks any hash function, even theoretical ones. Period.

For a real hash function like SHA2 which has a 256-bit output, assume you were magically handed that lookup table for all 2256 possible outputs, and assume it takes you 25 ms to perform each hash, it would take you 6.7x1057 x age of the universe just to verify that the lookup table is correct. Now, if instead of being handed the lookup table, you had to compute it yourself through trial-and-error, that number would be even bigger. So yes, all hash functions can be broken by a "really fast computer", but like really really really fast, like ages of the universe faster than any computer that we have today. [As pointed out by @BlueRaja-DannyPflughoeft in comments, getting enough electricity to do this computation would require consuming several stars so it's not physically possible for a pre-interstellar society]

The reason that attacks are tractable on modern hash functions, which forces us to do tricks like salt&iterate to make them slower, is that for things like passwords you don't need to check all 2256 possible pre-images. If everybody used random password generators then this would be true, but people don't ... in fact 1.5% of us (1 out of every 68 people) use the password "123456" (source). So you only need to check things that people commonly use as passwords. A list of the 100k most common passwords will get you almost all the users on the internet, which a modest computer can check in a few minutes if they are only hashed once. We compensate for people's weak passwords by making each hash computation take longer. If they are salted&hashed 10,000 times then that few minutes on modest hardware goes up to months on a custom GPU rig.

In summary; a lot of the problems we have with hashes aren't because the hashes themselves are weak, but because we're asking them to protect data which is easy to guess.


Cacheable HTTPS Response CVSS https://portswigger.net/kb/issues/00700100_cacheable-https-response

Applications should return caching directives instructing browsers not to store local copies of any sensitive data

Which CVSS vector I should assign to a web application which use Cache-Control: private for anything (also sessionID and pages with personal sensitive information)?

I think this would be fitting:
CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time.

Unless you have another exploit to access the computer, you'll need physical access. It's fairly easy to do and doesn't require PR or UI.
Let me know what you think.


Storing CardHolder Data using RC2 encryption I would like to know if storing credit cardholder data using RC2 encryption requires to be compliant with PCI DSS. Currently the 16 digit PAN number and expiry date is stored in the database. The PAN number is encrypted before storing and the site uses SSL to transmit the data to the payment gateway. Do we still need to comply with PCI DSS Requirements if we store encrypted cardholder data???

Yes, if you receive, transmit, or store cardholder data in any form, you are required to comply with PCI-DSS.  In fact, one of the things that you're required to do under PCI-DSS is encrypt that data using strong encryption.   Though I am not a PCI auditor, I would suspect that RC2 would not, if fact, be considered strong encryption, so not only are you subject to PCI-DSS, you may be violating it as well.


Why is there a "des-ede3-cbc" in my rsa private key? I have created an OpenSSL RSA private key and certificate request with 4096 bit with the following command:

openssl req -newkey 4096

When I view the private key with

openssl asn1parse -in privkey

I get the following output:

    0:d=0  hl=4 l=2446 cons: SEQUENCE
    4:d=1  hl=2 l=  64 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :PBES2
    17:d=2  hl=2 l=  51 cons: SEQUENCE
    19:d=3  hl=2 l=  27 cons: SEQUENCE
    21:d=4  hl=2 l=   9 prim: OBJECT            :PBKDF2
    32:d=4  hl=2 l=  14 cons: SEQUENCE
    34:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXX
    44:d=5  hl=2 l=   2 prim: INTEGER           :0800
    48:d=3  hl=2 l=  20 cons: SEQUENCE
    50:d=4  hl=2 l=   8 prim: OBJECT            :des-ede3-cbc

What bothers me is the part with des-ede3-cbc. Why is there des-ede3-cbc in my RSA private key? As far as I know "DES" is an encryption standard from the seventies and it's considered broken.

Your private key is encrypted with Triple DES. While DES is easily broken, Triple DES is safe for now, especially in this context. AES was made to replace Triple DES not so much because Triple DES was broken, but because it was way too slow. In the context of private key encryption, a non issue.


UTF-7 XSS attacks in modern browsers I've recently read Ned Batchelders article on UTF-7 XSS-attacks. I tested his examples, but could not get any UTF-7 attack to work in modern browsers. I tried recent versions of Firefox, Chrome and Safari so far.

I know that Chrome has some XSS-attack prevention mechanisms but to my experience, Firefox has a more "generous" mechanism of executing javascript, even when it's broken - however, none of these browsers seems to select the UTF-7 charset by default if the site is using (but not explicitly declaring) it.

So: Does anybody know why this is not working anymore? It seems that the UTF-7 detection mechanism has changed, maybe even for security reasons? Can UTF-7 attacks still target modern browsers if there is no way to change charset declaration within the document or manipulate the headers?

This exploit is only possible in old versions of Internet Explorer. Modern browsers will not auto detect the encoding as UTF-7.

OWASP:-

  This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported.

Wikipedia:-

  To mitigate this problem systems should perform decoding before validation and should avoid attempting to autodetect UTF-7.
  Older versions of Internet Explorer can be tricked into interpreting the page as UTF-7.


The safest way to circumventing Iran's Internet censorship We usually buy services like VPN, SOCKS, Kerio [Kerio Connect?]... to circumvent Iran's Internet censorship policy.
Recently, one of the shops started selling [one of] Kerio's products, for which I do not understand what it is.

My question is: Can the people that I buy Kerio's products from see my data? By these people I'm referring to the seller in the shop [we purchased the product from]. Would they have access to the server [we setup using products they sell]?

I'm asking this because the seller is in this case our government, and we purchase these tools from their agents so we can freely access the Internet, and they can easily monitor us and catch those they consider as offenders.

Editor's note: parts in square brackets [] are my addition, the rest is edited for grammatical and readability reasons, while trying to retain question's original meaning. In case of parts of my edits being unclear, please refer to the previous revision by clicking here, or on the timestamp of the last edit.

The Onion Router (tor) was designed specifically for this purpose.

This is a program that you run locally that provides a socks proxy,  which allows you to access an unfiltered, and anonymous connection to the open internet.  It is very difficult for governments to prevent you from accessing tor.


Can malware physically damage a hard drive? I recently responded to an incident of supposed malware infection. The symptoms were simply, "My computer freezes at random times." The response ended with replacement of the physical hard drive and re-imaging the machine.

Later, I forensically imaged the 'broken' hard drive and have ran several malware detection scans with no hits (just two simple tracking cookies). I'm not much of a hardware guy but it does seem the physical HDD was just worn out (it is over 6 years old).

This experience leads me to the question of whether a virus or other malware can physically damage a hard drive. I know of Stuxnet but am unaware of - shall we say - consumer grade malware. Can anyone point me to resources that explain the feasibility and challenges involved with physically damaging a hard drive from malware?

You can definitely brick a HDD or SSD by flashing it with incorrect or corrupt firmware.  Most drives will accept firmware updates while in use.

Of course a sufficiently determined person can probably repair the damage, but in most cases this would be written off as a drive failure and the drive replaced.


Import Wireshark Cookies into Firefox? I'm trying to copy session cookies (collected using Wireshark) into a different Firefox sessions. But can't seem to find a method or working add-on to manage the cookies.

Greasemonkey and tampermonkey's "cookie injector" userscripts don't seem to work. Many other FF add-on's either require JSON format, Netscape format (output formats Wireshark doesn't support) or the cookie add-on's don't feature the ability to import cookies at all.

Is it currently possible to import cookies (collected using Wireshark) using Firefox?

References:

https://addons.mozilla.org/en-US/firefox/addon/tampermonkey/
https://www.youtube.com/results?search_query=wireshark+cookies
https://github.com/ihciah/cookieinjector

UPDATE:

It seems if there aren't cookies set already, I can't right-click on any of the parameters (Name, Path, Domain) to add data. Only if there are cookies already present it's possible to "Delete All" or "Add Item". Is there a solution for adding cookies using Storage when no cookies are present?

As Matthew said, you can directly set the cookies with the document.cookies="..." command in your browser console.

Example on security.stackexchange.com:

As you can see, I am not logged in. I cheated a bit and directly retrieved my cookie through my browser, and not through wireshark, but your question is about setting it once retrieved.

Cookie Name  |  Value
acct         |  t=7c6483ddcd99eb112c060ecbe0543e86&s=080f651e3fcca17df3a47c2cecfcb880

To set it, you can use the document.cookies="{COOKIE_NAME}={VALUE}" command, like I did on the picture above. You need to repeat this command for any cookie you want to set.

I just need to refresh the page, and the cookie will authenticate me.

Here, the Storage tab shows the cookies that have been set.

Note that other security controls may be put in place to prevent cookie theft, like checking other information associated with the user. (Browser, IP, etc.) It is the case here, I couldn't do much before being deauthenticated.


How was (is?) the ping of death attack possible with IPv4? While reading about Internet Protocol, I found myself reading about ping of death attacks: the thing that attracted my curiosity was the fact that these attacks could ever work!

I mean, why wasn't IPv4 packet dropping (for packets larger than 56 byte + header) immediately implemented on computer systems? Was/is there a reason for a host to receive a packet larger than 84 byte total?

There are many reasons why packet dropping isn't implemented. One example is that there is a technology known as jumbo frames, which allows for up to 9000 bytes of payload. These are primarily supported on LANs where large amounts of data are moved around, and where the repetitive nature of headers is unnecessary.

It's also worth noting that most packets are larger than 56 bytes + header. The standard Ethernet frame size is 1500 bytes. If you are referring solely to ICMP packets, it would be possible to implement such a restriction, but why? There are valid use cases for wanting larger ICMP packets. Having a network stack that properly handles non-standard packets is generally more desirable than having a network stack that arbitrarily limits functionality.


Is windows 7 vulnerable to null session? My lecturer told me that Windows 7 is not vulnerable to null session but did not explain why. What is the preventive measure that windows 7 did to protect against from it?
The recommend fixes for Windows 2000 and XP are to make the following changes:

For Windows 2000:

HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous=2

For Windows XP:
Network Access: Do not allow anonymous enumeration of SAM accounts: Enabled (Default)
Network Access: Do not allow anonymous enumeration of SAM accounts and shares: Enabled

The same configuration items for Windows 7 are set as:

HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous=0

Network Access: Do not allow anonymous enumeration of SAM accounts: Enabled (Default)
Network Access: Do not allow anonymous enumeration of SAM accounts and shares: Disabled

Since only one of the three setting changes match I would expect it to still be vulnerable. In that case, why is Windows 7 not vulnerable to null sessions? Any enlightenment?

Back in the day, null sessions were a major issue. The problem with null sessions is the ability to arbitrarily glean usernames from a system, then try password combinations via bruteforce until you manage to log in. Once done, badness ensues - anything you wish to do can be done.

As you can see on your Windows 7 system:

  Network Access: Do not allow anonymous enumeration of SAM accounts: Enabled (Default)

Your SAM database (user/password list) cannot be enumerated via a null session, whereas:

  Network Access: Do not allow anonymous enumeration of SAM accounts and shares: Disabled

Your Windows shares can. This is not the end of the world - without authenticating, all a null session can do is enumerate these shares (unless you've altered your ntfs permissions). That said, if you're feeling paranoid, you can always turn it on. Finally, this switch:

  HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous=0

Is a bit more complicated. In Windows, there's a group called "Everyone" which with this setting contains the "Anonymous" (unauthenticated) users. This switch basically allows you to share without authentication, which you sometimes want to do.

Switch it to 2, and "anonymous" no longer belongs to "everyone". More here.

Ultimately, null sessions are a problem where they allow enumeration of users and groups without authentication. Beyond this, null sessions (or unauthenticated sharing) becomes a risk depending on whether you're prepared to allow anonymous share enumeration (and use) or not.

So in the classic sense, no, Windows 7 is not vulnerable to null session attacks.


Authenticating Certificate for School Wifi My school wifi, which requires me to login using ny username and password, is requiring that I accept a certificate in order to connect. I don’t know if this is a trusted root certification but what does this certificate enable them to do? Does this mean they can run man in the middle attacks and decrypt my https searches and stuff? Any help will be appreciated, thanks.!! i had asked this question on the wrong platform earlier. this is the certificate they are asking me to accept

As the image you shared indicates, this is simply the certificate used for client authentication.

Basically, your device is performing an 802.1X authentication to connect to the network. This uses an EAP method to authenticate to a RADIUS server, most of the common ones establish a TLS tunnel between the client and server to protect the user credentials.

When the EAP supplicant (i.e. client) begins the authentication with the RADIUS server, the server begins by providing it's certificate to the client. The client then needs to determine if it is going to send the credentials to the server.

Since your device is not actually connected to the network until after you authenticate, there are only limited ways it can validate the certificate and server is valid. In the case of your OS, it is prompting you for validation that this is the server you want to send your credentials.

Accepting simply allows your client to continue the authentication process. It is not installing any sort of certificate (CA or otherwise) on your device.

  I don’t know if this is a trusted root certification but what does this certificate enable them to do?

It doesn't allow them to do anything. It allows your client to continue authenticating.


Nmap scan what does STATE=filtered mean? When I scanned a host for open ports I came across the following result:
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
3306/tcp open     mysql

What does filtered mean?

Filtered is described in the NMAP Reference Guide, Chapter 15:

  Nmap cannot determine whether the port is open because packet
  filtering prevents its probes from reaching the port. The filtering
  could be from a dedicated firewall device, router rules, or host-based
  firewall software. These ports frustrate attackers because they
  provide so little information. Sometimes they respond with ICMP error
  messages such as type 3 code 13 (destination unreachable:
  communication administratively prohibited), but filters that simply
  drop probes without responding are far more common. This forces Nmap
  to retry several times just in case the probe was dropped due to
  network congestion rather than filtering. This slows down the scan
  dramatically.

Long story short - Filtered means you cannot access the port from your scanning location, but this doesn't mean the port is closed on the system itself. Closed on the other hand would mean, you can reach the port, but it is actually closed.


is there a two developer minimum for companies seeking PCI compliance? I'm doing a questionnaire for PCI compliance and one of the questions (Yes / No / Not Applicable) is as follows:

All custom application code changes are reviewed (either using manual
or automated processes) prior to release to production or customers in
order to identify any potential coding vulnerability as follows:

Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices.

So I guess in order to be PCI compliant a company must have at least two developers? 'cause that's sure what it looks like...
Another question (Yes / No / Not Applicable) seems to re-enforce this notion:

Change control processes and procedures are followed for all changes to system components. There are separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.

As @schroeder points out, 3rd parties can perform secure code review.  And Production environment practices are better handled by operations staff, not developers - in fact, other regulations like SOX restrict developers from Production access.
So it is possible to be PCI compliant with one developer.  The overall requirements of PCI DSS will be difficult for a small (one- or several-person) shop.


How can I find the IP address of someone who is using a vpn? I have a friend who is being threatened by anonymous accounts threatening blackmail. I have gotten multiple ip addresses from an iPhone, all 1 number off, from this person but they were stupid enough to tell me the vpn they use (widscribe).

I would recommend contacting local police and reporting that incident as well as contacting other international authorities. Usually, such threats are being fought by special cyber units.
I would not recommend contacting the blackmailers or reacting to their provocations. Just compose a descriptive detailed report and send it to the police.
Sometimes criminals are waiting for the victim to make such mistakes to exploit those mistakes against them, so be careful with contacting them or threatening them.


Do any third party time stamping signature services exist? I'm wondering if there exists any trusted third-party service that I can submit a file, or just a signature of a file, and get back a signature of that file signed with the timestamp of when it was signed.

Does any such service exist?

I'm not looking for something complicated like a block chain - just a simple service that uses GPG or something similar.

A line from a build script I used a few years ago:

signtool sign /v /f <REDACTED> /p <REDACTED> /fd sha256 /t http://timestamp.verisign.com/scripts/timstamp.dll %1

That is, using the Windows SDK's signtool.exe to request that Verisign (now Symantec) timestamp the signature of the file I was compiling. Ironically, the domain timestamp.verisign.com is unavailable over HTTPS (although this doesn't really matter; no meaningfully sensitive data was being passed and I could of course verify the timestamp signature against a known key).

You may be able to find other public timestamping authorities; that's just one I was shown by somebody else working on a similar problem. Also, note that signtool.exe has a separate parameter (/tr vs. /t) for RFC 3161 URLs, which suggests that the URL I provided is not RFC 3161 compliant.


How can an access point spoof me into connecting? I was reading through the answers of the question "How can I ensure that I connect to the right wireless Access Point?" and was wondering how it is possible for an access point to imitate another wifi network assuming I use WPA2.

I read the wikipedia article and it looks like that the PMK (Pairwise Master Key) is never actually send over the network. Also, the client station sends a Nonce to the access point, which the access point concatenates with the PMK and hashes to produce an authentication. How could an impostor produce a valid authentication without knowing the PMK?

What am I missing?

EDIT: I read a little further through the comments and it seems like I can only fake a wireless access point, if I actually have the PMK. Can somebody confirm, that I have the right idea?

I'm going to go out on a limb here and could be wrong, but...

If there are two APs using the same encryption level and the same passphrase, then I believe most wireless clients will happily connect to either without raising a fuss.  I do not believe that the equivalent of an SSH host key is used to fingerprint the original "authentic" AP.

Therefore, if an attacker knows the passphrase in use by an AP, they can imitate that AP and either hijack traffic or perform a man-in-the-middle attack.

I am reasonably sure that this was my experience when I temporarily configured a second AP in my house with the same passphrase, using XP and Windows 7 clients.

It may be that the protocol supports an AP host key, but that the Windows client implementation does not take advantage of it.  As I say, I'm going out on a limb here, basing my response on limited experience which I recall hazily.  I'm sure someone will let me know if I'm wrong!


How email sent with S/MIME are stored? I use Outlook to send email. In order to encrypt them, I use S/MIME with a signed certificate. I don't find the answer on how the storage of the email I send is performed.
First option as I am the expeditor, the email is stored in clear on my computer.
Second, I create an encrypted version of the email for me and I stored the email encrypted.
Do you have an idea ?

The email is encrypted for both, the recipient as well as the sender. So the same email can be read by either the recipient or the sender.
In more detail, S/MIME (just like PGP) encrypts the email with a symmetric cipher using a random key, then that key gets encrypted using a asymmetric cipher using the public key of all recipients as well as the sender. These encrypted keys are then stored as part as the email.
This is true for any email app, not only Outlook.


Facebook POST request capture I have been trying to test a sniff on facebook POST request forms using wireshark (filtered HTTP).

At login form, I would try login, and then check wireshark and see that no packet was captured.

Strange enough, even the GET request of www.facebook.com wasn't always captured.

Why is this? if wireshark can't capture a POST request packet being sent to facebook, then how does facebook receive any data to process?
Note: Trying the same on hotmail, and also fail.

I am suspecting some sort of encryption is performed on the data I send so that hackers can't sniff data on same networks.

As you guessed, Facebook uses HTTPS, what that means is that requests to Facebook.com regardless of whether they are GET or POST requests are not sent over HTTP, instead they are sent over HTTPS in an encrypted form which the 'http' filter in Wireshark wont be able to display as regular HTTP requests. If you want to view the encrypted HTTPS traffic including data to Facebook, select 'tcp' as the filter and you should find requests that you are looking for.
Facebook uses HTTPS for transmission for security reasons, as you suspected, so actually Facebook is receiving data, just your filter is not displaying it to you.

Read More about HTTPS at:
http://en.wikipedia.org/wiki/HTTPS

For interception of Requests to Facebook.com use a proxy such as Burp Suite or OWASP ZAP. They will allow you to intercept and modify/monitor the traffic sent in real-time.

Hope this helps.


How do I remove disorderstatus.ru virus? Prevent reinfection? Make sure there is no (BIOS) rootkit left? I have recently had two PCs infected with disorderstatus.ru / differentia.ru, by plugging an infected pendrive.
From Google searches, it appears that it is a recent virus, or at least with recent spread.

PC1 has Win Vista, and PC2 has Win 8. Both have Avast, which detected the infections.

In PC1 (with partitions C for OS/programs and D for data), I recovered a previous Ghost image into partition C. Partition D was later scanned with Avast and reported clean.

In PC2 (again with partitions C for OS/programs and D for data), I reinstalled the OS.

My two pendrives (one infected and one... perhaps too) were reformatted to FAT16 and FAT32, in a Linux boot from CD.

I further have an external HD.

Is there a way to know for sure if the infection is gone forever?

My concern is due to the fact that there are BIOS rootkits, and perhaps other beasts around that are masters of disguise.

I would appreciate getting info specific to the infection I got, in addition to possibly generic comment which might apply.

Nuke from Orbit (TM)
Replace your non-hardware. Wipe and reinstall everything. That takes care of any software rootkits.
Use general good infosec hygiene to prevent reinfection. (E.g. install updates, only install from trusted sources, run antivirus. Air gap your network if you have to.)
(Hardware) rootkits: don't worry.
The short answer is: these tailor-made hardware rootkits are too expensive to waste on you or the general population.
Also: to defend from these type of attacks is ALSO very expensive and cumbersome. I recommend you spend your infosec budget elsewhere first.
General musings
Hardware rootkits are high-tech, nation state espionage, spy stuff.
They are valuable to the attacker. To continue working, they must be used sparingly. Each use of these has risk of detection for the attacker. Now this means: No shotgun style "hit everyone" attacks. But very specific, direct targeted attacks.
If you are a target valuable enough to justify using one of these things on you, then I'm assuming that you will have to replace your hardware as well.
If for example you are working in nuclear research. I'm thinking Stuxnet like attacks on Iran nuclear installations here. This probably isn't you.
Further reading:

Wikipedia: Rootkit, section Firmware and
hardware

Addendum: Non-tailor-made hardware rootkits.

"WPBT" sounds scary. No idea if it can be subverted.
Ars Technica: Lenovo used Windows anti-theft feature to install persistent crapware (Archived here.)
There is a leaked hardware rootkit from the Hacking Team hack. It's out in the public now. So this could be used by anyone. And not just spy agencies. But: it requires physical access to the computer.
Trend Micro: Hacking Team Uses UEFI BIOS Rootkit to Keep RCS 9 Agent in Target Systems (Archived here.)


How to authorize a public client I've created an application that is exposed via a web service and an Android client that communicates with that web service. Is there a way to have the client authenticate with the web service so that the web service knows it's communicating with the Android app I wrote and not an application masquerading as my Android app?

You can't effectively prevent someone from imitating the app. Even if
 you establish some sort of "secret app token" that only the app uses and encrypt the
 communication, it will still be possible to reverse-engineer these measures with manageable effort and mock
 the app behaviour.


Is it possible to exploit IOT devices with Usb 'RubberDucky'? Im kind interested , is it possible to exploit IOT devices with Usb 'RubberDucky' like Routers, servers , printers, modems with 'USB insertion'?

In summary: most devices will probably be not exploitable this way but given the infinite wisdom of IoT developers I'm pretty sure they will come up with devices where this is possible.

There is a variety of IoT devices out there, especially since there is no stringent definition of what an IoT device is at all. Some of these devices will probably also accept both USB keyboard and USB storage. And in some of these devices the user might also do harm by entering specific stuff on the keyboard. This ability might be by design or it might be a debugging capability which was left in production code. With such devices BadUSB can work too since it relies on the idea that plugs in an USB stick which looks like a storage but behaves like a keyboard.


Why do I see Network Traffic without any User Activity? Why does my computer send any network data, even if I am not doing anything?

Is it possible that this network traffic includes private data (text documents, images,...), to which I did not consent?

I'm going to assume you ask why you see traffic on your machine, even though you don't actively do anything. The reasons for that are that your computer is doing a lot in the background, which is not triggered by any user action. Let me give a few examples:

Replies to requests: Your computer receives network requests all the time. A good example for that are ARP requests in your local network. Your computer will receive them, and may respond to them. This is normal behavior and required for your PC to work.
OS and Application Updates: Your OS and your Applications will periodically check to see if updates are available. This is not triggered by any actions of yours, but happens periodically.
Background Connections: Some applications open various connections to external services as soon as you open them. For example, Chrome and Firefox both try to reach a specific site to see if captive portals are being used, if ISPs behave correctly, etc.

Of course, there are many more reasons why your computer may show traffic, even if you're not "doing anything".

  Could these contain private information without my consent?

That depends what you consider private information. For example, Firefox sends requests to fetch http://detectportal.firefox.com/success.txt. An attacker in the same network could listen to this request and detect that you are using Firefox.

As far as your consent goes, it depends on the Terms of Service of each individual application. You would be surprised to what things you consent just by using regular applications.

  Could these replies contain personal documents?

Answering a comment, usually no. Of course, if you use a file-sync service such as Google Drive, Dropbox, etc., it is of course possible that personal files will be included in such traffic, but this is by design.

As for other applications, it would be highly unlikely. For example, if you bought a video game from Steam and it would suddenly send copies of all your files to the publisher, such a case would become popular very quickly and would put the developer into hot water (and likely get their game banned from Steam quickly).


Why did TLS 1.3 drop AES-CBC? I was watching this video about TLS 1.3: "Deploying TLS 1.3: the great, the good and the bad (33c3)" and was somewhat surprised to see that in their effort to provide

  "fewer, better choices"

they dropped AES-CBC as a supported block cipher mode.

The video lists a number of attacks (Lucky13, POODLE and others), that to my untrained eye seem to be  implementation issues. I understand that it is better to have a mode that doesn't encourage such implementation issues, but was that all it took to deprecate this entire cipher mode?

While this book is somewhat dated (2010), Cryptography Engineering it recommends AES-CBC using a randomly generated IV as the best option.

The problem here is not so much with CBC, but with alternatives that are easier to implement safely, without losing mathematical security.In fact, AES-CBC turned out to be notoriously difficult to implement correctly. I recall that older implementations of transport layer security don't have cryptographically secure initialization vectors, which are a must-have for CBC mode

A lot of recent attacks are padding oracle attacks, like the Bleichenbacher attack. These especially depend on old modes kept for support. POODLE is a downgrade vulnerability. LOGJAM is downgrading TLS to old, export-grade (read NSA-sabotaged) crypto suites.

For CBC mode, there is the Vaudenay attack.
These attacks depend on the server explicitly saying "invalid padding", thereby leaking 1 bit of information on each transaction. Error messages were removed, but the problem of timing remained. The server still used more time before responding if the padding was valid.

In response they were forced to come up with the peculiar workaround of generating a dummy key, and using that for decryption so it would fail in another part of the implementation. In every implementation. So they decided to no longer force that on developers by supporting it in the specs.

Cryptography is a very broad field, and a specialty on its own. History had learned through uncomfortable experience, that doing it perfectly is almost never guaranteed, even for the best in the field. For example MD5, created by Ron Rivest, co-inventor (and part-namesake) of RSA was widely used, then broken in 2013 . Its collision resistance was circumvented in 2^18 time, less than a second on a desktop computer for 128 bit hashes.


Is Android encryption secure? As far as I know Android (Pie) is encrypted by default with some hardware-based password. But how secure is this encryption?

I am not talking about password compromise, but if somebody gets my phone, he just needs to turn it on to get data decrypted, so what’s the point? For what cases is this encryption designed?

I am not talking about password compromise, but if somebody gets my
  phone, he just needs to turn it on to get data decrypted, so what’s
  the point? For what cases is this encryption designed?

I'm not sure from where you are quoting this statement, but it's false. Physical access to the device does not guarantee automatic decryption of the disk.

From the official Android documentation:

  Upon first boot, the device creates a randomly generated 128-bit
  master key and then hashes it with a default password and stored salt.
  The default password is: "default_password" However, the resultant
  hash is also signed through a TEE (such as TrustZone), which uses a
  hash of the signature to encrypt the master key.

  When the user sets the PIN/pass or password on the device, only the
  128-bit key is re-encrypted and stored. (ie. user PIN/pass/pattern
  changes do NOT cause re-encryption of userdata.) Note that managed
  device may be subject to PIN, pattern, or password restrictions.

In the comments I've also referred to this question that answer a similar (if not equal) question.


What are the security benefits of calling and asking to input pin from the website? On Amazon AWS as part of the registration process you need to provide your telephone number. Then, after pressing Call me now button a PIN number displays on the same site and you get a phone call where you're asked to input that PIN on your phone.

What is the purpose of this security feature? Are there any vectors against which it protects or is it just a security theater?

Besides proving that the phone number is correct, a verification by phone helps to combat spam. It's much easier to create a high amount of fake accounts with verified email addresses than with verified phone numbers.

Google explains why they do that, too:

  Why Google asks for your phone number to verify your account

  In an effort to protect our users from abuse, we sometimes ask users
  to prove they’re not a robot before they're able to create or sign in
  to accounts. Having this additional confirmation via phone is an
  effective way to keep spammers from abusing our systems.


Should I create one key pair per customer as Service Provider in SAML? This is more or less the reverse of what's asked in this question.

I recently added SSO with SAML to a SaaS Web application making said application the Service Provider (SP). This is done so customers (companies) can use their existing Identity Provider (IdP) such that the users (the companies' employees) don't have to maintain credentials in our Web application but can simply continue to use their existing local accounts.

In SAML, the SP sends an authentication request to the IdP which answers with an assertion that provides authentication information about the user that wants to log in. In order for both parties (SP and IdP) to be sure that request and response are not fabricated by a wire tapper, they are signed with a private key. The certificate used to check the signatures of requests and responses have been exchanged beforehand as part of the SAML Metadata exchange that is done manually by the administrators of the involved parties.

The question is: Are there significant downsides to the security of this system if I use the same public/private key pair for all customers or is it advisable to go through the hoops of creating a separate key pair for each individual customer?

I'm explicitly asking about the security of this issue. I know that if I have to exchange the key due to a security problem, all customers will have to update their IdP to incorporate the new certificate. I haven't made up my mind yet but I lean towards thinking that this is an acceptable risk. Those keys would be stored next to each other; a breach of any description would require new keys for all customers anyway.

Best practice is that every IDP and every SP has its own key pair. Easier if you need to issue a new certificate for one of them and it prevents one of them from posing as another etc.

But this is the key pairs for the IDP and your web application. You are asking if the customers need different keys. If it is really is a question if the end user should have separate keys than the answer is definitely yes. In the same way that they should have different passwords.


How can I convince my customers not to send Credit Card data over email? My wife and I run an online business. For a long time we would accept credit cards over our website, and cash or bank drafts in person. However, as time went on my wife picked up the Square to process credit card payments in person and our customers really like this.

Due to the nature of our business (much of the furniture is custom) we don't take the entire payment upfront. We might authorize one amount, capture 60%, and when your goods arrive we re-authorize for the remaining 40%. This is pretty standard and works well. Except some folks aren't keen on meeting up in person for the remaining 40%, and we don't have an option to handle that extra 40% through our website (it would expect a new order).

I've been noticing some of the customers sending such details through email. Some were cautious, sending the number and the dates/cvv code from separate email addresses. Others not so much. Either way, it's not a stellar practice. I brought it up to my wife last night, and she didn't really get why I was making such a big deal about it - after all, she deletes the email as soon as its processed. I said "what if you lost your phone today?" and it clicked in that being insecure for "just a few days" isn't okay, especially if you almost always are in the "just a few days" stage with someone.

At the same time, it would be a pretty poor practice to say "We can't do this thing that's super convenient for you because we can't trust my wife not to lose her phone." - that's basically what our customers would hear. So keeping in mind that we can't rely on our customers being tech savvy at all, what can I use as leverage to convince my customers to not reveal their credit card data over email?

I've read this one about unsolicited emails but the recommendations are vague - "institute a policy", okay. * waves hands * we no longer accept these emails. But, when we are first discussing payment terms, they are likely to ask "can I send you my CC data over email" and when we say no, they will ask "why not"? What can I tell them that doesn't make us look irresponsible and convinces them that it would be best to do it in person with an actual swipe, or if it must be remote, to call us and we can enter it while on the call and it never needs to be recorded anywhere?

It's very simple, when you are taking in credit card information it means you have to be compliant with PCI-DSS being a merchant. Now to make your customers understand this you need to explain to them that you are simply not allowed to take credit card details through email. Kindly refuse it, acknowledge it's annoying but nescessary and immediately destroy the email.

You are not allowed to store or accept credit card information except when it complies with the standards as detailed in the attached document. If you do so you can make yourself liable for any credit card fraud which originates from a credit cards leaked through your business.

You can also explain to your customers that they should never send credit card details via email as this may be seen as an act against due dilligence (which customers need to take into account as well).

One way of solving this is only allowing credit card payments through bank terminals or through a payment gateway like PayPal. These will take care of the liability issue.


Is the Facebook login form using SSL without https in the URL? If I go to http://facebook.com, I am not redirected to https://www.facebook.com. If it doesn't have https in the URL, can the login be secure? Usually I am redirected to an https page on other sites? How is Facebook managing its login?

No, it is not secure to enter your username and password on http://facebook.com.

The target of the login-form points to an https URL, so a passive attacker cannot read your password:

<form method="POST" action="https://www.facebook.com/login.php?login_attempt=1"

But an attacker, who can modify the data stream, can manipulate html code which contains the login form. He can modify the target url or add some javascript code that sends a copy of the username and password to his own server.

Furthermore after logging in, Facebook sends the session cookie over an http connection. This allows even an passive attacker to act in your name. This is not a theoretical attack, there is a tool called Firesheep that is extremly easy to use.

To prevent the first risk, always use https://facebook.com to login. There is a browser extension called https everywhere which does this for you and even stays at https which prevent the Firesheep style attacks, too.


if computer is compromised, does hardware key still protect in ssh? Let's say I sign into my local pc with a hardware key (eg yubicon). Let's say I further sign into a sensitive server (as root) via ssh using yubicon hardware key as well (ie only way to get into server is though ssh when yubicon key connected).
Now let's say I click on a phishing email that gains admin access to my machine.

when I am 'away' can the threat actor access the server (assuming I logged out)?
when I am 'sitting there using it' can the attacker move into the server and plant access directly to the server so that they no longer are impeded at all by the key.

Thanks.

When I am 'away' can the threat actor access the server (assuming I
logged out)?

This will largely depend on the setup of your hardware key, assuming it is left inserted. If your key is set to require physical touch every time it is used for authentication, this likely cannot be bypassed, even if your system is compromised. If the device requires a PIN, the attacker likely needs to steal that first. In the case of both features, the device may not require them again for a period of time, at which point you'd likely be exposed.

when I am 'sitting there using it' can the attacker move into the
server and plant access directly to the server so that they no longer
are impeded at all by the key.

If the attacker has root, they can typically manipulate all files and processes on the system. It is not infeasible that they could backdoor the ssh binary to run extra commands, or attach to it at runtime to inject extra stuff.
It would seem the hardware key is most effective when it is unplugged or requires additional, unforgable physical interaction in order to activate each time a sensitive operation is performed. However, as alluded to above, while a hardware key is a powerful tool as part of a defense in depth strategy, it does not remove the need to focus on securing the rest of the system.


What are potential security risks when using an insecure wireless connection? If someone is using an insecure wireless connection (for example a hot spot in a coffee shop) does it pose a threat even if the person is using a secure application layer protocol? What I mean by secure application layer protocol is HTTPS, sftp, ssh etc. In this article, it is claimed that credit card numbers can be compromised, but would this be the case even if using HTTPS?

If I connect to a non-password protected wireless signal and use the Facebook app on my mobile phone, is it easy to get my Facebook password?

but if I rely on HTTPS (assuming a valid certificate) for all sensitive browsing, (banking, social media, e-mail, etc.) then is there still an issue?

Yes and no. It has been demonstrated that HTTPS can be circumvented, giving the user almost no clue that this happened. You can read more about this here: SSLSTRIP

On the same site you can read about a vulnerability that IE had which made HTTPS not secure (IE Basic Constraints vulnerability. Even if this vulnerability has ever since been patched, this shows that even if HTTPS is secure in itselft, one of its implementations can be broken and therefore make you vulnerable to an attack.

Finally, this article explains five ways in which you could break HTTPS.

This doesn't mean of course that HTTPS is not secure or that it's useless, far from it, but you shouldn't feel 100% safe when you are using it.

  Also, I know that it is as well trivial to obtain a user's MAC address, but I am not aware of any dangers associated with this. If I understand correctly, a MAC address is no different from a physical address, and poses no harm in the wrong hands.

It can indeed be a problem. There is one type of attack, called ARP spoofing, which allows an attacker to impersonate another computer on the LAN, thereby receiving all the packets originally addressed to the legitimate user.

This is a little different from the scenario you are picturing (obtaining another user's MAC address), because here the attacker tries to associate its own MAC address to the IP address of the victim, but it's just to show you that MAC addresses can be used to attack.

  Open ports are dangerous, is this why? In my specific case, I use things like MAMP, could this be a vulnerability if I were to use it while connected?

The answer in the link you posted is very good. Yes, you are more vulnerable than you would be without leaving that port open, because it's simply another way through which a malicious user could attack you.

  But more and more I am starting to think that with the proper counter-measures, using an open network can be no different to using a WPA/WPA2 encrypted network.

It is different, because if you encrypt your network, an attacker would first need to enter your network. If the network is properly encrypted, this could mean a huge work for the attacker, who could then simply decide that it's not worth it :)

  Assuming that I don't care about others mooching off of my internet, what are the downfalls?

As Lucas pointed out, you are responsible for your network. Suppose that some kind of illegal activities take place on your private home network, you are the one who will be held responsible (it already happened). It would be difficult, at this point, to prove that you were not involved.


How to verify the signature value in a SSL certificate? According to RFC 3280 a certificate's basic syntax is

Sequence :=
{
    tbsCertificate
    signatureAlgorithm
    signatureValue
}

In tbsCertificate, SubjectPublicKey is the public key of the server. The signature value is encrypted with the private key of the server (if I am not wrong). How will I decrypt the signature value (to validate the certificate) if it can only be decrypted by the server's private key?

I'm sorry you don't need the private key to "decrypt" something encrypted using asymmetric encryption, you need the public key, which is in the certificate, or the certificate of the trusted authority.
Using the public key also provides proof that the private key was indeed used.

See this prior entry  Digital Signature and Verification?
and this:
how digital signature verification process works


Is random data inserted into an encrypted stream easy to retrieve? Given that I have two pieces of data:

A large piece of encrypted data.
A small, fixed-size piece of random data.

I want to be able to transmit both pieces of data together, but I don't want the second piece of data to be readily available to a third party, but easily retrievable at the other end, assuming they know how it was hidden. It can't be encrypted as well.

For each message both pieces of data will be different.

Given the above, and assuming that an attacker has the knowledge that the payload they receive actually has both the above pieces of data is there any way to do some form of analysis to determine what the small piece of data is?

If the intended receiver knows "how it was hidden", but not the attacker, then this means that there is a "secret convention", shared between the sender and receiver, and applied to the piece of random data which you want to keep confidential. Regardless of how you want to call it, this is encryption (both legally and mathematically, that's what you are doing). You would have better luck actually using a proper encryption algorithm rather than a custom game of hide-and-seek.

Possibly, you may want to have the software use by the receiver "know" where to seek for the random data, hardcoded in the executable. This is still encryption, with a hardcoded key embedded in the software (so really not very secure, because attackers tend to have a copy of the software, and to know how to reverse-engineer code). Still, using AES with a hardcoded key (if you do not want to bother the receiver with key or password management) would still fare better (not good, but better nonetheless) than mixing your random data at "discrete" emplacements.

For the question you actually asked, properly encrypted data is indistinguishable from random bytes -- otherwise, this would be felt as a weakness of the encryption system.


Are there tracking methods for targeted ads from regular cell phone use, and how can one monitor that? There are many stories of individuals exchanging information near a cell phone, then finding targeted ads closely related to that information, with those same individuals claiming they did not search about that information in any internet browser. I have experienced a similar sensation, but I can usually attribute the targeted ads to some slightly related web search I made so casually that it slipped my mind.

That begs the question: are there tracking methods to generate targeted ads based on users' regular cell phone use (texting and calling, use/presence of apps)? Very similar to this Q&A: Listening to phone calls as user profiling for marketing

If more or less yes, and potentially as a way to answer that question in any case, here's a more tangible question: are there any tools to identify and block tracking methods that could be used to generate targeted ads from regular cell phone use? Even if no such tracking methods exist, perhaps there is software designed to keep a watch for it, as a part of a mobile security suite?

For example, is there a tool like Privacy Badger for smart phone applications? Privacy Badger monitors fingerprinting and tracking techniques by third parties within web pages viewed on a web browser - can any tool monitor for such behavior tracking being performed by smartphone applications, enabling users to have more control / confidence with their privacy?

The tracking methods are not all located in your phone.  For example, Verizon has been adding their own custom header, X-UIDH, to cell phone HTTP requests that pass through their network; and are using this to track users across the web.  Because it's injected by servers in their network and not by your browser or phone, there is no phone-based firewall or software solution capable of stopping this.  And as Verizon strips it out before it's returned to your phone, you aren't even able to detect it without looking at the traffic that arrives on a web server.

If this concerns you, and you are a Verizon subscriber, your best defenses are to use encryption.  While HTTPS Everywhere may seem like a good idea, I wouldn't put it past a phone company like this to install a proxy certificate on your phone that would enable them to MitM your HTTPS traffic.  Instead, encrypt all your phone's traffic before it leaves your phone, either using a VPN or Tor.  And you may want to switch to WhatsApp if you want to keep them from listening to your voice.  Since it seems kind of foolish to buy phone service from a company that can't be trusted, if this is a problem for you you should probably shop around for a phone provider that isn't violating your privacy.

Of course, this merely shifts your security burden to a different entity, but at least you can shop around for one that is more aligned with your privacy interests.


Is it useful to protect hashed password with encryption? Imagine that I am hashing the users' passwords with a random, long enough, salt, using key stretching, and a secure hash. Would it be more secure to finally encrypt the hash with a symmetric key?

What's the threat model? It could be of benefit to protect the password storage with an application-side secret, but only if you think it's a realistic scenario that your database is going to get compromised—without your application server, which holds the secret, also having been compromised.

Usually, the application layer is considered the more vulnerable part and the database layer more protected, and for this reason it is not considered useful to protect the data with an application-side secret. But that may not be the case for every app, and personally I would somewhat question this assumption given the prevalence of SQL injection.

The downside of introducing an app-side secret is that you now have to worry about key management processes. What's your mechanism for replacing the key if it gets compromised? Are you going to rotate it as a matter of course? How is your key stored so that you can move servers and not lose it (potentially making all your data useless)? For short-lived keys (used for eg signing session tokens) you may not care but for long-term password storage it becomes important.

The further downside with symmetric ciphers (especially block ciphers) is implementing them correctly. Since you are hashing and don't need recoverability, you could instead include the secret in the hash (as a ‘pepper’)... but then you wouldn't be able to re-hash all the password data on a key change, so you'd have to have a multi-key method for rollover.

ETA re comment @Pacerier:

Hashing does not prevent an offline guessing attack by someone who has obtained the password database. It only increases the amount of time it takes for that attack to bear fruit; with a hashing scheme of appropriate difficulty (ie rounds of key derivation rather than raw salt length per se), it will hopefully increase that amount of time to long enough for you to notice you've been hacked and change everyone's passwords before too many of their accounts are lost.

Protecting the content with a secret key (either using encryption or including the secret key in the hashed material) does prevent the offline guessing attack, but only as long as the secret key itself is not leaked. If the secret key is on the app server separate from the database server, the passwords are only attackable if both machines are compromised.

How much of a benefit that is arguable, given that many kinds of attack can end up compromising both, especially if the app server and database server are the same machine. There also is a price to pay in manageability as discussed. So whether there is net benefit needs to be judged on a case-by-case basis with reference to the threat model.


Javascript injection via document.cookie possible? Let's say someone rooted a site, is it possible for the attacker to do XSS via document.cookie? Instead of giving the user a name=value, the attacker does something like this name=<script>document.alert(1)</script> and it will store this in users browser as a cookie when he visits site it will execute. Is this possible or am I just way off? So is it possible to store some kind of VBScript/JavaScript exploit in users cookie? Or is that totally not possible? I know there are different ways attacker can approach if he rooted the site but I'm wondering specifically about cookies in users browsers and their capabilities storing code and attacking the client. Is this a possibility or a myth?

As you point out, if an attacker has rooted the site, you've already lost.  There's a number of things they can do that are far more dangerous to your users than cookie-based XSS.

However, it's possible to set cookies for a domain without rooting the site.  (Such as injecting them if a user is visiting an HTTP page on the same domain, even if that page doesn't contain anything significant or sensitive.)  So let's look at what a cookie can do.

If you output the value of a cookie without escaping it, then there's a definite opportunity for XSS.  If you build a tag (such as a link) with the value of the cookie, you might have an XSS.  Basically, you should be treating cookies as untrusted input anyway, so you shouldn't have an XSS, but it does happen.

Here are a couple of real-world examples:

http://blog.k3170makan.com/2013/10/aboutme-cookie-based-xss.html
http://miladbr.blogspot.com/2013/04/exploiting-unexploitable-dom-based-xss.html
http://research.zscaler.com/2009/05/cookie-based-persistent-xss.html (older link, some resources are broken, still informative though)


How to authenticate to racoon with a certificate chain if only the root CA is known I'm trying to setup IPsec using x509 certificates on Linux. I'm using racoon for that task. I've come to the point where the authentication works fine if I keep every link of the certificate chain on every host. My goal is to authenticate each other knowing only the Root CA.

For example: for the hosts "Alice" and "Bob" the chain of certification looks like this

Root-CA -> MajorCA -> MinorCA -> (Alice/Bob)

Where Root-CA is self-signed and so on.
Certificates that Alice knows are

Alice.key
Alice.crt
Root-CA.crt
MajorCA.crt
MinorCA.crt

Certificates that Bob knows are

Bob.key
Bob.crt
Root-CA.crt
MajorCA.crt
MinorCA.crt

Now everything works fine in this constellation.
Alice sends

Hey, I'm Alice, and this is my certificate
"Alice.crt"

to Bob and Bob can reconstruct the entire chain to

Root-CA -> MajorCA -> MinorCA -> "Alice"

What I'm trying to realize and I'm not sure if this is possible at all is to authenticate a host via the Root-CA, regardless of the rest of the chain, which has to be provided by the host itself. E.g.

Bob knows only the following certificates

Bob.key
Bob.crt
Root-CA.crt

and Alice authenticates herself to Bob by sending

Hey, I'm Alice, and this is my certificate chain
[Root-CA.crt] -> "MajorCA.crt -> MinorCA.crt -> Alice.crt"

either with or without the Root-CA certificate.

Now Bob should be able to reconstruct the chain to

Root-CA -> "MajorCA -> MinorCA -> Alice"

and therefore authenticate Alice.

I know that some CA certificates come as bundled PEM files and I know that it is possible to bundle the entire chain as PKCS12 file.
But racoon does not support PKCS12 (or does it?) and it ignores additional certificates in a PEM bundle (and only takes the first one).

Now my question :-)

Does anyone know how to realize this (using racoon) and make the scenario work, or does anyone know that this will surely not work because of reasons they can explain?

Regards,

fr00tyl00p :-)

In IKE v2, it is possible for any machine to send several certificates, its own and a number of "helper certificates" which could help with validation, i.e. intermediate CA certificates. The standard states that:

Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication,
and also MUST be capable of being configured to send and accept the
Hash and URL format (with HTTP URLs).  Implementations SHOULD be
capable of being configured to send and accept Raw RSA keys.  If
multiple certificates are sent, the first certificate MUST contain
the public key used to sign the AUTH payload.  The other certificates
may be sent in any order.

so it should work, as long as you can convince your tools (racoon) to send the certificates. The standard is there.

The standard alludes to the possibility of sending, on the wire, not an X.509 certificate alone, but a PKCS#7 file. A PKCS#7 file is really a large and flexible format, but often used as a container for multiple certificates (but it does not contain the private key). It may be worth a try to use such a file with your certificate_type clause (in racoon.conf).


Unencrypted data over Magnetic Card Reader. What are the security risks? I am working on evaluating the security of my University's student id card. The ID card contains both a magnetic stripe and a RFID component and is used to make payments as well as to provide access to buildings. When I tried to read it using a Arduino based Magnetic Card Reader , I could see the data in plain text. As there is no Keyboard based PIN entered during any payment transactions from the card, my question is what all security risks are involved with this setup. I am a complete noob at security so pardon my ignorance here but I think we can use a Magnetic Card Writer to clone this card and use it in the same way as the original card. Will this be possible ?

In short: yes, it is very likely possible.

If the magnetic strip and the RFID are not related, then even if the data were encrypted the setup would not be secure. It would be too easy to slip the data off the original card (you can do that with a tape recorder head, and there are even iPhone apps to do that, by interfacing with the audio jack), clean them and record them back on any ISO2 card.

If the RFID and the magnetic strip are both needed, then it is much more expensive, but not difficult: you just need a RFID reader/writer.

Passive PIN-less cards are not secure, that's all there's to it. Their information can be cloned in several ways; for example I've witnessed a test on a variation of Van Eck 'phreaking', in which a sensor placed near the original card swiper was able to "hear" the chatter from the card reading head. Once you know the data on the strip, just pass near the cardholder with a RFID terminal and query the card for its data payload. Passive cards will always respond in the same way. Once you have both strip and RFID information, all you need is a blank on which to store the information.

If the magnetic strip alone is needed, things can become even worse: one could erase the magnetic strip on his own card and re-record it with someone else's information, thereby appearing to have a legitimate and authentic card that would pass a cursory examination, but actually logging accesses and debting sums to someone else.

If the target scenario doesn't involve human interaction, it is not even needed a good blank - you can demagnetize and recycle any old ISO2 card, and swipe it while wearing a RFID fob on a bracelet. The strip will supply the correct data, the fob will fool the reader into thinking there's a RFID chip on the card, and the reader will be tricked.

I am quite surprised that nowadays someone may still be considering accepting payments using a stealable card without the need of two-factor authentication (such as a PIN). I would try to warn the University - but anonymously, since this kind of setups usually practice shoot the messenger, and are too likely to pull a Feynman on you.


How well Tor protects against fingerprinting? I don't want certain websites to track me, but they don't work without js. I found a few plugins that all require "reading and changing all data on all websites", so I needed something else. I was thinking about coding a tiny python browser or another based on the chromium project, and just configure it not to pass that much data (empty user agents, etc). Also, the second option would've been to find the top 10 fingerprints on web and use them randomly. The downside is I had to get a new IP for every fingerprint change to seem like requests came from different devices. And the easiest way to achieve that is using Tor. But then I still have my unique fingerprint and back to the original problem, right? Does the Tor network do something about this?

When you do not change anything, the Tor browser is already configured in a way that the fingerprint is identical to every other Tor browser (and is close to the most common fingerprint on the web). I recommend to rely on this instead of messing around with it by yourself since there are many possibilities to build a fingerprint. Have a look at the open and closed issues of the Tor browser bug tracker and try to understand the problems.

You could also use Tails via a read-only live medium to get a very high amount of anonymity with reasonable effort.


What is the purpose of the rotating plate in front of the lock? I am now in Poland and see these everywhere:

The plate can rotate freely,when you insert the key, matching the groove, you rotate the key so it is aligned with the lock and then insert the key.

What is the purpose of this?

It's called anti-drill plate.

With the anti-drill rotating plate, the drill bit won't be able to go through the cylinder. It's supposed to be in hardened steel and act as an other layer of security.

When you drill a cylinder lock, you have to go with small drill bit first. You will then use bigger and bigger drill bit on the little hole you made. The plate will prevent you from doing so because the bigger drill bits will just make the plate rotate.

Here is how drilling attack works

Examples:

Euro Profile Cylinder Security Protector
Mila secure handle


NMAP's explicitely closed ports I'm working on a challenge and I notice this odd output for a full port scan?

abc@desktop:~$ nmap -T5 -p- -sV x.x.x.x -PN

Interesting ports on x.x.x.x:
Not shown: 65533 filtered ports
PORT      STATE  SERVICE       VERSION
3389/tcp  open   microsoft-rdp Microsoft Terminal Service
11111/tcp closed unknown
Service Info: OS: Windows

I'm used to NMAP only displaying open ports. In this case the vast majority of ports were closed but NMAP explicitely stated port 60000 is closed.

What does an explicitely closed port mean?

You are performing a SYN scan or TCP connect scan (depending on your account permissions). With those scan types, you can receive the following port states based on the results of the TCP handshake:

open: An ACK packet was received, indicating that the connection was accepted.
closed: A RST packet was received from the host or firewall, rejecting the connection.
filtered: No response was received when attempting to connect to this port.

It is also worth noting that Nmap utilizes half-open scanning in the SYN scan mode because it never completes the TCP handshake. The idea is that this is more stealthy because logs often record when a connection is actually established.


Conditions for reusing client certs in TLSv1 In my setup I am using client certs, and the client devices are iPhones running iOS 9.0.

In comparing some network traces I noticed that in some cases, the server asks for the client certificate for the first time, and then for all future connections (at least within the next minute) it will not ask for it again. After the first connection I will just see "Server Hello, Change Cipher Spec, Finished", where for the initial case I will the proper back and forth which involves transferring the server and well as the "RSA Encrypted PreMaster Secret".

However with some other clients (which have a different version of the software which handles the SSL) I see that the server will frequently ask the client again and again for the client Cert.

Which is these behaviors is correct and what elements determine whether the Server decides to ask same client (based IP address) again for the client cert?

SSL/TLS supports a performance optimization called session resumption. It allows you to continue a previous connection, reducing the standard 5 messages

down to 3 messages

(image from Vincent Berat's blog)

For session resumption to work, you need both a server and client that support this functionality. From your description, it sounds like your server and some of your clients support session resumption, while other clients don't. Note that just because both the client and server support session resumption, it doesn't mean it will happen. The client and/or the server may decide to free up the resources used to hold session resumption information for any reason. If they do this, a full TLS handshake will be required if there is further communication.


Preventing data remanence at filesystem / OS level We all know that deleting a file from your computer does not really erase it, but only marks as free the memory where the file was written, so that, until such memory is not overwritten, the file can still be recovered by reading the raw memory.

To really erase a file, its memory must be overwritten by random data or simply zeros, using tools as shred. (I'm going to assume that no physical method to recover data from erased memory is possible.)

This has to be done manually for every file we want to erase; In particular, if we use a software that keeps some sensitive data (for example, the "recent files history"), we have to erase them by ourselves instead of trusting the delete function of the software (that is, clicking, "delete recent files history"); which requires many awareness and/or customizations.

My question is: Is there a way to ensure that computer files are always deleted by being overwritten with zeros? I mean, a filesystem or OS that does so? In such a case, except for the memory allocated for the files that are present in the filesystem, the whole memory would be always filled with zeros.

I straightforward way to do so could be modify how the OS handles the "delete" filesystem command in a way to run an erase tool, but it doesn't seem trivial to do.

Notes:

One may suggest to simply encrypt the whole filesystem, and who cares about deleted file or not... they are protected by the password. However, this solution is subjected to rubber-hose cryptanalysis.

"Shred" isn't always as effective as you might think, since it relies on the assumption of in-place overwrites.

Using a Solid State Drive (SSD) with TRIM function enabled will reliably remove deleted data, but sometimes there's a delay that can stretch out to many minutes before TRIM does its thing.

None of the above approaches address alternate storage such as cache, or shadow files.

If you're really serious about protection, use a Bootable Non-Persistent OS where everything is in RAM and no changes survive after a power down.


Does corrupting several bytes of an encrypted zip make it unrecoverable? Can adversary extract data from a deliberately corrupted archive?

If I archive a folder with 7zip, and I use a password (including header encryption) will garbling a few bytes at a particular offset of the encrypted archive make recovery by forensic software impossible without knowing in advance which bytes were deliberate altered?

If N  bytes at offset O have been altered must an adversary trying to bruteforce the archive correctly reconstruct both the correct offset and original unaltered bytes before trying bruteforcing the archive password, or is there a shortcut to extract data from the encrypted archive in the case that some of the data have been (deliberately) corrupted?

Assuming for instance, that 5 bytes at offset N have been  changed and the adversary only has incomplete knowledge of the original archive state, is it possible to "guess" all the original bytes data constituting the archive before proceeding with the bruteforcing of the password?

Can someone -- assuming that he can remember and later reverse the offset O and bytes N,  use this method in addition to a good password to fool forensic software and maintain plausible deniability in the scenario that he is being compelled to disclose the password?

UPDATE

Sorry, what I intend to use is 7zip's builtin encryption AES-256 in conjunction with header encryption.

My question was concerned with (deliberately) altering the offset of an encrypted 7zip archive and if bruteforcing the password would even be feasable without reconstructing the altered N bytes at offset O.

There are a lot of assumptions baked into your question, so I don't think a general answer is possible, but I'll try to explore it a little.
I assume you have encrypted the archive using the standard "password-protected" mode that's built-in to zip tools. I'm not an expert on the zip file format, but it looks like there is no standard for which cipher to use; RC4 (stream cipher) and DES, 3DES, and AES (block ciphers) are all common choices. To answer this question, we'll need to explore how encryption ciphers work.
Stream Ciphers
RC4 is a stream cipher, which according to wikipedia, works like this:

A stream cipher makes use of a much smaller and more convenient key such as 128 bits. Based on this key, it generates a pseudorandom keystream which can be combined with the plaintext digits in a similar fashion to the one-time pad.

I have never studied RC4, but my understanding is that encryption is done one byte at a time by XOR'ing one byte of the keystream with one byte of the plaintext.
This means that, assuming you know the key, the 5 bytes you've mangled will decrypt mangled and be unrecoverable, but all bytes before it and all bytes after it will decrypt fine.
Block Ciphers
Block ciphers work totally differently from stream ciphers. It's a bit harder to explain, but we can look at the most common mode: cipher block chaining with this image from wikepedia:

The important thing to note is that cipher text for a given block depends on the cipher text of that block and the block before it. So this largely behaves the same as stream ciphers in that the bytes you mangled (and one block after it) will decrypt mangled and be unrecoverable, but all bytes before it and all bytes after it will decrypt fine. (thanks @dave_thompson_085)

Brute-forcing the password
So generally speaking, unless you reverse the mangling, the bytes you mangled will be unrecoverable,  but the bytes before and after will decrypt fine (whether the bytes after decompress fine is a different story, thanks @dave_thompson_085, but since compression is not designed for security, I'm sure a good forensic analyst could get information out of it).
In the context of an attacker brute-forcing the encryption key (ie the password), encrypting the zip header actually makes their job easier: all they need to do is try decrypting with random passwords until the first few bytes decrypt to a valid zip header (or the file header of the first file in the archive decrypts to a valid file header).

What problem are you trying to solve?
The XY Problem
Going back a step, it sounds like you want to enhance ZIP's password-based encryption and possibly add plausible deniability by inventing an obfuscation technique - or if you want to be able to reverse it, by inventing an encryption technique.
As @TTT colourfully put in a comment, I'm not sure you're going to be able to convincingly hack plausible deniability onto ZIP's encryption system.
As for enhancing it, why not just use AES and throw away (or don't throw away) the key? Or, why not skip using ZIP's terrible password-based encryption altogether, and just run the .zip file through GPG or openssl or some other better more modern tool that supports public-key encryption? (hint: native zip encryption was a badly-done hack when it was written, and now it's out-of-date hack. If you want proper security, then run your zip file through a proper tool rather than trying to salvage the hack).


Is there a standard order for the X.509 extensions of a certificate? Is there a standard order for the X.509 extensions of a certificate?
For example:
 [ myca_extensions ]
 basicConstraints = critical,CA:FALSE
 keyUsage = digitalSignature,keyEncipherment
 extendedKeyUsage = serverAuth
 subjectKeyIdentifier = hash
 authorityKeyIdentifier = keyid:always,issuer
 crlDistributionPoints = @crl_section
 authorityInfoAccess = @ocsp_section
 subjectAltName  = @alt_names

 [alt_names]
 DNS.0 = *.example.com
 DNS.1 = *.example1.com
 DNS.2 = example.com
 DNS.3 = example1.com
 IP.0 = 192.168.0.2
 IP.1 = 192.168.0.3
 IP.2 = 192.168.0.4
 IP.3 = 192.168.0.5
 IP.4 = 192.168.0.6
 IP.5 = 192.168.0.7

 [crl_section]
 URI.0 = http://pki.example.com/Example Intermediate Certificate Authority.crl

 [ocsp_section]
 OCSP;URI.0 = http://pki.example.com/ocsp/
 caIssuers;URI.0 = http://pki.example.com/Example Intermediate Certificate Authority.crt

If the extensions have a standard order to be placed, is my above config correct?

Extensions are unordered, so whatever order you prefer would be fine.
p.s. Does your organization own 4146 PEN number? As per IANA registry, this PEN number is owned by GlobalSign and you are not allowed to use it in certificate policies. And 2.23.140.1.2.2 is owned by CAB Forum, so you are not allowed to use this OID either.


Is there a portable memory device with an offline erase technique? (such as an erase switch?) I know about the USB devices that have a write protection switch that disables writing on the device side, are there devices that have a similar hardware switch that permanently erases the devices memory, or another method that can verifiably erase the data?

After watching this video I got the feeling that even snapping a micro SD card in half may not permanently erase the device, so I was looking for an alternative.

A switch or method to irreversibly destroy the memory could also partially answer this question but I worry that it would be harder to verify, since it is a trick you can only do once. Even devices that have a self destruct method of forgetting the devices encryption key require some trust from the user and the device to be plugged in at the time, the best answer would be a button that resets all the memory to 0.

Tamper-resistant devices, like the PIN pads you see at cash registers, often store their keys in a CMOS chip that requires a battery to keep the storage refreshed. If the circuit detects tampering (someone removes a screw, or drills the PCB, or breaks a tripwire cutting into the epoxy, or trips whatever other sensors the manufacturer included), the battery power is cut and the memory is drained. The chips used for this are often in a BGA package, making it that much more difficult to access the interior pins.  Adding a push-button kill switch into the tamper detection circuit would not be a problem, if one was needed.

The Mooltipass Mini offers securely encrypted password storage in a pocket-sized tamper resistant package. Three wrong guesses at the PIN and the master key is wiped.  But it doesn't have a kill switch, and it acts as a keyboard, not a mass storage device.

I have never seen a tamper-resistant mass storage device of the kind you seek. That doesn't mean they don't exist; just that if they do, they have very poor marketing.


Run Hydra Through Series of Proxies? Is there a way to run Hydra through a series of proxies so a website can't lock you out? Having a hard time finding a way to do this. Most websites will block you out if you take to many attempts at logging in and if I am trying to brute force a password, I am going to have to constantly have to look like I am coming from many different places.


security related certificate I work in cyber security r&d for several years. Meanwhile, I have obtained a CEH (Certified Ethical Hacker) certificate and a CISSP certificate.

I wish to move to security industry instead of r&d environment as my next step plan. Thus, what kind of certificate could be my next target?

The CEH and CISSP certifications will likely help quite a bit.  I suggest ongoing trainings (and certain certifications) through specific services, such as Amazon Web Services (AWS), Microsoft, IBM or Google.  It could also be beneficial to learn about various other security vendors and explore training opportunities (and possibly joining partner networks) for multi-factor authentication (Duo, etc.) and virtualization tools (VMware, etc.) and continuously follow research on "DevSecOps" and other industry best practices.  I also suggest following development and communities / trainings, based around open source security tools and best practices, such as Open Web Application Security Project (OWASP): https://www.owasp.org/index.php/Main_Page


What does the question mark in nmap output indicate? In the following nmap output:

$ sudo nmap -sS -sV -vv -n -Pn -T5 x.x.x.1-255 -p80,23,21 -oG - | grep 'open'

Host: x.x.x.x ()  Ports: 21/closed/tcp//ftp///, 23/open/tcp//telnet?///, 80/filtered/tcp//http///
Host: x.x.x.x ()  Ports: 21/open/tcp//ftp//D-Link or USRobotics ADSL router firmware update ftpd/, 23/open/tcp//telnet//Broadcom BCM96338 ADSL router telnetd/, 80/open/tcp//http?///
Host: x.x.x.x ()  Ports: 21/open/tcp//ftp?///, 23/open/tcp//telnet?///, 80/open/tcp//http?///
Host: x.x.x.x ()  Ports: 21/closed/tcp//ftp///, 23/open/tcp//telnet?///, 80/open/tcp//http?///
Host: x.x.x.x ()  Ports: 21/closed/tcp//ftp///, 23/closed/tcp//telnet///, 80/open/tcp//http?///

there is a question mark after the service name (ftp?, http?).

What does the question mark mean exactly?

If Nmap isn't able to identify the service based on the signature of its response to the probing it falls back to port identification. It checks the port against a list of known port-service pairs.

So the question mark indicates that the identification was based on the port number rather than response signature.

You can find the full list in nmap-services


List of visually similar characters, for detecting spoofing and social engineering attacks I'm trying to detect homograph attacks and other attacks where an attacker uses a spoof domain name that looks visually similar to a trusted domain name (e.g., bankofthevvest.com instead of bankofthewest.com).

Is there a dictionary or database of visually similar characters that's suitable for programmatic use?

For example, if I look up "l", I'd like to get back a list indicating that "l" is visually similar to "1" and "i" (at least in some fonts).  If I look up "w", it might tell me that it's visually similar to "vv" (in some fonts).  If I look up "d", it might tell me that it's visually similar to "cl" (in some fonts).  At least for now, my focus is on visual similarity between ASCII characters.  It's fine to ignore Unicode.  (However, it's an extra bonus if there's a list that also knows about which Unicode characters are visually similar to each ASCII character.)

If such a thing already exists, I'd like to avoid re-inventing the wheel.  Does such a list already exist?

Here's what I've found so far:

I found Is there a dictionary of visibly similar Unicode characters for Spam processing?, but the question is focused on Unicode, and the answers there don't really solve this question: they propose an alternate detection mechanism.
The following two research papers devise UC-SimList, a list of visually similar characters.  However, it focuses on Unicode characters, and doesn't have similarity between ASCII letters (e.g., l vs 1, vv vs w).

Anthony Y. Fu, Xiaotie Deng, Liu Wenyin, Greg Little.  The Methodology and an Application to Fight against Unicode Attacks.  SOUPS 2005.

Anthony Y. Fu, Wan Zhang, Xiaotie Deng, Liu Wenyin. Safeguard against Unicode Attacks: Generation and Applications of UC-SimList.  WWW 2006.

There are different approaches for homograph attacks. The success depends on the used font. For example in some fonts the small letter l looks very much like the capitalized letter I. And in others they don't.

Similarities

Use similar characters. They substitute the real character.

b ⇔ 6
c ⇔ (
g ⇔ q, 9
C ⇔ (
G ⇔ 6
L ⇔ l, I, 1, |
O ⇔ 0
S ⇔ 5
V ⇔ U
Z ⇔ 2

Sound Alteration Characters

Some language, like German, have special characters (e.g. umlaut). Under some circumstances they may look like a character without them:

a ⇔ ä, à, á
e ⇔ ë, è, é
i ⇔ ï, ì, í
o ⇔ ö, ò, ó
u ⇔ ü, ù, ú

Multi-letter

In some fonts the multi-letter approach is very successful.

a ⇔ ci
d ⇔ cl
g ⇔ cj
m ⇔ rn
A ⇔ fi
W ⇔ VV

Constructions

Construct a single character from multiple characters. Very popular is vv instead of w.

A ⇔ /\
B ⇔ |3
D ⇔ |)
G ⇔ (¬
H ⇔ |-|
K ⇔ |<, |{
L ⇔ |_
M ⇔ |v|
N ⇔ |\|
V ⇔ \/

Injections

Injection involves inserting meaningless characters into a string, especially within a domain/url.

http://somewebsite.example ⇔ http://some-website.example

Whitespaces are often overlooked in this case. The Zero Width Whitespace (&#8203;) is a nice tool under some circumstances.


Why are pins required on boot on devices with fingerprint readers? Both my iPad and my android phone are configured to allow access via either a pin, or a fingerprint scan. However, immediately after a reboot, neither device allows a fingerprint for the first unlock; the pin is required instead. Both devices state "a pin is required to unlock after a reboot".

Why is this? What risk is associated with allowing a fingerprint unlock directly after a power on?

The PIN is used to derive an encryption key, whereas the fingerprint is used only for authentication. Because the encryption key is kept in memory during runtime, it is lost after a reboot and needs to be supplied again. It is supplied via the PIN or passphrase that you are required to enter.