SSL Handshake failed I’m working on windows desktop application which is created using C++ (IDE : Qt creator). It has login panel, where i do user validation via https connection using openssl 1.0 library. Application is working in most of the machines, but i'm also experiencing "SSL Handshake failed" error while making https connection from few machines.

I tried debugging the error using wireshark. My observation is as follows:

1)  Client sends [SYN] to server.
2)  Server sends [SYN,ACK] to client.
3)  Client sends [ACK] to server.
4)  Client sends the message “Client Hello” to the server.
5)  Server sends its public key with the message “Server Hello, Certificate, Server Hello Done”
6)  Client sends its public key with the message “Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message”
7)  Server sends encrypted handshake message with the message “Change Cipher Spec, Encrypted Handshake Message”
8)  Client sends [FIN,ACK]
9)  Server sends [FIN,ACK]
10) Client sends [FIN]

In 7th step, as soon as client receives encrypted message from the server, client initiates termination of handshake by FIN signal.  Any idea, why does client tear down ssl connection with “SSL handshake failure” after both parties exchanging the keys?

Your description of the handshake seems to indicate that the client and the server conducted the handshake completely, and then the client dropped the connection. This means that "something" was not right from the client's point of view. There are mostly two possible candidates:

The certificate sent by the server is not "proper"; the client decided that some user validation is necessary. The client completed the handshake so that it may reopen the SSL session with a faster "abbreviated handshake" (reusing the negotiated "master secret" without having to to the asymmetric crypto again), but closed the connection so as not to keep resources open on the server while the human user makes up his mind (the meat bag is slow).
The Finished message sent by the server (that's the "encrypted handshake message") contains an incorrect value (from the point of view of the client) due to some bug (probably in the client). This is not a very probable occurrence.

My guess is that you are in the first case: the server uses a certificate chain which is "not good" for the client. Usual culprits:

The server certificate chain does not link up to one of the "trusted roots" of the client (depending on the library used on the client, the list of roots can be in several places).
The server name, as expected by the client (the one in its URL) is not matched against the names in the server's certificate.
The client clock is wildly off, so it rejects some certificate which is, from its point of view, either issued "in the future", or long expired.


How can I determine the Java version running on a remote server? Short version

How can I determine the Java version a remote server is running if I only have access to the server through port 443?

Long version

I am validating a pentest run by another group. They found an error message that provided the Java version being run by the remote server. The Java version was an old one. The developers have apparently made changes that prevent the error message from appearing, thus hiding the Java version.

My job is find out if the developers also updated the java version. How can I do that without access to the server other than through HTTPS via port 443?

Are you validating the results or the server? You seem to be confusing the two.

Preventing info disclosure through error messages is a good thing. You verified that is fixed. It doesn't seem to be your job to validate that the Java version is updated (since it appears to be a black-box test), for that, you leave that to the server operator to report on. Make a note that it's no longer obvious what the version is, and encourage the report audience to validate the server to confirm.


Automatic detection of credential leaking and secret servers Are there any frameworks or applications available for automatic detection of credential or secrets being leaked?

So far, I've found a number of academic papers on papers on the subject but no specific applications or frameworks. I've also found Netflix's Scumblr tool, which sort of fits the bill: automatic searching of social media sites, possible use-case would be to add regexes for emails or possible API strings.

This will not be a full answer, since a full answer is not possible:  A credential can be anything that you may want to make into a credential.  But assuming that the credentials are sensible we can argue about two things:

The first paper you mention simply makes a scheme in which an unauthorized access provokes an alarm (wrong codeword in the paper) which disables the key.  In implementation terms this isn't much different from: "after three unsuccessful logins the password is blocked".

The novelty of the paper is only that they make a full keyscheme (with formal analysis of the scheme).
The second paper talks about something completely different.  It is just an enumeration of how systems that publish user data to the web (e.g. github or bitbucket, but it could well be facebook) try to find that inside the published data there are strings that look like credentials to somewhere else.  This is pretty similar to what scumblr can be configured to do.  Their list of techniques includes rather simple points:

keyword search (e.g. BEGIN RSA PRIVATE KEY)
pattern match (e.g. search for base64 encoded strings)
heuristics (pattern match but using context)
source search (pattern match but using guesses based on the type of source code it is searching)

These things work, I remember receiving an email from BitBucket when once upon a time I submitted my AWS API key to a repository.  But as for their implementation as a specific tool I believe they're just scripts that are invoked as git hooks.  Look at this image in the paper:

The "key detection module" is called between a user commit and the actual commit to the public repository.

Github and BitBucket certainly has a database of patterns that are likely to be credentials.  And also they certainly have a couple of heuristic algorithms.  Points 1 (keyword search) and 2 (pattern match) are trivial to implement with grep, points 3 (heuristics) and 4 (source search) require a good deal of pre-existing data which only places like Github and BitBucket would have.

Finally note that even the paper argues that the heuristics and source search produce both false negatives and false positives.  Therefore there is no magical solution here.

Had I needed something to check for users on my website publishing their credentials to somewhere by accident I'd try to use points 1 (keyword match) and 2 (pattern matching) and then simply build a heuristic algorithm that does not depend on so much on pre-existing data.  On way would be to try Kolmogorov complexity (see this old question about string complexity from more info).

The assumption is that complex credentials will have a lot of entropy by byte since they should be difficult to brute-force.  This is a bad assumption in some cases: for example base64 encoded strings have little complexity compared to their length.  We will need to catch base64 strings in the pattern match phase (phase 2).

Here is a trivial (it uses zlib to approximate Kolmogorov complexity, which isn't particularly close) heuristic algorithm using the assumption above:

#!/usr/bin/env python3

from io import BytesIO
import zipfile

strings = [ b'password password password password'
          , b'correct horse batter staple'
          , b'HdtfhhaissdogkanfhhwnaHDnbahdnSGENdkfQWee=='
          , b'hZjJIdkXndjaodk='
          , b'\x89\x12\x03\x561w\x10'
          ]
for s in strings:
    fp = BytesIO()
    zf = zipfile.ZipFile(fp, 'w', zipfile.ZIP_DEFLATED)
    zf.writestr('f', s)
    zf.close()
    print('%50s' % s, float(len(fp.getvalue())) / float(len(s)) )

And its output:

        b'password password password password' 3.257142857142857
                b'correct horse batter staple' 4.777777777777778
b'HdtfhhaissdogkanfhhwnaHDnbahdnSGENdkfQWee==' 3.3255813953488373
                           b'hZjJIdkXndjaodk=' 7.375
                        b'\x89\x12\x03V1w\x10' 15.571428571428571

As expected it works well to separate simple strings from strings that are sets of more-or-less random bytes.  Yet, it works badly on base64 strings and even on some passphrases.


Why can a man-in-the-middle attack not happen with RSA? I understand how RSA works (generate private/public key pair, send public key to whoever you want to talk to, encrypt with public, decrypt with private), but isn't there a flaw in this?

Let's say A wants to send a message to B. A generates his public/private key pair, and sends the public key over a network to B, right? What's stopping C coming along and intercepting this public key, generating his own public key, and then sending his own public key to B? Then, when B sends his public key back to A, C could intercept this, store it, and send his own public key to A.

Now, when A sends an encrypted message using what he thinks is B's public key (but is actually C's), C will intercept this message, decrypt it, then encrypt it again using B's actual public key.

Would this work? If not, why not? Is it just a matter of using a secure network to send the public key?

This is the problem of key distribution, and it is difficult.
In general, Alice must already know that the key belongs to Bob, or have someone she trusts attest that it belongs to him.

For HTTPS this is accomplished by a Public Key Infrastructure (PKI), where Certificate Authorities (CAs) attest that a key belongs to a certain domain or set of domains. This scheme quickly falls apart if any widely trusted CA proves unworthy of the trust placed in it, and unfortunately this has happened multiple times in the past (WoSign, Symantec).

SSH mitigates it by storing the host key for each server you connect you, then warning you if the host key changes for future connections (this is called trust on first use). It also warns you and allows you to verify the key's fingerprint when first connecting, but this requires obtaining the fingerprint through some other means, so it doesn't solve the problem so much as pass it on to the user.


Asymmetric Encryption Digital Signatures Here is the paragraph I can't quite get my head around.

Alice sends a message to Bob and wants him to be sure the message has
    come from her.
    • She publishes her public key.
    • She computes a message digest
    • She encrypts the digest using her private key
    • She sends the message and digest to Bob
    • Bob decrypts the digest using Alice's public key
    • Bob Creates a message digest from the message using the same algorithm
    as Alice
    • Compares this with the decrypted digest received from Alice
    • If they match we have established two things
    – The message must have come from Alice - Authenticity
    – The message has not been altered - Integrity

I understand private and public keys and how they work, also I know that you could add Bobs public key to the entire message at the start for confidentiality. But what I can't get my head around is why Bob had to create the digest, I thought the fact that he could decrypt the digest itself wouldn't that give him the original message? What am I missing. thank you in advance

The message digest is a hash of the original message.  You can't reconstruct the message from the digest.

Bob computes the digest and compares it to the one Alice sent him.  If it matches, Bob knows that the message hasn't been changed, since any change in the message will cause a change in the digest.  He also knows that the message came from Alice, because he can decrypt the digest with Alice's public key.

The message itself is not encrypted because Alice wants it to be readable by multiple people.  The digest lets everyone know that it really was Alice who sent the message.


Why does my Cordova app contain an SQLite file with credit card tables? We have created a mobile app that includes a view for payment with credit cards. We have used Cordova so we can pusblish our app for Android and iOS. During some tests an SQLite file was found on /data/data/[package]/app_webview/Web Data. This file includes tables named credit_card and whaever_credit_card. Those who found that file didn't mention if this file actually contains credit card numbers or is empty.

I have search this problem and I have found an explanation for it but I am not sure if it is right:

It is a file created by Android web view for credit card autofilling purposes.
It can only be accessed with root permissions.

Just to make sure, we are not doing anything with the credit card the user insert in the input field.

Can anyone elaborate on the security risks? Can anyone propose a way to delete the file or disable it with javascript in cordova or plugin?

The /data/data/packagename/app_webview/* stores the webview cache. The Web Data.db database is the default database that is created to cache the webview data and all the tables such as credit_cards, masked_credit_cards are created by default irrespective of the application using it or not.

First of all I would suggest that you must ask your application auditor to share the POCs(Proof of Concept), if the sensitive details are stored in the local data storage of the application.

I would suggest the following to get rid of the cache:

For the Cordova application you can use this plugin to delete the webview cache.
Alternatively you can programatically delete the folder (/data/data/packagename/app_webview/*) when the webview is destroyed. You can refer this for the logic.

Coming to the security risk, if the credit card details are stored locally then it is a severe risk since the sensitive data stored in the device can be accessed by a malicious user who gains the physical access to the device. Additionally, if the device is rooted i.e. OS security measures are circumvented by the device owner, this data can also be accessed remotely through a malicious application installed on the same device.


Outsourcing software development and its effect on security Some companies build their own software.  Others outsource software development by hiring contractors or other companies to build software they need.

When we need to build new custom software, is there any evidence whether the choice to develop in-house vs outsource software development has an effect on security?  All else being equal, does developing in-house tend to lead to more secure software than hiring third parties to do the software development?

One could hypothesize that maybe outsourcing software development has a greater risk of leading to insecure software, all else being equal.  Maybe when you develop in-house, you own the risk, so developers are properly incentivized to make it as secure as it needs to be -- but maybe when you outsource to a third party, since the third party doesn't operate the software and doesn't bear any of the risk during operation, maybe the third-party developer isn't sufficiently incentivized to use good security development practices and maybe you're more likely to end up with poor security (since that cuts the third party's costs).  Or, rather, one could worry there might be some effect like this.  But is that really what happens?  Is there any evidence one way or the other?  Or is there any general experience or conventional wisdom from industry about the effect on security of outsourcing vs developing in-house?

I'm especially thinking of a government agency who has to make this decision, but I imagine the question is generally applicable.

I'd say that there is nothing per se which would always lead to outsourced software being less secure than an in-house development but there are some common factors which may in practice lead to this commonly being the case

Cost concerns.  If a key factor in winning the work is low cost, then the risk of insecure software is likely to increase.  Whichever way you cut it good software security costs money (IIRC Microsofts early SDL estimates was a 10% overhead), so where a 3rd party has to be cost competitive to win, non-functional aspects of the project (e.g. security may suffer).  This leads to the second point.
Failure to adequately describe the required security level in the contract.  A general problem with outsourcing is that the requirement has to be clear in the contract. Things which aren't in the contract are likely not to be focused on (see point 1). Specifying exact requirements for security in a software contract is hard.  Language like "it should be secure" isn't prescriptive enough to produce a good result, and the contracting company and outsourced provider are likely to have a very different idea of what "secure" is.
"Market for Lemons".  Along with that you have the general problem that in secure development there's a market for lemons.  What's meant by this is that it's very hard for a buyer to adequately assess the security practices of a development company.  There aren't really any good qualifications that can be assessed and buyers are unlikely to go to the effort of manually assessing the security knowledge of the individual developers.

All that said, I'd say that it's entirely possible for an outsourcing company to produce more secure software than an in-house team, the key would be for the buying company to actually prioritize security in a meaningful way during the purchase process, take efforts to assess the claims of the bidding companies, and have good descriptive security requirements in the contract.


TLS private key storage for embedded systems. Are there any best practices? I am looking for best practices regarding TLS private key storage for small single chip embedded systems, such as Cortex-M MCUs, with monolithic firmware stored in internal flash. Most recommendations seem to be very PC-centric, and in most cases those PC-centric recommendations don't even care to protect against physical access. I guess many assume the PC is locked away in some server room, but that is an assumption which does not hold true for embedded devices.

Also, user password entry is not an option for embedded systems, as it has to work without user interaction.

I have so far identified two basic approaches:

Store private keys in external security chip. This basically protects the private key from plaintext access. But as far as I can tell, it does absolutely nothing to stop an attacker from using the private key by accessing the security chip. Either by some exploit in the MCU firmware, or by physical access to the security chip.
Store the keys in internal flash memory of the MCU, and blow fuses to disable the external debug interface. Set up the MPU of the Cortex-M so that only privileged parts of the MCU firmware can access the memory regions where the key is stored. This would seem to provide good protection against physical access, but an exploit in the privileged part of the firmware might result in plaintext access to the key.

It is not obvious to me that either of these two approaches is better than the other.
Are there other approaches? Are there any recommended best practices specific for embedded systems like this? Preferably ranking different approaches and their pros and cons.

I was hoping there were best practices available from some reputable source.
Lacking that, I am posting this as a suggestion, and welcome any input on it.

Methods for secure key storage in embedded devices depends on the threat scenario.

Threat scenario 1:
Both remote and physical attacks.

Threat scenario 2:
Only remote attacks.

------------

The best solution in both scenarios

Single-chip MCU with built-in cryptoprocessor and secure key storage, such as PUF-RAM or tamper-resistant write-only flash accessible only by the dedicated cryptoprocessor.
Any firmware loaded from off-chip must be signed.
Ideally no external RAM.
Use MPU to restrict access to crypto functions to privileged sections of the firmware.
Blow the JTAG debug fuse if defense against physical attacks is required

The second-best solution, scenario 1 only

Single-chip MCU, with external security chip.
All communication with external security chip is encrypted using a device-specific key.
Any firmware loaded from off-chip must be signed.
Ideally no external RAM.
Use MPU to restrict access to crypto functions to privileged sections of the firmware.
Key for encrypted communication with external security chip is stored in on-chip flash.
Blow the JTAG debug fuse.

Con: The most complicated to implement, and any bugs in the implementation may compromise security.
Performance may suffer because of the additional encryption.

The second-best solution, scenario 2 only

Single-chip MCU, with external security chip.
Any firmware loaded remotely must be signed.
Use MPU to restrict access to crypto functions to privileged sections of the firmware.
No need to disable JTAG. Greatly simplifies maintenance.

Con: No defense against physical access. The unencrypted interface of the external security chip is wide open to physical attacks

The third-best solution, both scenarios

Single-chip MCU.
All firmware loaded from off-chip must be signed.
Use MPU to restrict access to crypto functions to privileged sections of the firmware.
Private keys stored in on-chip flash.
Blow the JTAG debug fuse if defense against physical attacks is required.
Ideally no external RAM if defense aganst physical attacks is required.

Con: A successful attack yields the plaintext keys, rather than indirect access to keys.

Pro: Ability to add support for new crypto algorithms by firmware update, as security standards evolve.

------------

Explanations

Two lines of defense against remote attacks

The two lines of defense against remote attacks are identical in all four solutions above.

Bug-free monolithic main firmware. Remote attacks are only possible if there are bugs in the firmware.
Bug-free privileged part of main firmware. Even if the main part of the firmware is compromised due to a bug, the MPU provides a partial second layer of protection for the privileged part of the firmware, and the private keys.

This is where your security focus must be, regardless of hardware solution.

External security chips

Dedicated devices with built-in secure key storage and cryptoprocessor capable of performing all required ECC, RSA and AES functions. Typically connected to your MCU using I2C or SPI

These cannot really be said to add any additional lines of defense against attacks. A better description is to say that they change the outcome of a successful attack. Without a security chip, a successful attack yields the plaintext keys. With a security chip, a successful attack yields indirect access to use the keys. The latter is a marginally less damaging outcome.

But ask the cable-TV industry what they think about this kind of protection. Indirect access to keys is sufficient for widespread cable-TV piracy by having the keys indirectly accessible via internet.

Security chips also come with a significant drawback: They expose an easy to access hardware interface to use the keys, actually making physical attacks very easy.
The exception is external security chips with support for encrypted communication with the MCU, and which even over that encrypted interface does not allow reading the private keys. But that creates a new key-storage problem in the MCU.

MCU internal hardware cryptoprocessor and protected key storage

Provides the same advantage as an external security chip, but without the physical attack weakness or performance issues.

Physical attack vectors, and their defenses

Ranked from easiest to hardest attack vector.

Serial interface to external security chip.

Use MCU-internal cryptoprocessor and key storage instead.
Use external security chip with encrypted interface and device-unique encryption key.
Use no security chip, and store private keys directly in MCU-internal flash instead.

JTAG debug interface.

Blow JTAG fuse.

External boot flash.

Verify signature or hash of loaded firmware.

External RAM.

Use only internal RAM.

Silicon probing.

Anti-tampering hardware.
PUF-RAM.


Which is more secure: saving reference link to file in file system in the database, or save the entire file into the database? We have forms where we get clients to upload images of very sensitive information (passport, signature, etc.). We will store their written information into a database. However, there is the issue of the images. Usually, I hear people saving the images in a filesystem and having a link to it in its cell as a reference. I know I can also save the entire image as a blob in the database.

My question is on the matter of which would be more secure; both from the outside and the inside. This isn't an issue of users uploading malicious files, but more about where would I hide them better?

The difference is not too big from a security perspective. If your database is breached, the attacker will either have the actual data or working access to it. If the files were to be properly stored externally, in the case of an attack as a direct quick response you could deny access to them (by means like dismounting the location they are stored on) but this is a special case.

From a data perspective, keeping a lot of large files in databases is not good and not recommended. Databases were not designed for file storage.

So my vote goes to links in DB and separate files.


How to protect against the new malware Mazar Bot? Mazar Bot is new Android malware that spreads via SMS.
Its capabilities: It can read incoming SMS and send itself, make calls to directory contacts, contaminate Chrome, access to the Network, read the phone status or query the network to know the status and completely erase the contents of storage.

What are the measures to be taken to protect against this new malware? And what are the steps to follow for cleaning an infected smartphone?

The text message to infect your device with the Mazar bot looks like this:

  You have received a multimedia message from +[country code] [sender number] Follow the link http: //www.mmsforyou [.] Net / mms.apk to view the message.

Don't run the link and you don't get infected.

You can also ensure that the option to not allow installation of applications from unknown sources (within Settings > Security) is enabled as this will also block the installation of the APK.

As noted in the post from Heimdal Security, Mazar won't install on a device with the language set to Russian,

  the malware cannot be installed on smartphones running Android with the Russian language option. Mazar BOT will check the phone to identify the victim’s country and this will stop the malicious APK if the targeted phone turns out to be owned by a Russian user

Mazar will "gain boot persistence to help survive device restarts". To remove, nuke the device from orbit and start again.


Should Flash be disabled, or are sandboxes secure enough? Flash is a hot bed of vulnerabilities.

Chrome contains a built in version of Flash, running in sandboxed mode. Obviously, this method is safer than running Flash as a plugin in either Firefox or IE.

But isn't it possible to find a zero day vulnerability in Flash and a way to break out of the sandbox as well? Isn't disabling the Flash plugin altogether the best option?

Obviously, this method is safer.

Surely. Running a program within the browser's sandbox is always safer because the browser creates a contained environment for the third party program (Adobe Flash, in your case) -such as scratch space-to prevent  the eventual malicious code from leaving the browser and installing itself to your hard drive.  You can think of running an untrusted third party application within the browser's sandbox, at a certain degree, as running a program within a virtual machine instead of running in your host machine's operating system.

An other advantage of Chrome sandboxing Adobe Flash programs is that:

  However, Adobe recommends that non-developer Chrome users use Flash
  Player integrated with their browser. Using manually installed
  versions of Flash Player, by following the steps below, means that
  users no longer benefit from the automatic Flash Player updates that
  Chrome provides.

It means the recommended way of running Adobe Flash makes the user benefiting automatically from security updates (as not all users are prone to do that manually, and thus exposing them to threats)

  than running Flash as a plugin in either Firefox or IE

Recently, Mozilla added a feature in Firefox that enables the user to sandbox any program (including Adobe Flash) you want individually -this is may be an advantage for Firefox as it allows to sandbox Java applets unlike Chrome-

As I am not using IE you mentioned, I am not sure whether it sandboxes Adobe Flash programs or not yet. But I think so as I landed on this article (Adobe sets IE as next target in Flash security work) written three years ago.

  But isn't it possible to find a zero day vulnerability in Flash and a
  way to break out of the sandbox as well?

You are right. Sandboxing mechanisms are not that perfect. Whether the sandbox is related to Flash or any other third party programs, it is common for attackers to break the security constraints of the sandbox.

Speaking about Flash and Chrome, just last month there has been a real world example where the Flash sandbox in Chrome has been escaped (Hacking Team’s Flash 0-day: Potent enough to infect actual Chrome user). But as I said, not only Flash sandboxes can be escaped: I can mention to you randomly (CVE-2015-0016, escaping from IE sandbox) and you can find so many at your will there for different browsers.

  Isn't disabling the Flash plugin altogether the best option?

If you are talking only about Flash player plugin, then you are right. It is no longer recommended (Facebook calls for end to Flash as Firefox blocks it over hacking holes). HTML5 is the recommended technology instead (Comparison of HTML5 and Flash)


Can SD-Card be a vector of a BadUSB type attack when used with a USB reader? The firmware of a USB flash drive can be maliciously rewritten in order to make it appear as a rogue device (like a keyboard, a network card, etc.). Since several different kind of devices may be simultaneously connected to the same USB port, it very very hard (if not impossible) for the computer OS to distinguish genuine from rogue devices. This is called a BadUSB attack.

SD-Cards rely on the very same technology than USB flash drives: the same NAND memory, the same controller, the same kind of firmware running all together. So, theorically, the firmware itself should be vulnerable to the same kind of attack.

However, at least when the computer provides an internal non-USB SD-Card reader (as can be found on laptops where the SD-Card reader is connected directly to the PCI bus), the OS would never expect to see a keyboard or whatever to be plugged on the SD-Card reader slot, the protocol does not even allow such kind of weird thing, so a BadUSB type attack against SD-Cards would be moot.

However, I wonder if this remains true when one uses an external USB SD-Card reader? Can the SD-Card be infected in a way that, when used together with a sane USB reader, it will be able to trigger a BadUSB type attack against the computer? Or can an SD-Card reader be considered as a secure "proxy" between the computer and a potentially malicious SD-Card?

I can't say that it's always the case, but all of the internal SD card readers I've looked at were actually USB devices - this puts them in scope for BadUSB.

Internally, an SD card is indeed very similar to a thumbdrive - and there have been attacks against them released. So they can be reprogrammed to change how they behave, just as you can a thumbdrive. So, there is certainly something to this.

Myself and Brandon Wilson released the first public BadUSB code - when we did this we also looked at SD cards, trying to see how they could be leveraged to perform similar attacks. The answer we came up with was that there wasn't a reliable way to do it.

The attack vector here would be a malicious SD card would behave in a non-standard way to exploit a vulnerability in the firmware of the reader - as it's the thing connected to USB, and potentially able to do more interesting things - in order to take control of the USB interface directly or apply modify the reader's firmware to facilitate further attacks.

The problem with this? You have to target specific readers (by controller & firmware version), which means that it has some value as a targeted attack, but can't be made reliable or generic enough to have a large scale impact. So we didn't pursue it in our research. Of course, it's worth noting that there aren't a huge number of companies that develop the controllers that the readers use, so there's some potential for targeting a relatively small number of common controller / firmware combinations and covering a decent percentage of the market.

So, to answer your question - it isn't a secure proxy, but it is a complicated proxy. If an attacker is able to learn about your specific configuration, and is willing to spend the money on research and development - it is possible. But, that said, if you are facing that type of attacker, there are almost certainly better options for them.

In general, pretty much everything that connects to USB, from mice to the internal root hub, are potential targets of BadUSB attacks. Some are harder to leverage than others - thumbdrives are ubiquitous and easy to modify, so they became the face of the attack, but they are far from alone. If it's connected to the bus, there's always a risk that it could be modified with malicious firmware.

It's been pointed out many times, but keep in mind that BadUSB isn't really a vulnerability, it's a feature. Everything that you see in a BadUSB attack is compliant with the specification - that's why there isn't an effective defense. The host has no way to know if the behavior is desired or not.

It's also important to remember that BadUSB isn't just devices showing up as another device type - it can change how the device behaves, while appearing to act normally. One of the demos that we released was a hidden partition that was only accessible if you know the right trick - we had also toyed with self-destructing drives, and drives that made a backup copy of anything deleted, so that even if the drive is formatted, it still can contain sensitive information (we didn't release these).


Should we confirm other personal details before security questions during password resets? I've been tasked to work on a password reset tool for my company website. This tool is for a support person to provide a new reset password over the phone in case the customer does not receive the email or is locked out of their email account.

Now firstly I would personally say this isn't ideal as I believe there are other methods such as receiving a reset code via phone - however as that's apparently not an option I was left with the task.

So I was tasked to add 2 security questions to the users' accounts, where the questions are pre-selected (by the user) out of about 14 questions. The idea being that a user will call and be asked the questions and if both answers were correct then the password would be reset and given to the end user.

While building the reset form I went ahead and decided for extra security to add a post code (UK company and customers) and their primary contact number - both which are required on sign up. The process then being: take users email, confirm post code and primary phone number, ask for security question answers - if all ok then give new password.

The disagreement I had was with the other members of my team who thought this amendment was completely unnecessary.  Personally I thought this would be an additional step from a data protection point of view and an added level of security.

My question is who is right?  Am I being too protective or are the other members of the team being too hasty?

Personally I thought this would be an additional step from a data protection point of view and an added level of security.

This is correct.

  The disagreement I had was with the other members of my team who thought this amendment was completely unnecessary.

This might also be correct.

The more information you can get from the user, the more confidence you have that it's actually them. But that's not the only thing in play. Why limit this idea to password resets? Why not ask them for their birthdate and phone number on every login? Or every page?

Security always needs to be considered in the context of a threat model. What sort of attackers are you going to protect against, and what sort aren't you? This needs agreement across the business, because it might vary depending on what sort of information you're storing, or how important UX is to your business, or how much of a selling point security is, or what your budget looks like.

We can't tell you if your plan is too much (or, for that matter, too little) for your product. That's a judgement call, and one that your team will have to make.

What we can say is that it's pretty common to just require a few security question answers before resetting. There is also often some leeway for the customer service representative, where they can ask more or fewer questions depending on how sketchy they feel the person on the other end is acting.

But again, there's no fits-all answer.


Can dual NIC Snort machine cause threats to bypass firewall? I am thinking about building a Linux Snort machine that can listen to both WAN and LAN traffic.

Setup I am thinking about:
Snort computer with two NICs
One NIC connected to hub/tap outside firewall (WAN)
One NIC connected to hub/tap inside firewall (LAN)
Management from the Snort machine itself.

My question is:

This setup creates a physical path between the WAN and the LAN that bypasses the firewall. Could viruses or trojans or malware or other threats bypass the firewall and go from the WAN into the Snort machine and then to the LAN and affect LAN computers?

I have read about configuring the NICs with no IP addresses, but I have not been able to come to a conclusion about my question.

Generally speaking, yes, dual homed devices can - and often will - be used to create a pivot point for attackers.

Yet, your sniffing machine would be in a significantly less exposed position as maybe a server in a DMZ. On the other hand, parsing is hard and snort does exactly that; I am not confident to proclaim there are no vulnerabilities in snort. However, as you described, a physical connection is there so it very well could get infected and act as a pivot point into your network.

Besides using iptables to restrict the outbound network traffic of that machine, you might also consider using a data diode to ensure that behavior. Configurations on that machine might very well be changed when the attacker gains root; as simple as iptables -P OUTPUT ACCEPT. A data diode would still hold up any outbound traffic.


Can one reliably show HTTPS status in browser (not just the lock in the URL bar)? I'm almost certain this isn't possible, as it would probably be too exploitable, but I wanted to ask the community just in case.

Is there a way to determine and display the state of HTTPS on a page (working vs. not working) within the browser (i.e. as a status on a website somewhere), in addition to the lock icon provided in the URL bar of (most/all) browsers?

I'm trying to figure out a way to blatantly tell users wether the connection is secure or not. Another option would be including some sort of instruction set for how to check, though that's obviously a greater barrier. (If anyone has seen something similar somewhere, I'd love to see an example).

Thanks!

No, this isn't possible. Anything you display on a webpage can be manipulated easily, using things like Javascript and thus cannot be trusted.

The padlock on the browser is the only reliable indication that HTTPS is working on a page.


Bruteforce all IP addresses on network with Hydra I have been tasked to pen test a computer on my network. I have done some social engineering to get the username and password of the device, and I know ssh is open on the computer. However, I do not know the device's ip address. Given a file of all the IP addresses on my network, how can I have Hydra attempt to log in to each device on the network with the given credentials? (I am not limited to hydra, any program that runs on macOS Catalina would work for me).

Did you try listing the options for Hydra with hydra -h or man hydra?

  -M FILE list of servers to be attacked in parallel, one entry per line

(No, you didn't.)


Why has salt option been deprecated as of PHP 7.0.0? http://php.net/manual/en/function.password-hash.php

Is that less secured ?

echo password_hash("rasmuslerdorf", PASSWORD_DEFAULT);
=> $2y$12$QjSH496pcT5CEbzjD/vtVeH03tfHKFy36d4J0Ltp3lRtee9HDxY3K

And with extra cost:

$options = [
    'cost' => 12,
];
echo password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);

=>$2y$12$QjSH496pcT5CEbzjD/vtVeH03tfHKFy36d4J0Ltp3lRtee9HDxY3K

Is that "too predictable" ?

Extra question : if an encrypted password above is exposed, how long is would take to "crack" one  ? Given that the hackers have dozen of good computers which only took few hours to crack our admin password in sha256 without knowing the salt.

Disclaimer : I first read about encryption 13 years ago but my brain CPU was never able to fully process those concepts, too much math. Now my boss assign me the task, so I guess asking simple question may help me a little.

It is not less secure because in absence of a manually provided salt, a securely generated salt is automatically created and used.  So, the option of providing your own, while it could be as secure, would never be more secure, and could very easily be (and probably often was) less secure if salt generation technique was poor.

If it meant that no salt as all were used, that indeed would be less secure, but thankfully that is not the case...You're just getting a more secure default configuration.


Can I force unique passwords for domain admin accounts? Best practices would dictate that domain admins should not be logged into as such for daily tasks.

Ideally the user would have two accounts; Their "daily" account and their domain admin account.

How can one assure (through a technical control) that Bob doesn't use the same password for his domain admin account that he does for his daily account?

For this to work, I would assume there would need to be the ability to tie ownership of the 2 accounts to a specific entity and enforce password uniqueness between those two accounts and those two accounts only.

Otherwise, people could determine that someone else is using the same password as them if uniqueness was forced across all accounts.

Forcing unique passwords for both domain admin and Daily account would simply do people so they use like "MyP@ssw0rd1" for their Daily and "MyP@ssw0rd2" for domain admin.

That would do the passwords easly guessable anyways, knowing the Daily password would make it easier for an attacker to deduce the domain password out of this.

The risk you want to protect against, is if malicious software or a malicious user could access the domain admin account, by knowing the password of the Daily account.

To protect against this I would suggest using a 2FA token solution with OTP tokens. Either time synced or event synced. Or even a Yubikey. The good with code-based OTP tokens or yubikey, is that they can be used in legacy password systems by simply replacing the password validation module with one that can validate a code consisting both of a static password and a OTP. 2FA is then only enabled for domain admin, which means the token can be securely locked away in a safe while its not used.

Another solution is to enforce a 2 person access rule. Simple, you have 2 domain administrators. One domain administrator a password half he knows without the other one looking, then the other domain administrator types Another half that he knows, without administrator 1 looking.
Then both persons must come in unison to access the domain administrator account, which both increases traceability but also security since you would need to know both password halves so even if both administrator set their halves to their Daily password, security is not compromised.


Figure out how internet access is being monitored I suspect that someone is monitoring my internet connection.

Said person has revealed information about sites I visit and online conversations (Facebook) even when I am not using his/her network.

What software or techniques could I could use to figure out how this person is monitoring me?

Since you do not state what kind of "help" you want, I will have to guess. So I suggest the following:

Talk to your father.

With "talk" as in "talking", not "shouting reproaches". Your father installed this monitoring system for a reason, probably a mixture of making him less worried about your well-being, and a safety feature against the re-enacting of some of the less glamorous parts of your past behaviour.

Engaging into a technical evasion war with your father will not work in the long term. Every good strategist will tell you so: don't fight an enemy who, by definition, will always be more powerful than you. Your father has access to the Ultimate Power: the money flow which pays for every single machine and Internet access that you may use. Even if you could somehow detect and remove whatever monitoring system he put in place in your machine (assuming that's the case), in the long run he will still win, even if that entails removing your computer altogether.

So, admit that this battle is unwinnable, and begin the diplomatic part: negotiate surrendering conditions. You are a kid (or used to be) so you know that fathers cannot withstand sweet-talking from their offspring.


Getting called from hidden caller ID, what are the dangers if I answer? My girlfriend has been getting calls on her iPhone from a hidden caller ID for several days in a row now. She has not answered any of them because we figured it can't be anything good if it's hidden.
However, as the calls are relentless, we are curious as to who or what it is about and she is thinking of answering the next call.

What could be the dangers of this and how bad of an idea is this?

If you do not say anything, then the only danger is that the caller knows that the number is live. But that does not seem to be a big risk since they appear to think it is live anyway.

Just answer but say nothing except "who is this please?" then put the phone on mute to help you resist the temptation to say anything. Phone scammers are experts in playing on people's emotions to get them to engage. The trick for you is to not say anything except to ask questions. Do not give any information but turn every one of their questions back into a question. It might seem childish and rude, but it's effective.

There are lots of legitimate reasons for legitimate companies to call you while hiding their number. If you find out that it is legitimate, then you should be able to go to the official website to get a number where you can call them back on. Aim to do that.

If it is not legitimate, then call your phone provider to get the calls blocked.


Should the Router or Firewall Come First? Network scenario....  I have a typical enterprise network meaning

ISP > Edge Router > Firewall|DMZ  > Switch > LAN

I know there are several debates about what device comes first, but based on a typical medium-size office (500 people), what should come first in the network architecture; the firewall or the router?

My thought was that the router should come first because the IOS firewall would be the first line of defence, then a Palo or Sonicwall for the firewall would come next to take what's left..

ISP->Edge Router->Firewall->Main Switch->LAN is fine. That even helps if you have complex routing configurations like xGRP tunnels. Also helps in multi-WAN scenarios. Your objective is to protect your internal infrastructure, not the Edge Router itself. Any Edge router should support extended ACLs so if you want to protect against something very specific you can do it anyway.

The only case where you should put a Firewall in front of the router is when you have type-specific targeted attacks (using exploits, etc) against that particular router model, but that is a very rare case.


Parrot OS live vs Tails Is Parrot OS as secure as Tails?
Tails is running from USB, loading to RAM so it means that it doesn't use local computer storage. After each start, Tails starts a new session and doesn't store files you had in previous sessions. It means that you can browse using flash drive where installed Tails on someone's computer, but he won't see anything of it because Tails worked in RAM, it erases each shut down.
Parrot OS is an operating system for pentesting, which has hacking and anonymity tools. You can use it from USB too: install .iso file into flash drive, and start it as "Live CD". After restart data was in that session won't appear.
So, Can you use Parrot OS live mode instead of Tails, will it be as private, orDoes Tails have another security and privacy features except routing all traffic through Tor?

Parrot is by definition a Penetration Testing oriented OS based on Debian. This basically means that is a distro with a bunch of repos + already installed applications useful for pentesting. On the other hand, we have Tails which is NOT a PT oriented distro, it is instead a privacy/anonymity oriented distro.
With this information, we can see that the main idea of the creators of Parrot was to do a pentesting distro and not a secure one in terms of privacity. therefore I would not recommend you using it if your idea is to preserve privacy. I would use Tails instead.
As another funny example of the security of the penetration testing images was the fact of the old Kali versions which had the root account with default very weak credentials (root:toor). Just because a distro was made to be used on penetration testing it does not mean necessarily that the distro itself is secure.


Detect HTTPS self signed certificate in (DPI) firewall TL;DR : Can a DPI firewall detect HTTPS connections that use a self-signed certificate? If so, how?

A DPI firewall that should not allow VPN connections. The firewall blocks all VPN ports by default and on port 443 it inspects the protocol to be SSL/TLS. Wrapping my VPN connection in stunnel, I can bypass this detection mechanism on port 443. Most stunnel connection use self signed certificates. Can the DPI firewall detect HTTPS connections (in this case the stunnel connection) that uses a self-signed certificate and if so, how?

Note: I want to come up with a proper solution before reporting this bug.

Thanks in advance.

Can a DPI firewall detect HTTPS connections that use a self-signed certificate? If so, how?

It is possible to implement such a functionality inside a DPI firewall, but that does not mean that the ability is implemented in every DPI firewall or even enabled in the specific configuration used at your side.

Usually if a DPI can do SSL interception (i.e. active man-in-the-middle of SSL/TLS connections) it will also verify the certificates. Depending on the configuration it will reject all connections which use certificates not signed by a trusted CA. But it is not known if the firewall at your site can do SSL interception at all and if it is enabled - but you could check by looking at the certificate chain. Often such DPI solutions can also be configured to accept bad certificates, although this is usually not the case by default.

It is also possible to look at the certificates of SSL/TLS connections without doing SSL interception, because the certificates are transferred in clear. But this functionality is not very common because there is not such a big use case for passive inspection of TLS traffic, that means usually inspection of the transferred data is needed which requires active SSL interception.


Fetching GPG private key from Linux server to decrypt files on a Win 10 computer in production I have a need to fetch automatically the GPG private key from a Linux server to decrypt files on a Windows 10 computer in production.

There are a few challenges here:

How to assure SCP from the Windows 10 to the Linux server that not everybody who operates on the machine can perform this task?
Where to store the private key to decrypt the material? I don't want the private key to be stolen by anybody. I thought about a script which fetches the key, imports it to a temporary GPG keystore, decrypts it and then deletes the keystore securely. But that is far beyond from security as everybody who has a bit of knowledge on batch scripting can fetch the key anyway (see for point 1).

Anybody an idea for a secure design how to handle this?

windows 10 also supports curl, so the following command can also be used:-

curl scp://example.com/file.zip -u user:password

If you create a scheduled task to fetch key and place it in the windows administrator profile and another task that signs any file with that key you should be secure.

Unless the users run mimikatz or other memory dumping tools or have local administrator access.


How can I set up a secure virus laboratory? I've been playing around with virtual operating systems for some time and began wondering: would it be possible to set up a virus laboratory in a virtual machine? If not, are there other ways that do not require me to go out and get an additional computer?

The virtualization software and even the hardware can contain all kinds of bugs that would allow a guest program to access the host. There are already known malware that detects VMs and some may be able to use these vulnerabilities.

Also don't bother about dual-booting or changing disks as virus/rootkits that attack BIOS are not even new.

The only secure solution is to use a physically separated computer with an air gap.


Can Internet logins occur from the private IPv4 address range (10.x.x.x)? I’m seeing many logins to my Stack Exchange OpenID account from the private IP addresses 10.7.2.16 and 10.8.2.15. Another of my accounts says that it was logged in from 10.80.0.144. I was under the impression that accessing webpages via the Internet requires a public IP address.

So, can Internet logins occur from the private IPv4 address range (10.x.x.x)? More specifically, I’m curious if this suggests unauthorized login attempts via the Internet or something else, such as internal logins from the relevant servers.

Well, it can be a misconfiguration of a webserver if the client uses proxy to reach the outer world and proxy adds a header 'Forwarded' - see the wikipedia example here - it can look like 'Forwarded: for=192.0.2.43, for=198.51.100.17' - and it's totally OK for private network addresses to appear in for-part of the header. If the webserver tries to separate users originating from the same IP but having different LAN ip's in an old way - it can result in such a metrics. However, to be fully correct, an external IP address should be shown as well.


Possible security issues with on demand generated image from database I want to know what could be the potential risk with the displaying part of this behavior.

For the upload part:

A form with a file upload for image.
Image content is save into Mysql "longBlob" type (It is a requirement)

For the display (loadImage.php):

A script loadImage.php will receive as parameter the record id.
It Will set the proper image header
It will echo the longBlog content

The image will be load like this: src="loadImage.php?id=%i".

Apart from it being an inefficient way to store an image, storing the image in a database isn't any riskier than storing it on the filesystem.

The major difference between the two is that filesystem storage is vulnerable to directory-traversal attacks, where database storage is vulnerable to SQL injection attacks.


Most popular RSA key format We are trying to decide on which RSA key format our application should use. The ideal format would be widely used and supported in most of the popular platforms/frameworks. This would make it easy for 3rd parties to integrate with our system. So which one of the RSA key formats is closest to that?

For private key storage, you will find mostly:

What OpenSSL does. This actually is the ASN.1 format specified at the end of PKCS#1 (type RSAPrivateKey). When that object is Base64-encoded into PEM format, the header will be: -----BEGIN RSA PRIVATE KEY-----. The raw (binary) format is "as is", but PEM includes options for symmetric encryption (with a key or a password). This PEM format is not really standardized or documented; it is "what OpenSSL does".
PKCS#8. For a RSA key, it will be a wrapper around the ASN.1 format from PKCS#1, with an explicit specification of the key type (i.e. "this is RSA"). PKCS#8 also includes options for symmetric encryption. OpenSSL also supports PKCS#8 and can encode it into PEM, this time with the header: -----BEGIN PRIVATE KEY----- (notice the difference with the previous case: the key type is no longer specified in the PEM header, since the ASN.1 structure contains that information). While a PKCS#8 file which is PEM-encoded could contain PEM-level encryption, this is rarely done since PKCS#8 can also do it internally. PKCS#8 benefits from support in many frameworks, e.g. Java knows that format natively.
PKCS#12, also known as "PFX". This is in fact a generic archive format which features optional encryption and integrity checks, and can be used to put together one (or several) private keys and the corresponding X.509 certificates. If you store public keys in certificates, then you will want to use that format since it is natively known by many systems (Windows and MacOS X can read it directly, for instance).
The OpenPGP format. This is what will be used in most "keyrings" as handled by GnuPG. It is not based on ASN.1. If you have to reimplement it yourself, then it is somewhat simpler to manage than PKCS#8. This format is rarely known natively by existing programming frameworks, but ready-to-use opensource libraries are available (e.g. GnuPG or Bouncy Castle).
What OpenSSH supports. SSH has long used its own formats, but for private keys, OpenSSH can feed on the OpenSSL formats (both the OpenSSL-specific and PKCS#8).

For public keys, there are a few twists:

In the OpenSSL and X.509 worlds, public keys don't exist "as themselves" but only as part of X.509 certificates. You may want to store your public key in a certificate structure, which could be (by tradition) self-signed, since there is a "signature" field in the X.509 certificate format. The part of a certificate which contains the public key itself is called SubjectPublicKeyInfo (look for it in the standard) and is a wrapper around an algorithm-specific format, which brings us back to PKCS#1. DER-encoded SubjectPublicKeyInfo structures are occasionally spotted in real-world applications, but they are quite rare.
OpenPGP has its own formats for public keys.
OpenSSH has its own formats for public keys. Mind the plural: there are several. Start here for descriptions.

For interoperability and integration, I'd say that it is a tie between X.509+PKCS#8 (with possible use of PKCS#12), and OpenPGP. Personally, I'd use the former, but that's mostly out of habit.


How do cryptographic algorithms help hackers to bypass Antivirus software? I was wondering how do hackers use cryptography for bypassing antivirus software.

I don't have some deep understanding on how antivirus software works, but I know that every antivirus has base of signatures, so when we scan .exe file it actually compares signature of .exe with signatures in it's own base, and if it matches, antivirus will identify .exe as virus.

So by applying some cryptographic algorithm on .exe file (using tool "Crypter"), they change signature of .exe, so antivirus can't detect it as malware, right? But concretely, how do they apply cryptograpyic algorithm on .exe file? I saw only in my book how plaintext is crypted.

Executable file encryption is rather obfuscation than real encryption, since encrypted file still have to execute. So "decryptor" part has to know the decryption algorithm and/or key.

Antivirus software has:

various emulators, for x86 code, x64 code, normalized JavaScript code etc.
various decryptors/unpackers for all "crypters" and archives known to antivirus vendor (eg. ESET has 1228 decryptors/unpackers as for now)

As for your question: basically signature matching is done after unpacking, decrypting etc., when antivirus engine finds out, that there are no more known archive/encryption/obfuscation levels for current file.

However there are 2 exceptions:

There are modular viruses, eg. Flame, in which only one module has decryption key for another module, which has decryption key for another module and so on. Catching such viruses require writing dedicated code in antivirus engine.
There are ransomware viruses, that, while not being encrypted themselves, can encrypt random files on infected computer in a way that nobody but virus author has decryption key. Files encrypted by such viruses are not recoverable by antivirus software.


What to do against continuous FTP attack I have a server (windows 2008) and this server uses WebsitePanel to host some websites.
I tried to setup Mozilla FTP server, but I cannot get this to work. As I do not use it I do not mind.

However by accident I almost immediately noticed that a hacker tried to gain access to the FTP.

I can see this because Mozilla FTP shows all failed logons and shos an IP-address. As FTP doesn't work all logons will fail. And as nobody is supposed to use this FTP, it can only be someone with bad intensions. Plus most attacks seem to originate from Russia and Brazil and my websites are all in Dutch.

At first I entered the IP-numbers that Mozilla showed me in IP and domain restricions and FTP domain and IP-restrictions (server wide). But I noticed that when the same IP-address was used (which doesn't happen that often), that they could still try to connect to FTP (my idea was, what is than the use of this IIS protection).

So now I created in my Windows firewall a block restriction for all programs and entered all IP -addresses (over 200).

What I would like to know is how do they do it. I can see they try to logon and they use about 15 attempts, than within a second they change IP-number and again 15 attempts. So I cannot believe these attempts are from different persons.

Are they using IP-spoofing?? If so, can they random choose a new IP-number? Because than there would be no use in blocking these IP-numbers. Or are they using relays, ghost computers or however you want to call it.

Furthermore I noticed they know which websites I have on that server. Did they get access to my server somehow and thus know the names of the websites, or are they using some reverse IP option to find out which websites all go to my IP-address??

Also I noticed that sometimes for a certain period thay use the email accounts I have and spoof their spam email to pretend as if I send it. Again, did they get access to my computer or as they know the websites simply guess some email addresses that go with these websites (email@ and info@ after all is not that hard to guess).

On my server I cannot detect anything strange, no virusses, no strange files, nothing has changed??

I thought I could use the Mozilla FTP as some kind of honey trap and that at some point I would have all the computer IP numbers that they use to do this. But if they can simply choose a random number than there would be no point in doing this.

Your guess is right - the attackers can use an almost unlimited range of IP addresses if they have a botnet. So trying to block IP addresses manually is pointless.

There are tools such as fail2ban that can be setup to block any that meet specific rules, but if all they are trying to do is access a service you do not offer then try not to worry too much.

As regards your email question - generally return-email-address spoofing does not imply they have compromised anything. Anyone cab set their return address to be anything they like.


Decrypting application data from pcap Full disclosure I am front end developer with hardly any knowledge of security trying to complete a security challenge. All info below I picked up in the last 12 hours so if it doesn’t make sense feel free to correct me. Lastly I don’t consider this cheating because I am not doing the challenge to get a job I was just bored tonight, but it’s 5.30am and I refuse to be beaten.

So far I have this :

The file is a pcap file
I can open this pcap file in wireshark and see the TLS handshake
Somehow I am meant to be able to decrypt the application data by generating a private key using the information about the cipher and other info in ‘Server Hello’ packet

I have only found 1 blogpost on how to do something similar, I am thinking that being in a security challenge this must be a common type of attack. Does this have a name and can anybody shed some light on how to go about this?

Somehow I am meant to be able to decrypt the application data by generating a private key using the information about the cipher and other info in ‘Server Hello’ packet

It does not work this way. If it would be possible to decrypt the TLS traffic just by combining information found in the packet capture then TLS would be terrible insecure since then essentially every passive attacker could decrypt the traffic.

Instead you need for decryption the private key of the servers certificate in case of the obsolete RSA key exchange. In case of the preferred DH key exchange even having this private key is not sufficient but you'll need to extract the secret specific for this connection from the client or the server. See Decrypting TLS in Wireshark when using DHE_RSA ciphersuites and SSL on Wireshark Wiki for more information.


External network DNS spoofing I've been thinking recently if its possible to DNS spoof an external network. Let's say for example you are attacker.com and your victim is of course victim.com. Then I've thought of 2 scenarios:
1. You somehow manage to find victim.com DNS server, poison the cache there and just wait for your victim to connect
or 2. You bombard victim.com with resolved queries from a previously setup DNS server, which queries are of course forged.

So my question is : Is scenario 2 possible in any way? Because i couldn't find a reason why it would not work, and knowing my luck there's a simple answer to that.

Here's the paper I've been reading about it :
SANS

To do this you will have to spoof the IP address of the DNS server and if you must pass through the internet, the attack will probably won't work for two reasons:

If the DNS server of the victim is in his intranet with a private IP number you won't be able to send the packet through the internet since private IP addresses from private ranges are not rooted over the internet.
If you spoof a public IP address and you try to send it, your ISP will probably not root it and it will just drop the packet. Before rooting a packet some rooters check if it is plausible that the source IP came from a specific interface.

If you don't need to pass through the internet to reach the external network, your private router may root the packets depending of its configuration


Under what conditions is the Client trying "the next" CRL Distribution Point? We've got a scenario where the CRL is distributed to 2 different Locations.
One ist accessable from a private network and not from the internet.
The other one is asseccable from the internet but not from the private network.
So to make sure that everey client (either located in the internet or in the private network) can access the CRL via http, I assume that I have to include both Locations as CRL Distribution Points in the certificate.
I also assume that the Client (when checking the CRLs) is asking the 1st CRL Distribution Point first and if it does not get an "appropriate answer", it's asking the 2nd CRL Distribution Point. If it does get an "appropriate answer", it stops. Am I right until here?

What is an "appropriate answer", that makes the client stop asking next CRL Distribution Points? Does it only stop if it gets a proper CRL-File, or are there other scenarios (error codes, "not available"-messages) that make the Client stop trying "next" CRL Distribution Points?

CRL distribution points are location that the client must be able to resolve to a file. If the client is unable to obtain that file, it will go to the next location.

In order to obtain that file, the client must be able to:

Understand the schema of the endpoint (HTTP, LDAP, File, Whatever...)
Resolve the host name (if appropriate).
Contact the host name using the protocol mandated by the schema (HTTP, SMB, LDAP, etc.)
Query for the file path and receive an answer that is not an error.
Obtain the file data and verify that is is signed by the relevant certificate chain. (see RFC 5280 for reference)
Verify that the file is still valid (i.e. that the "next publish date" field is not in the past)

Now, the exact behavior of the client is dependent of the implementation so it's hard to be specific and since CRL validation tends to increase connection time massively, most real-life client will, by default, include some performance optimization that will cause the actual CRL validation not to be fully performed in many cases.


PCI-DSS Requirement for Application Level Security? Before I arrived at my current company we obtained the services of PCI consultant who gave us some very specific, if questionable, advice on encryption requirements.

The particular piece of advice I am suspicious of is that of making sure that cardholder data is encrypted as is moves across our internal (detached) network. The method of encryption, we were told, needs to be at the Application level, and Transport level is not allowed. So, instead simply using HTTPS to move a file, we are having to encrypt the file using PGP before sending, then decrypting after it arrives.

I simply can't see in the documentation where this is a requirement. Has anyone else been told the same thing? Is there a precedence for this?

The document we are using is the May 2013 Card Production Logical Specs

The advice your PCI consultant gave you does not match PCI requirements.  Ask them for a citation that "Application level encryption" is required across the network.  Any PCI consultant has to at least tell you what DSS requirement they're citing.  "Pictures or it didn't happen..."

Section 4.1 of the PCI DSS requires you to encrypt on untrusted networks; if your internal network is properly protected as per Section 1 then you are permitted to transmit unencrypted PAN data on it*.  And Transport level is explicitly listed as an appropriate protection:

  Use strong cryptography and security  protocols (for example, SSL/TLS,
  IPSEC,  SSH, etc.) to safeguard sensitive  cardholder data during
  transmission over  open, public networks.

When storing PAN data, you are required to protect it, which in the case of encryption section 3.4 states you should use:

  Strong cryptography with associated  key-management processes and
  procedures

Which may be where your consultant is coming up with "Application level encryption", but that's on disk, not on the wire.

*Note, even though you can go without encryption on the backend, you probably shouldn't.  Among other things, DSS 8.4 requires that credentials be encrypted during transmission, and if you're sending PAN data in the clear you're probably sending credentials in the clear.


How risky is it not to install ssl? I would like to have more insight about when a server should install ssl, in particular when it is worth the money to pay for a valid certificate. As my clients often have little understanding of why they need ssl, and since a certificate is quite costly compared to renting a vps, I would like to know some statistical numbers or other descriptive information.

Suppose a user forum, which has thousands of users, and all their usernames and passwords are sent unencrypted over the internets. There are no credit card informations, or other sensitive data, except the passwords. What would be the arguments for acquiring ssl in this situation, and what would be the arguments not to?

I hope this question is intelligible. I wouldn't know really how to ask more directly.

Thanks for your time and advice!

Without SSL, all that is sent over the wires can potentially be spied upon or altered by indelicate routers. "Altered" includes hostile hijacking of connections and Man-in-the-Middle attacks. These are relatively easy to setup by attackers in the context of WiFi hotspots -- which means that if a user is accessing your Web site from a restaurant or a public park (using his laptop or tablet) then his data (in particular passwords and cookies) can be silently eavesdropped by ill-intentioned people equipped with a readily available 100$ gadget.

Moreover, not only are non-SSL connections easily commandeered by hostile outsiders, but people begin to know it. When your users see that you use passwords without SSL, some of them will think that "you do not care about their security". That alone is not a good thing. You want your users to feel safe, otherwise they'll be tempted not to be your users anymore.

SSL costs are routinely exaggerated, for reasons which are not completely clear (there is some theory on the subject):

On the server: the extra CPU and network overhead implied by SSL is in the 2% range, i.e. not a lot. Biggest indirect cost is that SSL prevents some transparent proxies (run by some ISP) from doing their optimization; it might have some impact if your server hosts big static files. The cost of the certificate can be zero -- or, more accurately, no buying fee, and some administrative task once a year. Even in commercial contexts, the cost of the certificate is negligible with regards to the hosting costs and sysadmin time.
On the client: the main effect is increased latency for the very first connection. When opening the first connection, client and server run the full TLS handshake. But the connection will be kept open for subsequent HTTP requests (the normal "keep alive" mechanism), and if the connection is closed due to prolonged inactivity, new connections will use the abbreviated handshake which reuses the cryptographic elements from the previous connection. the abbreviated handshake is much faster, especially since it implies one less network round-trip.

Nothing beats actual measure, so you are encouraged to experiment, if only with a homemade certificate (aka "self-signed"); but, on the whole, SSL cannot be considered as really expensive (it used to be expensive, 15 years ago, but computers have grown a bit in computational power since these times).


Why is my website getting spammed? Does anyone recognize this type of spam?

  NAME: Bagas
  EMAIL: dq95zxm7l@gmail.com
  PHONE: JCBUIR6ulwtO
  COMMENTS: I must express apaotcipeirn to the writer for bailing me out of this particular scenario. After browsing throughout the the web and coming across notions which were not pleasant, I assumed my entire life was done. Existing without the answers to the problems you have solved through your good short post is a crucial case, and the kind which may have badly damaged my career if I had not noticed your blog. Your main natural talent and kindness in controlling all the stuff was priceless. I am not sure what I would have done if I hadn't discovered such a solution like this. I am able to at this time look ahead to my future. Thank you very much for your impressive and sensible help. I won't hesitate to endorse the blog to any individual who should have support about this matter.

They are using my form "Inquire about product" to send me these spam emails, rather than using the contact forms. There are no links included in any and we receive 15-30 a day!

Will captcha stop this?

Yes, add a captcha to all exposed forms or contact pages on the internet to prevent spam like this


Cipher usage by end users and browsers How do I check in apache logs as to what cipher end users / browsers are using ? Are there other tools to achieve the same to get a result in percentage ?

related link: How can I determine the encryption strength of an SSL connection

Yes, this is entirely possible. What you need is to define the proper configuration setting in ssl.conf file for your Apache web server.

An example of which is:

  CustomLog logs/access_log \
          "%{%Y-%m-%d %H:%M}t %{Host}i %{User-Agent}i %{SSL_PROTOCOL}x %{SSL_CIPHER}x"

where the parameter %{SSL_CIPHER}x displays the cipher that is being used.

A sample output would be something like this:

2015-07-10 23:39 localhost Mozilla/5.0 (some bot) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384

More information could be found on the documentation:
http://httpd.apache.org/docs/current/mod/mod_log_config.html#customlog


Comprehensive audit of firewall - is Internet truly not accessible? We have many Linux servers in several co-locations over the world.  By design, these machines generally should not be able to access the Internet.  Depending on location and role, some sites may have very limited Internet access (e.g. default deny with one or two sites white listed).  So depending on the circumstances, the no-Internet policy is configured either by routing rules at the switch level, or by a filter device (e.g. Untangle).

One team is responsible for configuring the network per policy, and a separate team (me) is responsible for periodic auditing to make sure things are actually working as intended.

The question, therefore, is how to comprehensively check that the Internet cannot be reached?  The naive method is to simply "ping google.com".  But what if Internet is available, but DNS is simply not working?  OK, so ping a known public IP, e.g. "ping 8.8.4.4".  But what if ICMP is filtered, but e.g. TCP connections are still allowed?  What if TCP and UDP are filtered, but raw IP is not?  What if the network team left themselves a little hole (not necessarily by malicious intent, maybe honest mistake, maybe bug in firewall or switch)?

Obviously, ping is a nice easy check when you want Internet access, but it's woefully insufficient for ensuring that Internet is completely blocked.

The ideal approach would be to try every possible combination of

Port
Public IP
Protocol

But that's not practical.  But I'm looking for a reasonable compromise between that and a naive ping test.

My thought was to try to use nmap to look for any open ports on public IPs that should generally be up---public DNS servers.  So, for example (8.8.4.4 is a public DNS server):

# nmap -v -v -v -T3 -sS 8.8.4.4

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-18 10:24 CDT
Initiating Ping Scan at 10:24
Scanning 8.8.4.4 [4 ports]
Completed Ping Scan at 10:24, 0.01s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 10:24
Completed Parallel DNS resolution of 1 host. at 10:24, 13.00s elapsed
DNS resolution of 1 IPs took 13.00s. Mode: Async [#: 2, OK: 0, NX: 0, DR: 1, SF: 0, TR: 4, CN: 0]
Initiating SYN Stealth Scan at 10:24
Scanning 8.8.4.4 [1000 ports]
Completed SYN Stealth Scan at 10:24, 0.07s elapsed (1000 total ports)
Nmap scan report for 8.8.4.4
Host is up (0.0015s latency).
All 1000 scanned ports on 8.8.4.4 are closed

Read data files from: /usr/local/encap/nmap-6.40/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 13.14 seconds
           Raw packets sent: 1004 (44.152KB) | Rcvd: 1001 (40.040KB)

This was run from a server where the Internet access block is believed to be working correctly.  Yet why does it say "Host is up"?  How does it know?  A simple ping fails, and I am unable to use that server with dig.

I was hoping to get away with a simple script that looked for "Host is up" to flag Internet access, but it looks like that would generate too many false positives.

Anyone have any better suggestions or approaches to this problem?

From what you're describing, I'd say that the only way to achieve your goal is a credentialed audit of the server and the firewall, as opposed to network scanning from the server.

The reason for this is say that outbound traffic is only allowed to a single high port on a single host, there's no way that your port scanning approach will find that.

I'd recommend doing a manual review of the firewall ruleset to make sure that the rules work as intended.  Depending on what's used/how familiar you are with that kind of thing, you can either do it manually or use something like nipper to help out.

To explain what you're seeing on the port scan.

All the ports are responding as closed rather than filtered.  That's somewhat unusual for a firewalled connection as most firewalls will drop blocked traffic rather than explicitly reject it.

However that explains why nmap thinks that the host is up.  Nmap uses a couple of mechanisms to determine that a host is live and one of them is a TCP ping (look at the -sP section of this page).  If it gets a response to that it assumes that the host is up.  As your firewall appears to be responding with RST/ACK (the closed message) that would cause nmap to think that everything is up, whether it is or not.


UEFI secure boot anti-rollback I haven't seen any seen mechanism by which UEFI can detect the most recent update to a binary from being swapped out for an older binary that was signed with the same key as the up-to-date binary. Google's vboot is the only PC firmware I know of that uses anti-downgrade counters. Does the UEFI specification specify a way to thwart rollback attacks?

UEFI of what ?
Generally, there was no such specification initially.
The latest UEFI specs can be found here.
Some manufacturers use something called "Secure Rollback Prevention”. If enabled, it prevents any downgrade.
For example, Lenovo Thinkserver series implemented this in order to prevent people using security-flawed versions. For specific models, the BIOS cannot be downgraded to a level lower than the version listed once the BIOS is at that level or higher.
You will have to see if your UEFI has such a feature, but note that even if there is one, it may be bypass-able.
Since something like this is possible, a forced downgrade even with an option to protect against it may be trivial to accomplish.


Does a professional website know that person A switches the Chrome "user" and logged into its website with another email address? Let's say I have account A on site example.com that has a policy of strictly one account per real person. I then create a new Gmail address, use that Gmail address to open a new Chrome user (not incognito), then use that Chrome user and session to create a new account B on example.com.
I know that example.com can see that two accounts A and B are currently logged into the website from the same IP address. But can it know that it is the same person operating both accounts? For example can it track the ID of the browser (if there is such thing), or the ID of the computer / internet session?
Does it matter if I operate using desktop / laptop / smartphone?
To ask my question in another way, how is two people using two accounts on the same device different from one user using two accounts in the same device from the point of view of example.com?

how is two people using two accounts on the same device different from one user using two accounts in the same device from the point of view of example.com?

Nothing. example.com may know that there is two accounts connected to itself on the same device and even know that accounts are open in the same browser, but can only guess whether it is the same person or not. Your question is logically out of context, I can open another account on the same device and give it to my brother for him to use. How on earth server will know it is me or not?


How do I get the RSA bit length with the pubkey and openssl? I have a public key generated with ssh-keygen and I'm just wondering how I get information on the keylength with openssl?

ssh-keygen -lf /etc/ssh/rsa_key.pub
2048 d1:cb:15:df:5d:44:...

2048 is the keylength


Web application reacts differently to Windows reserved names like CON, AUX, NUL Several web applications I tested have the behavior that reserved Windows filenames such as AUX, CON, NUL, PRN, COM1, LPT1 have different behavior than other pages. For example, http://example.com/foo will give a 404, where http://example.com/aux will give an 500 error.

What causes this behavior? Does this indicate a security problem?

By default on an IIS server the path of a URL is validated by using the same rules that determine whether a Windows file system path is valid. So this is the reason why http://example.com/aux can give an 500 (aux is an invalid directory name) but http://example.com/foo a 404 (foo is ok). This behavior can be disabled by setting
relaxedUrlToFileSystemMapping = true in web.config.

Apart from a possible small information disclosure that you are running an IIS server there is no security problem.


How to block user from using GoToMyPC or Teamviewer Recently, we found our users install GoToMyPC and Teamviewer on their workstations.
What is the standard approach to block users' personal use of remote desktop control?

There's a few options here:

Force users through a web proxy set to block remote desktop applications
Block the IP addresses of popular remote desktop applications. These protocols use https to connect, so you can't filter on port. You either have to make group with all the IPs, or filter on their DNS entries if your firewall supports it
Prevent users from being able to download and run the applets the sites use. That will prevent them from being able to use the sites


How to detect a virus in a network card? How can I know that a network card in a server was infected by a virus or not? Are there any methods to check it?

While it's theoretically possible to insert malicious code into flash memory on peripheral equipment like network cards, it's more likely to see the use of videocard GPU systems to do rainbow table cracks for special purpose hackware, etc.

Specialized programming is needed that would be nation-state level targeted attack fodder. Peripheral equipment malware would take special knowledge and techniques that would allow the device to operate normally without crashing while filtering traffic.

If a theoretical hack was ever done to a network card, the only way you would ever detect it would be by analysis of the traffic coming in and out of it. Your standard anti-malware wouldn't have a clue.

It's more likely that this kind of attack would be done against routers and printers. They already have CPUs with plenty of left over clock cycles and flash memory storage that will easily hold a few minor mods. Our local College had an HP that had a humorous "Insert Nickel to Print" message left by one of the Electronics Majors.


Using unique per-session gpg keys to store backups on cloud storage I'd like to encrypt my server's daily backups and send them to dropbox / google drive / etc., as a backup.

I've read of various approaches. Assuming symmetric encryption (passphrase rather than public/private keypair), people seem to: tar, compress, encrypt with a passphrase (using gpg), and upload the result to cloud storage.

Then I found this comment (edited for brevity):

  I wouldn't use the same passphrase over and over to encrypt your files. Instead, I'd generate a file containing a number of random bytes and use that as a key for my .tar.bz2.gpg file. I'd then encrypt this random file with my 100 character passphrase and upload it together with the backup file. (Basically, I'd create a session key with which to encrypt my data and use the 100 character string as a master key to decrypt the session keys). You can automate this, and it gives you forward secrecy in case one of your backup session keys is compromised and the ability to decrypt any specific backup without losing control over your master key.

So if I understand correctly, for every backup I must (via a bash script):

create the backup 2020-01-01.backup.tar.bzip2 (date is just an example)
generate a random passphrase, and save it as 2020-01-01.passphrase.txt
use 2020-01-01.passphrase.txt to encrypt 2020-01-01.backup.tar.bzip2 to get 2020-01-01.backup.tar.bzip2.gpg
encrypt 2020-01-01.passphrase.txt with my "master" passphrase (which I keep on my local box) to get 2020-01-01.passphrase.txt.gpg
upload 2020-01-01.backup.tar.bzip2.gpg and 2020-01-01.passphrase.txt.gpg to cloud storage

The above comment says this is more secure because if one backup/passphrase is compromised, the others are still safe as they use different passphrases.

But I'm a little confused. If the master passphrase is compromised ("hacked" / guessed / whatever) - all the backups are compromised. It seems like just another level of indirection.

The only way this makes sense is if the master passphrase is MUCH longer (more entropy) than each session passphrase - e.g. 100 characters vs 20 characters, respectively. But then why not just make every session passphrase 100 characters?

Is my understanding of this strategy correct, and can you detect any gotchas I should take into account?

But I'm a little confused. If the master passphrase is compromised ("hacked" / guessed / whatever) - all the backups are compromised. It seems like just another level of indirection.

It's not another indirection, it's another lock the attacker have to pick before entering the safe. It's like having lots of small safes, and another safe well hidden somewhere else, with each little safe's combination. The attacker don't know about every combination is unique unless he successfully opens one and tries the same combination on the others, and don't know where the master combination is stored.

The reason to have a symmetrical key for each backup and one strong asymmetric master key is that you will rarely use the private master key, so it can be very long, be stored offline and be well defended. Security is always a trade-off against usability, and in this case, you can dial all the way to security, like splitting the key in lots of segments and use Shamir's Secret Sharing to store it on various places.

The public key will be used every day, but it is not of much concern. You would not paste it on the home page of your site, but you don't have to be paranoid about it either.

Usually, password leaks are due to human error, not failures on the tech side. Having only one key protecting all your backups means you are one mistake away from compromising every single backup. Having multiple keys you can compartmentalize the data, and the errors can be more contained.

  Is my understanding of this strategy correct, and can you detect any gotchas I should take into account?

I believe your strategy is correct. The most important thing you must take into account is to keep the private key well protected, and never lose it. Leaking the private key means all backups can be compromised, losing it makes all backups irrecoverable.


Why does OWASP recommend "Disable Web Browser Cross-Tab Sessions" I have been looking through the OWASP session management cheat sheet and I don't understand the reasoning behind the suggestion to "Disable Web Browser Cross-Tab Sessions". How does using the same session id for multiple browser tabs present a security vulnerability?

I would guess that in principle it's because it's to prevent possibility of a Bad Person hijacking your session.

If such a person were to be tapping your session then would have your cookie (or less trivially whatever magic value in the pages is identifying your session) and then all they'd have to do is spoof your IP-address.

Of course if your session were encrypted this shouldn't be possible, but presumably this rule doesn't presume it to be the case, or rely upon it.

It's not something HTTP itself can deal with, but the rule itself notes that:

  Web applications can use JavaScript code once the user has logged in
  and a session has been established to force the user to
  re-authenticate

So you couldn't support users who don't wish to use JavaScript, or whose browser doesn't support it. Your session-tracking logic then, implemented in JavaScript lets say, retains session information local to the browser-tab session only. You need to ensure that this implementation also is portable across whatever browsers you wish to support.

I'd recommend using a well known implementation for this rather than rolling your own. I'd imagine most well known JavaScript frameworks support this.

There's more on what you might specifically need to do here: https://stackoverflow.com/questions/11008177/stop-people-having-my-website-loaded-on-multiple-tabs

Update:

There are another few scenarios that come to mind.

A ticket sales site might like to do something like this to prevent their customers "gaming" a queueing system by running multiple tabs. But this is a session management issue really, because the customer is effectively running multiple "queueing sessions" within their actual session.

It can also simplify site design if you don't need to worry about race conditions between different user activities thus forcing them to do "one thing at a time", though this is more of a UX than a security issue.

Finally, this rule could also frustrate the activities of scraping software, or bots (such as those that could be used on ticket sites again for instance). This would be an effective countermeasure against an attacker logging in through the browser to capture a session, and then continuing the session with the bot.


Are there any kinds of ID where it would be safe to email a photocopy of that ID? I am developing an online registration form for a discount program whose eligibility can be determined by examining a person's ID.  When a user submits the form, he or she is asked to upload a photocopy of the ID will be sent via email to the organization for verification.  I have steered the stakeholders away from allowing a photocopy of a drivers license for security concerns, but there are other types of ID I'm not sure about.  The examples I was given were:

A student ID
A student metro card (the organization is in New York)
An NYCid (I assume referring to this: https://www1.nyc.gov/site/idnyc/index.page)
A military ID
A medicare card
A Social Security benefit card
A WIC card
Any union ID

I did some research and I'm getting various answers about each type.  Is "don't email any id at all" just the best rule to follow?

"Safe" for whom? I'm seeing a significant risk for your organisation to accept any of those things.

Personal data is a "toxic asset", which means its liabilities are greater than its assets. If you accept those things, then you are responsible for those things for as long as you store them. There are many regulations that you would have to be mindful of, and if the data was leaked, your legal liabilities would be higher than normal.

None of those things is safe for the end user, either. Each one poses a significant ID theft risk. Maybe not the Metro card.

And then you are emailing these documents. Each email server in the chain from the sender to the recipient would get a copy of the ID. At least, if you decide to do this, provide a web-based upload facility instead of email.

As a privacy expert, I would strongly advise against any of these things.

If you need official ID verification, use a 3rd party service, like Yoti, or something. Else, design your service to not require an error-prone, easily-faked process such as a scan of paper documents.


Should Session-Timeout events be logged I am working on Audit logs for an ERP project and searching for all kind of events to be logged.

In this project, session, timeouts on inactivity. I was wondering if logout by session-timeout should be logged.

I was referring to OWASP - Which events to be logged and couldn't find a clear answer on whether a session timeout event should be captured in audit logs or any other log.

Is there any clear requirement / guideline for session-timeout events to be logged ?
(Logout by user is added in the logs)

(Also, since the implementation is timeout based and utilizing the TTL property of session_storage, it would require extra resource to implement the logging for session timeout. I am not sure if session-timeout events are worth the extra resources for its implementation. Please share your opinion / suggestion.)

Logging is based on the threats you perceive and also what you might find valuable during an actual security incident.

Another slightly different alternative would be to log any attempts to access a session that expired. Thus you're not logging when a session actually expired. Instead you're logging the moment a user or attacker makes a request against a session that already expired. This should be low resource for coding since you already have the session Id and you're already checking if the session is valid or not so just log in your code the moment you determine Its and invalid session.


Can use this security system on websites? I have created a password security system.
I wanted to get your reviews about it and its technical problems.

In this system, users create a dynamic password that will change every time they try to log in based on their unique formula they wrote when registered.

Example of password created: apple{{A+2}}{{B+C}}{{D*E}}green

When user wants to log in on the browser, the server sends 5 random one digit values like:

 1,2,3,4,5

corresponding to A,B,C,D,E respectively.

and now user has to enter his password like :

apple3520green

This protects the password from being exposed , as it can't be compromised because it will change every time.

I have created a demo version of this implementation on http://advpassword.com
And I love to have your comments about it on the website ( Good or Bad )

Don't forget AviD's Tenet of Usability:

  Security at the expense of usability comes at the expense of security.

This is what makes this scheme unusable, for any security properties it may have over any other form of password.  It would be simply inconceivable to expect for people, who have as many issues as we have with simple passwords, to try and cope with random new algorithmic password schemes that require not only remembering a password, but remembering an algorithm associated with the password, and plugging in a new set of variables every time you need to use the password, and calculating it correctly.  The entire idea is a disaster of complexity.

Ultimately, this is a (relatively) solved problem.  Multi-factor authentication is the solution.  It's secure above and beyond simple passwords, and far less novel and complex than what you propose.

There are very specific scenarios where this scheme might be useful, but common services are not one of those scenarios.