Windows 7 consent.exe attempting to access the internet Looking at Firewall logs, I see that consent.exe, which is responsible for the Windows 7 UAC UI, attempts to connect to the internet.  I have verified the file is a genuine executable provided by Microsoft.

Does anyone know why it attempts to connect to an external server, and if there is any reason to allow it?

In performing an internet search for this information, I could find only ambiguous answers, such as:
http://www.instant-registry-fixes.org/consent-exe-a-genuine-file-or-virus/

Update: I have noticed that it always attempts to access the internet when Windows 7 boots, even though no UAC prompts are being issued.

You asked 1) if consent.exe is a legitimate program, 2) if its use of the network is legit (why does it attempts to connect to an external server), and 3) if there is any reason to allow it.

Your questions (and some commentary) follow.  The short answer is that it is OK, and no, you don't want to block it:

Legit?  Kudos for checking the genuine M$ origins of the file on your system.
Assuming that the copy of consent.exe on your system is good, then what is it doing anyway?
Consent, is part of the user access control (UAC) system.  Among many other things, before it allows anything to run based on signatures & certificates, it wants to check to see if any certificates have been revoked.
To check the revocation information consent has to 'phone a friend'.  Consent does this for all of your certificates each time that it does not have current, trusted information.
Can you block it from network access? Well there are 2 reasons that you may not want to do this:

Going back to a really trusted root gives you a bit more safety.  It is of course your choice, but as for me and my machines, we will check the root.
For me, when I did not provide access to all of the Trusted Roots the UAC prompt took almost 30 seconds to come up.
This was a mystery to me, and might be to you. I was using self-signed machine-specific code-signing certificates rooted from my machines at work.  These certificates were being checked via a ROOT that was not accessible.   Unfortunately, the internal work network is usually behind a firewall.  This means that the revocation check has to timeout.

So in summary:

Yes
Yes
Yes

Happy hunting.

Ah, so what did I do?  I removed all of the offending certificates -- my UAC prompt now comes up faster than I can blink.


How to validate user input I am having a lot of trouble understanding where I as a developer can validate the data that my users send to me. Let's say for a simple example I have a web page where it has a simple form that contains three fields:

Name -> text field
email -> text field
Lunch Choice -> Dropdown field
  values:
    Burger
    Hotdog
    Pizza

Once the user submits the form their name and order is saved and they can pick up their lunch the next day.

If I am a vicious user and I got to this site and edit the html to say that the pizza value is actually salad and the value of the option is some other value.

Now when the form is submitted and saved, some bad data is going into the database.

Where can I stop this?

My first thought was to have some javascript validation, have an ajax call talk to the server to make sure the values requested are valid. This sounds like a great idea, except javascript runs on the client, not the server, so that is also susceptible to attack.

If I let the user submit the form and then handle the submit on the server and do the checking there, the user has already submitted the form so I would need to do some kind of redirect back to their form?

I'm sure I am not the first developer to have questions about input securities and I was wondering if there is a best practice for handling this type of problem.

Thanks in advance!

Is a basic question. You should validate EVERYTHING on your server side. The back-end is the right place to make validations. Of course javascript validations are useful too to drive standard users into the right values, but for hackers (or any advanced user) is very easy to trick.

It's suppossed you have a database on back-end and you know what kind of food is able to be assigned to each user. You should check if the received value is present on the valid recordset. If is ok you can go on with your workflow. If not, you can show an error and stop the proccess.

Another important problem you'll face is not only the logical bypassing. Beware of special chars and filter everything dangerours like single quotes, double quotes, dashes, semicolons, etc... or you'll face too a sql injection or a XSS (cross site scripting) attack. That is another story... but I mention it because is very important too.


Can Inverse TCP Flag Scan be run as a stealth scan? How exactly does the Inverse TCP flag scan run and can we run it as a stealth scan?

The Inverse TCP flag scan executes as follows.

Attackers send TCP probe packets with a TCP flag (FIN, URG, PSH) set, or with no flags.

When the port is open, the attacker doesn't get any response from the host, whereas when the port is closed, he or she receives the RST from the target host.

When Port is Open

 Attacker--------- (FIN/URG/PSH/NULL) ------------------ >  Victim
                       X < -------- No Response --------

When Port is Closed

Attacker--------- (FIN/URG/PSH/NULL) ------------------ >  Victim
      < -------------- RST / ACK ----------------------

Security mechanisms such as firewalls and IDS detect the SYN packets sent to the sensitive ports of the targeted hosts. But  the probe packets enabled with TCP flags can pass through filters undetected, depending on the security mechanisms installed. Inverted Technique is probing a target using a half-open SYN flag because the closed ports can only send the response back.

Advantages

Avoids many IDS and logging systems, highly stealthy

Disadvantages

Needs raw access to network sockets, thus requiring super-user
privileges
Mostly effective against hosts using a BSD-derived TCP/IP stack (not
effective against Microsoft Windows hosts, in particular)

Inverse TCP flag scanning is known as FIN, URG, PSH scanning based on the flag set in the probe packet. If there is no flag set, it is known as null scanning.


Additional check for request integrity I'm building a REST API resource server with JWT authorization for an Angular web app. I'm looking for a method to perform an additional check if the request body sent from the client application has not been modified by the attacker.
The communication between the server and the client is using SSL, but I need to make an additional check that the data sent in the POST request has not been modified by a man-in-the-middle attacker.
I think it should be solved by calculating the signature of the request on the client-side and then verifying it when the request goes to the server. Does anybody know how this can be done?

Before I answer this, I really need you to consider: what is your threat model here? Are you trying to be secure against a malicious user of the web app? Against somebody with the power to break TLS? Against a malicious browser extension? This is important, because the first and third are impossible and the second is almost certainly a waste of time. Is this just some best-effort-to-slow-them-down thing, like DRM, or are you expecting an actual security boundary here? Are you envisioning that, for some reason, the attacker can modify the request but not the response? If you're assuming the attacker has full control over the TLS tunnel - meaning they can inject malicious script into responses, as well as modify requests - this is flat-out impossible because there's nowhere you can hide a signing key that the attacker can't access and use to re-sign their modified message. For that matter, you also need to assume that the user has been able to previously communicate securely with the server for the purpose of key establishment; if that's not the case then the whole effort is also hopeless.

Signing the message body before sending is the right idea, but there are some problems you need to consider. Obviously each user needs their own key, tied to their account, so that the attacker can't re-sign the message with a different key. Additionally, the key needs to never be visible to the attacker, which means neither the key itself nor any value used to derive it can be transmitted in a request from the client.
Option:

Session-based symmetric: At login, server generates a random symmetric key (128+ bits from a CSPRNG) and sends it to the client. Server also stores this key locally, in a session variable (tied to that exact user session). Client caches this key in some local storage and never directly sends it over the wire. Client also initializes a counter. For all subsequent requests, client takes the message body and computes an HMAC (probably something like HMAC-SHA256) over the message + counter, using the key. This HMAC is sent in a header or some such, along with the current counter value. Server verifies that the counter value is greater than any previously seen this session (storing the updated counter in its session state) and then retrieves the symmetric key from session state, computes the HMAC itself, and ensures it matches.

Fast to compute and verify.
Transmits the key, but only once, and only server-to-client.
Cryptographically simple, relatively easy to implement correctly.
Requires a common function for all requests, so that the counter is always used and incremented correctly and requests don't arrive out of order.
Requires server state, which is generally contrary to the goal of using a JWT and does not scale well to a cluster or even just a large number of active sessions.

Stateless symmetric: As in #1, but the server keeps a secret symmetric key (shared across any cluster) and computes the session key by HMACing a string that the client will send unhashed with every request (could be the client's JWT, or even just part of it, as long as it includes the client identity and ideally some unpredictable value) with the secret key. Server still needs to send this session key to the client (and needs to do so every time it changes, if it does) but doesn't need to remember it locally. To avoid needing to store the counter value on the server, instead require that the client use a timestamp in the HMAC (and send it in plain text with the request), and the server makes sure that the timestamp is within some range.

Still pretty fast, though you now have to do two HMACs instead of one to verify each request (aside from any work that you have to do to verify the JWT, of course).
Slightly more complicated, but still reasonable.
Requires no additional per-user or per-session state on the server; suitable for clusters with only a little effort.
Introduces a single point of failure for all sessions, if the attacker can get access to the server's secret key then they can re-derive every victim's session key from their JWT.
Introduces the risk that the session key will rotate (when the JWT expires, as they are wont to do), which could invalidate legitimate requests. Can be mitigated by using some value that is still unique to the user and ideally to this particular session, and is sent by the client on every request, but does not change when the JWT is refreshed. This value could be part of the JWT or even just a random string chosen by the server and cached on the client during the session.
The use of timestamps rather than a counter or other proper nonce introduces a small opportunity for a replay attack, until the timestamp expires.
The use of timestamps requires that the server and client have well-synchronized clocks.

Persistent, wrapped asymmetric: At user account creation or password change/reset, the client creates an asymmetric key pair suitable for signing (such as RSA or ECDSA). The client transmits the public key to the server. The client also hashes the user's password client-side, twice, with different salts and/or algorithms. One digest is sent to the server as the "password" for authentication (will receive additional hashing server-side before authentication, just like a normal password). The other digest is never transmitted, but is used as a symmetric key to encrypt (wrap) the user's newly-generated private key. The wrapped private key is transmitted to the server for storage. At login, the client performs the same dual client-side hashing of the user's password. If the server authenticates the user, it sends back the wrapped private key, which the client decrypts using the never-transmitted digest, and then stores client-side for the duration of the session. The server also retrieves the user's public key from storage. At all points that are neither logging in nor creating/changing passwords, the client uses its private key (which the server has never seen in unwrapped form) to sign the request body, along with a timestamp or counter/nonce (as desired; see considerations above). The signature, along with its timestamp/nonce, is transmitted in request headers. The server verifies the validity of the timestamp/nonce, and then uses the user's public key to verify the signature.

Unlike the previous approaches, THIS WORKS EVEN IF THE ATTACKER CAN READ ALL SERVER-TO-CLIENT RESPONSES although it does still require that the attacker NOT interfere during account creations / password resets.
Unlike the previous approaches, THIS DOES NOT EXPOSE THE USER'S PASSWORD AT LOGIN TIME; an attacker who intercepts the login flow will not be able to impersonate the victim as the attacker (until the attacker brute-forces the password from the authentication hash) because the attacker won't be able to unwrap the private key and hence can't sign messages correctly.
Highly complicated and prone to cryptographic (or ordinary implementation) error.
Requires the server look up the user's public key on each request, though doesn't require storing any actual session state (assuming timestamps are used).
Requires additional asymmetric operations on both sending and receiving a request; could potentially be computationally expensive to perform a lot of these in rapid succession (for the server's sake, choose a primitive that is not too expensive to verify signatures of).
STILL BREAKS if the attacker can MODIFY RESPONSES (attacker will just inject their own script to steal the private key and/or modify and re-sign the request at the client immediately before sending).

As in #3, but use SRP (Secure Remote Password protocol) rather than the custom client-side hashing and key exchange, and use the computed key from SRP to sign (via HMAC; and heck, encrypt if you want to) the exchanges. Server and client both need to remember the SRP-derived key for the duration of the session, and never transmit it.

As with #3, is secure against an attacker fully breaching TLS on requests and able to monitor response plaintext.
As is normal for SRP, establishing the passwords (including handling resetting a forgotten one) can't be done within SRP and thus requires some other channel that the attacker can't be allowed to interfere with.
Requires storing server-side session state (the SRP derived key).
Can be used to provide an extra layer of encryption, not just integrity, to the channel (though you still need to be sure the attacker didn't ever inject malicious scripts at pre-login time or any other point where web content is transmitted in the clear).
Simpler to implement because you can use existing libraries for SRP, though still not trivial (there's probably a JS implementation of SRP usable in a browser out there already, but it's not built into the JS API library the way many primitives are).


Using hashed password as secret key for hmac to avoid exchange of secret between server and client I'm currently trying to improve our API to be more restful, therfore avoid any state on the server. I want to accomplish this with a hmac token, appended on every request.
The hmac will be made with the following data-part: host, request-method, request-uri, timestamp(to avoid replays) and in case of POST/PUT also the body of the request.
Any objection against this?

I'll send the hmac along with the username or maybe a hashed representation (public key) of the user to be able to have different secret keys for each user on the server.

Now I'm planning on the secret-key exchange between client (JavaScript) and server (PHP) and got the idea of just using something the server and the client already both know without exchanging it and it should still be different for every user.

So why not use the hashed password of the user as the secret key? The server has the hash of the password saved to the database next to the user in the usertable in anyway and the client can calculate the hash based on the input of the user and store it in a client session for later usage.

What are the concerns against using the hashed userpassword as a secret key?

It's not really possible just using the user's password as you can't securely store the passwords in such a way that the client can independantly derive the same key from the password. The reason being that you are required to salt a password while storing it.

The current accepted password hashing algorithms are:

bcrypt
scrypt
PBKDF2


SQL Injection Possibilities in my code This is an sql query for a registration page. I want to know what are the possible injection queries if I use the below code in my web app registration page.

    $stud_reg_query = "INSERT INTO `athletics`.`STUDENT`(`roll`, `name`, `batch`, `gender`, `phone`, `email`,`EVENT_1`,`EVENT_2`,`EVENT_3`)
    VALUES ('$v_roll', '$v_name', '$v_batch', '$v_gender',
        '$v_phone', '$v_email','$v_ev1','$v_ev2','$v_ev3')";
$stud_reg = mysqli_query($conn, $stud_reg_query);

These values are displayed after registration in a separate page.

Each and every place where a user-input variable is inserted makes you subject to SQL injection. You should either use prepared statements, PDO, or escape the variables properly before appending to the original query.

As an example based on your code:

$v_email = "', NULL, NULL, NULL) --";

If I can append something like this to your query, and the SQL specific characters are not escaped, your webapp is vulnerable as I just changed the way you wanted the query to work.


What Checkstyle or Findbugs rules detect common vulnerabilities? Looking for experience with both built in and custom checks.

I do not need references to commercial source code analysers.

To have a more complete set of rules, you could use the FindBugs plugin Find Security Bugs. It include 36 new detectors. Of course, the plugin generate some false positives, but you can always disable specific detectors.

Disclaimer : I'm the author of the tool mention


How severe are the interestingly disclosed AMD flaws? CTS disclosed several "flaws" in the AMD Ryzen architecture chips. These flaws are called Ryzenfall, Masterkey, Fallout and Chimera (https://amdflaws.com/). However several technology sites (for example Wired) and blogs raised questions as to the motives, release style and severity of the flaws. There also seems to be a very odd disclaimer on the CTS sites. So far it has been hard to find any data without a lot of hype. How severe are these flaws and what do I need to do to secure my systems?

Quotes from the rather detail-free whitepaper:

Exploiting MASTERKEY requires an attacker to be able to re-flash the BIOS with a specially crafted BIOS update.

Exploitable only if you've got the BIOS manufacturer's signing key (if they use one), have written a custom BIOS for the computer being targeted, and (generally) have physical access to the machine.

Exploitation [of RYZENFALL] requires that an attacker be able to run a program with local-machine elevated administrator privileges. Accessing the Secure Processor is done through a vendor supplied driver that is digitally signed.
Exploitation [of FALLOUT] requires that an attacker be able to run a program with local-machine elevated administrator privileges. Accessing the Secure Processor is done through a vendor supplied driver that is digitally signed.
Prerequisites for Exploitation [of CHIMERA]: A program running with local-machine elevated administrator privileges. Access to the device is provided
by a driver that is digitally signed by the vendor.

So, at a minimum, you already need full control of the computer and a third party's signing key to exploit these vulnerabilities.  Might be useful for a state-level actor trying to install an undetectable keylogger or the like, but the average person isn't at increased risk because of them.


What is safer to use (in general terms), online banking software using the mobile app or using a browser on a desktop OS? What is safer to use (in general terms), online banking software using the mobile app or using a browser on a desktop OS?

I suppose that a mobile app, provided by the bank on a mobile OS seems is harder to manipulate then a website in a browser on a desktop OS (more factors).

This is a very open ended question, as it depends on what bank, what OS, and potentially even what hardware.

Some banks are vigorous about the login process and password recovery, others put more value in convenience.

Some smartphone manufacturers are diligent about distributing security updates, but others are very careless and/or have spread themselves too thinly with too many models to maintain.

Some operating systems have a lot more malware "in the wild" and are more prone to user error, others are more locked down by default, and have more thorough checking within official software sources.

Some hardware was manufactured with vulnerabilities, such as with the rowhammer exploit that was discovered to work on smartphones, recently.

There's no binary answer; either could be insecure, depending on the context. It's best to avoid falling into a false sense of security by giving a one-size-fits-all answer. You need to carefully review the security of the routine you're using, and increase it where there are vulnerabilities.


Can I use the same password forever on my local machine Referring to Why do I need a strong password for my home computer and How often should I change my Mac password, am I to safely assume that:

Local passwords are, in fact, only for protecting against physical (ie. non-remote) access.
One doesn't need to change the password like, ever, as long as it hasn't been compromised (ie. shared with someone, used elsewhere, etc.)

I personally use a Mac with FileVault and no SSH service running. I use various Wi-Fi networks (both at home and away). If the answer depends on the OS, please elaborate on why.

PS! Should the strength of a local password be stronger, weaker or the same as an online one?

True, it only protects against physical access. But on portable corporate machines accessing corporate assets, it's a different ballgame as the local user authentication is probably also used to authenticate on the corporate domain when connected in some way to the corporate network. Let's say someone manages to read your username, domain and sees you typing your password connecting to a corporate laptop, they may not need physical access to that particular laptop to access the corporate network using the "stolen" credentials.
True. In fact, I would argue that encouraging users to change their local machine password too often would likely reduce password security as users tend to get tired to remember new passwords every 30/60/90 days. As a result, new passwords are very likely to be variations of previous ones, noted down, or simply weak.
Both local and online passwords should be made really strong, because although attack vectors may vary, ultimately you want both passwords to be resistant to brute forcing and dictionary attacks.


Android: Internal memory safe in case of loosing the phone? I'm using a Xiaomi Redmi 3 device with latest MIUI 8 Global Dev Rom (Android 6 based with weekly updates). I'm only using Fingerprint Unlock and my device is not fully encrypted.

I'm wondering how hard it is for an attacker in case my phone is lost to access the internal memory. The external SDcard can be easily removed but is it easy to access the internal one?

I have not opened up the Xiaomi Bootloader, hence the theft could not simply flash another Rom to get access to the device. Also no USB Debugging / Developers options enabled. So in case he connects the device to a USB port; IMO there should be no way to get access to the internal memory, right? (a friend of mine broke the display of his iphone and not even the Applstore could help him get access to his DCIM folder to copy his non-backupped images; hence I hope this kind of security is also provided by the latest Android OS).

The only way I could currently think of would be to open up the device, somehow solder the memory ASIC to remove it from the platine and get access. As Im not talking about super safety-relevant data stored on my internal memory, this scenario will not come true for a random theft and is not in my focus asking this question.

Thanks in advance

Reading unencrypted internal flash IC is a job that can be done for under $100. Last time I have checked, universal flash programmers were sold on e-bay for $30 to $300. If anything leads the thief to believe that your data is more valuable than your phone, this will be done.

If the thief is after your phone, they will have little incentive looking at your data. They will try to either unlock or reflash your phone to make it usable, whichever is easier. This may not be possible via external interfaces, but certanly doable if someone is willing to open the device: after all, those phones are flashed at the production line, so there is a way to do it.

Bottom line, you have to use encryption if you need to keep your data private. If that data is also valuable, you should use a more secure authentication method than a fingerprint.


Terminology for reduced brute-force attack? Many security algorithms today have such a large key length, that there's just no use in trying to brute-force a key. For example to find one AES-256 key you would have to try 2^255 keys on average.

My question is, if there's a special name for a brute-force attack where you would somehow know that a key "lies" in a specific range, which would reduce the amount of calculations so drastically that a brute-force attack suddenly becomes feasible.

An example about simple brute-force RSA-factorization might make it more clear:

We have a 2048-bit RSA key. Way too large to just try one number at a time to brute-force it.

But we assume now that I have a special algorithm that doesn't directly return one of the factors, but can tell us that one of the factors lies in a certain range k (plus / minus 1,000,000,000). Then we would only have to try the possibilities from k - 1,000,000,000 up to k + 1,000,000,000 and this is probably quite possible to brute-force.

No matter if such algorithms exist or not, is there a special name for this specific attack (reducing the possible key range to make a brute-force attack feasible)?

"Password Spray" is used to describe an attack in which a limited number of likely or easily guessed passwords are attempted against a number of accounts.  It's usually used for on-line (e.g., try to log in) rather than off-line (e.g., get copies of hashes) attacks.  To quote TheWindowsClub:

  Password Spray Attack is quite the opposite of Brute Force Attack. In
  Brute Force attacks, hackers choose a vulnerable ID and enter
  passwords one after another hoping some password might let them in.
  Basically, Brute Force is many passwords applied to just one ID.


Decryption on AES when the same key and IV are used Let's say that I have three messages being encrypted by AES-128 with the same key and IV every time. Is it possible to decrypt the key being used? And more importantly, is it possible to decrypt the plaint text of those messages?

What happens here depends on the mode of operation. As a basic rule, knowledge of the messages will not allow you to recompute the key itself, but it may give you enough information to (instantly) crack any other message encrypted with the same key and IV.

With CTR mode, a key-dependent stream is produced by encrypted the successive values of a counter, and the counter starts at the value given in the IV. The actual data encryption is performed by XORing this stream with the data to encrypt. If the same key and IV are used, then you get the same stream, so you are in the conditions of the (in)famous two-times pad. Without knowing the key, you can still compute the XOR of any two messages, which is often enough to crack them, by exploiting their internal structure. Once one of the messages is known, this reveals the key-dependent stream (up to the message length) and this allows for immediate decryption of any other message (up to that length) encrypted with the same key+IV.

OFB mode is in a similar situation: it produces a key-dependent pseudo-random stream. So it can be broken with the same level of ease as CTR.

With CBC mode, things are a bit harder for the attacker. If the messages start with the same bytes, then you will be able to see it. After the first distinct bytes, decryption becomes much harder. This is because, in effect, each block in CBC encryption is used as IV for the remainder of the message, and encryption of data with a block cipher tends to produce properly distributed IV for CBC. Generically, CBC requires a uniformly random IV which is unpredictable by the attacker, but in your situation you envision a passive-only attacker, and against such an adversary, an IV selected by encrypted a known data block is good enough for CBC, as long as the IV source is not reused; this is what you obtain with your messages, beginning with the first block at which the messages differ.

CFB mode is somewhere in between. If two messages begin with the same n bytes, then the encrypted messages will begin with the same n bytes too; then, for the remainder of the block containing the n+1-th byte, this is two-times pad. For the subsequent bytes, the streams have forked and attacker's power stops.

Important: though the paragraphs above seem to indicate that CBC or CFB would be safe for key+IV reuse as long as you include a counter in the header of each message, remember that this is for a passive attacker only. In many (most) scenarios, the attacker can be also embed a bit of data of his own in the messages which are to be encrypted, and/or alter the encrypted bytes and see what happens when they are decrypted. For these scenarios, which are realistic (many recent attacks again SSL are all about that), IV reuse, and even predictable IV selection (with CBC), are hopelessly weak. Do not reuse IV.

The only situation where a fixed IV is fine is when keys are never reused, i.e. each key is used for a single message only. This is, in practice, harder to obtain than a new per-message IV, because keys must be kept confidential: it is already challenging to have a key which is known by both the sender and the receiver, but by nobody else. At least, IV do not have this confidentiality requirement, and thus can be transmitted along with the message itself.


What reputable site should I download Putty from? I recently did a Bing search for Putty and can only guess at which distribution is "trusted", contains no malware, or sleuthing code.

If you needed to download Putty for a high security Windows installation, where would you get the Binaries from?  Would you compile from source?

The official site is www.chiark.greenend.org.uk/~sgtatham/putty, you can find the download in the download section. If you want to play it safe, you can verify the signature of the download.

In my opinion compiling it from source is as safe as downloading the binary and checking the signature (make sure to also verify the key itself with at least one trusted signer). Unless you review the source code (including all needed libraries) there is no point in spending the added effort of compiling it yourself since both parts, the source code and the binaries, are signed with the same key.

The only advantage you gain by compiling it yourself is the opportunity to review the code so as to mitigate the risk that the authors of PuTTY could have add some backdoors or malware to it.  But again, you would have to thoroughly review the code and all needed libraries to actually gain that benefit.


What's the safest password type? I've used Dashline (password manager) with random generated passwords, but I forgot the master password and there is no way to get it back. I read that password managers and random generated passwords aren't that safe as I thought they are. So what type of a password should I have that is the safest?

Losing a password manager's master password usually isn't too catastrophic, just a huge hassle. You can still reset those lost passwords so long as you have your email account and any other relevant form of authentication.

For human-memorable passwords (your password manager's master password, stuff you have to type into anywhere that password managers aren't available such as disk encryption and login, accounts you want to ensure you retain access to like email), Diceware-style passphrases are still the best that I'm aware of. You want more than four words unless you're pulling from an extremely large corpus - the 7776 words of the official Diceware site is a bit short to be safe at only four words long (51.7 bits of entropy, assuming the attacker knows you use that method) - but even just four Diceware words will be much stronger than almost any human-generated password/passphrase. A stronger passphrase can be made using more words (even going just to 5 will be sufficient to resist modern hardware assuming a slow hash is used, but going to 6 or more will be very expensive to break even with a fast hash). A larger word list (corpus) will also help, though less effectively (doubling the number of words in the passphrase doubles the entropy; doubling the number of words in the corpus adds only one bit of entropy per word).

For anything that your password manager will autofill for you, let it generate a nice strong random password. It'll be stronger than a Diceware-style passphrase of reasonable length; there are more than 100 printable characters on a standard US keyboard, and just 16 random characters from a set of 100 is 10^32 possibilities (106.3 bits of entropy) but there's no need to stop at 16. It'll be a pain if you ever have to type it manually, but even somebody shoulder-surfing you isn't likely to successfully memorize it like they could with a Diceware passphrase.


What local resources are used when bruteforcing a remote service? What pc resources are used when bruteforcing ?
I mean bruteforcing something online, not hashes.
Do you need a good amount a RAM and a good CPU or it's just about the internet speed ?

Well, unless the site you are bruteforcing is potato, it will have rate limits locking you out after a few attempts. So the biggest resource will be the number of IP addresses you can get, to circumvent the lockout. (assuming IP is used to block)

If there is no limit, then it will likely be internet speed. Though under some extremely rare circumstances, it may be something else.


Secure Register - Login Portal Im trying to create a secure portal for parents to view their sons or daughters information.

I would need to have a register page. Im having trouble with hashing and salting the password.

Then I need help with decoding the hashed and salt password for them to login in.

You wouldn't decode the salt/hash pair, you would instead run the salt/hash process again every time they enter their password on your site and compare the output to the stored salt/hash pair you have.

This is to avoid ever storing plain text passwords and if you're ever breached, it makes it exponentially harder to gain usable passwords from the information stolen.

The process you choose to salt/hash is up to you. There are a lot of functions ready to do this for you, depending on the language chosen.


Same-origin policy for file: URLs in Android browser? When you load a file:// URL in an Android WebView or in the Android browser, what does it treat as the origin?  What can the Javascript on that page access?  Can it access other files in the same directory?  Other files elsewhere on the device?

Background: I know that, in desktop browsers, the same-origin policy for file:// URLs has varied over time and from browser to browser.  For instance, some browsers used to treat all file:// URLs as being within the same origin, so any one page could script all pages with the file protocol.  Today, I think some desktop browsers use the directory as the origin (e.g., file://a/b/c.html is in the same origin as file://a/b/d.html and they can script each other, but they are in a different origin from file://a/y/z.html and cannot script it), while I think other browsers use the entire path as the origin (i.e., file://a/b/c.html is in a different origin from file://a/b/d.html and cannot script it or any other file URL).  What's the situation for the Android browser / the renderer used by Android WebViews?

When you execute a .html file using the file:// URI  that script is run in the "file" zone. Which means that you can read files on the local file system using an XHR. (This is subject to change,  and is also easy to verify)

As with most "standards"  it depends on what browser you are using. If you are using Firefox on any system,  including android, JavaScript can only access files in its own directory and all sub directories.  But this is a recent change FireFox's SOP (May 1st 2012).

WebKit is a different story. If you have a script running in the file:// zone then you can read any file on the local file system,  so long as the browser is running as a user with the necessary file permissions (/etc/passwd should always be world readable).

It should be noted that most browsers will not allow you to redirect from a web zone (http, https) to the file zone. Once upon a time you could do this,  but it was a feature that was ripe for abuse.  So if there was a DOM based XSS vulnerability in a local .html file it would be difficult exploit (I am not aware of a method of doing this, and this method would likely be a vulnerability).  Although this theoretical vulnerability maybe "cross-zone scripting"  which would allow an attacker to exfiltrate files off of the local file system,  it would be very difficult to exploit due to redirection restrictions.


Can hackers access wireless traffic between me and my ISP? The computer and the router are located inches apart in my study.

An Ethernet cable connects the router to the roof antenna.

The antenna talks to the ISP, 5 km distant.

I know from experience a hacker can access the router with ease.

The question is, can the hacker access traffic anywhere along the route between the antenna and the ISP?

Short Answer Yes.

Long Answer
It really depends on the technology being used to talk to the ISP if it's 802.11a/b/g/n it's super easy and won't be expensive and doesn't require specialized RF knowledge. If it's some other type of RF the attacker would have to have a special antenna, software and some extra knowledge but it's not impossible by any means.
If they sniff your traffic they will only see unencrypted traffic unless they were to setup a MITM scenario. If that were the case any time you would visit a site using SSL (https) you will get a big red browser warning.

Options

Get your ISP to run some cable to you (not likely)
Go to another ISP (meh)
Use a VPN service. This will encrypt all of your traffic up to the VPN providers server. Just google "VPN Providers" you can usually find one that less than $50 for an entire year.

Other things to worry about

If you're using a wireless router monitor your connections daily make sure no one has broken in. Even with WPA2 it's not impossible to hack and most newer routers have WPS for "Convenience" and that it is, for attackers too because there's a big backdoor built into it.
Attacks from the internet. Keep your router updated, check your logs and connections regularly.


OpenSSL x509: Is there an order in subjectName fields? Is there an order to respect in subjectName field when creating a x509 certificate with OpenSSL command? In other words, what are all possibilities of displaying subjectName of x509 certificate in OpenSSL?

In the subjectDN field of a certificate, there is the certificate owner distinguished name, which is nominally ordered. Its definition really is a SEQUENCE of SET of name elements, so it is an ordered sequence of unordered sets of elements. It is quite rare to have several name elements in the same set (I have seen it done to put the Common Name, First Name and Last Name together, as three elements with the same level).

The ordering of elements in a distinguished name relates to why such names were defined in the first place: as an indexing path into the Directory. The Directory can be envisioned as a world-wide structure that references everything; its main problem is that it never actually existed. Shrunk, diluted, local versions of the Directory do exist: they are called LDAP servers (or "Active Directory" in the Windows world). For some usages, you may want to mind the order of fields in the subjectDN if the software that uses the certificate will really connect to some LDAP server and use the subjectDN to get more data about the certificate owner. This is a rare case. In fact, even in Windows + Active Directory (which is very keen on using LDAP), when a certificate is mapped to an account, the account is usually located with the UPN, which is a Microsoft-specific type of name located not in the subjectDN, but in a Subject Alt Name extension; the subjectDN is then really used only for display purposes (the Common Name element of the subjectDN is shown to the human user).

When using certificates for SSL servers, the order of name elements in a distinguished name does not bear any specific meaning. The issuerDN of a certificate must be identical to the subjectDN of the certificate of the CA that issued it (and in particular must have the elements in the same order), but beyond that there is no order to follow. The SSL client (Web browser) will (at most) extract the Common Name element, regardless of where it appears in the sequence, and disregard all other elements.

To see the order of name elements in a subjectDN, you can use openssl asn1parse as indicated by @StackzOfZtuff in his answer. Making the issue more confused is RFC 4514 (that replaces the older RFC 2253): this is the standard representation of a DN into a string, to be used in LDAP context. For some reason, the string representation was defined to list the name elements in reverse order:

   Otherwise, the output consists of the string encodings of each
   RelativeDistinguishedName in the RDNSequence (according to Section
   2.2), starting with the last element of the sequence and moving
   backwards toward the first.

Nevertheless, when using openssl x509 -text -noout to display the contents of a certificate, OpenSSL will show the subjectDN and issuerDN as strings in a format which is very close to RFC 4514, except that it follows the order of appearance of the name elements in the encoded certificate, not the "reverse order" mandated by RFC 4514.

"Names" may also appear in the Subject Alternative Names extension. That extension is defined to contain a SEQUENCE of GeneralName, i.e. it is technically ordered. However, nothing in X.509 attaches any semantic to the order of names; in fact, this extension is defined to use a SEQUENCE OF and not a SET OF mostly because encoding a SET OF with DER rules is more expensive (you have to sort the names lexicographically). The order in which the various names in a SAN extension appears has no influence whatsoever on the validity of a certificate, and should not change anything in application behaviour.

Of course, any given software may fail to do things correctly. In a SSL context, it is common for several names of type dNSName to appear in a SAN extension: the browser will scan all the names until it either finds a name that matches the expected server name (as it appears in the URL), or runs out of names, whichever comes first; this behaviour, implicitly, does not ultimately depends on the order of names.


The following signatures were invalid: EXPKEYSIG 6494C6D6997C215E Google Inc despite correct signing key Ubuntu (focal 20.04)

Using Google webdesigner apt repository in /etc/apt/sources.list.d/google-webdesigner.list:

deb [arch=amd64] https://dl.google.com/linux/webdesigner/deb/ stable main

leads to:

# wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
OK
# apt-key list | grep -C 2 "Google Inc"
Warning: apt-key output should not be parsed (stdout is not a terminal)
pub   rsa4096 2016-04-12 [SC]
      EB4C 1BFD 4F04 2F6D DDCC  EC91 7721 F63B D38B 4796
uid           [ unknown] Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
sub   rsa4096 2019-07-22 [S] [expires: 2022-07-21]

# gpg --list-keys | grep -C 2 "Google Inc"
pub   rsa4096 2016-04-12 [SC]
      EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796
uid           [ unknown] Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>

# apt update
...
Err:14 https://dl.google.com/linux/webdesigner/deb stable Release.gpg
  The following signatures were invalid: EXPKEYSIG 6494C6D6997C215E Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
...
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://dl.google.com/linux/webdesigner/deb stable Release: The following signatures were invalid: EXPKEYSIG 6494C6D6997C215E Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
...

I have been seeing this error only for a few days.
Does anyone know what is suddenly going on?

"This is the protection you are getting from these checks. You don't want to update your software right now while something is messed up on Google's end. Wait until they fix it. Don't try to override by reinstalling keys until some official word comes out that a new key is the solution."

Original link - Source


TLS1.0 to TLS1.2 (Browser vs Registry) Question

How does TLS protocol differ on registry and browser level?

Context

Many companies are migrating from protocol TLS1.0 (disabling this) to TLS1.2 (enabling it). I'm not sure how this differs on the registry level, and on browser level.

Before my registry disabled TLS1.0 and enabled TLS1.2, my browser already showed TLS1.2 enabled via How’s My SSL. My machine did not accept connections to hardened Windows applications on TLS1.2 until I made registry changes though (enable TLS1.2 and SchUseStrongCrypto):

Reference

https://www.entrust.com/moving-tls-1-2/

The TLS protocol itself has nothing to do with your browser and/or registry.  It is a documented standard that can be implemented by anybody.  What you're looking at are some registry keys to enable or disable various protocol versions for applications using SChannel, the TLS implementation in Windows.   As Yorick mentioned in a comment, SChannel implements the various TLS protocol versions, but they're not all enabled by default.   Originally TLS v1.2 wasn't enabled for compatibility purposes due to the number of sites that suffered from version intolerance bugs, (it is enabled by default now) and in the past SSL v2 and SSK v3 were enabled by default because there were many servers that didn't support anything better.  (And these are now disabled by default.)

Incidentally, you generally don't need to get into the registry editor to change these values.  There's available on the "Advanced" tab of the "Internet Options" dialog in Internet Explorer.


Why does Google Safe Browsing keep detecting malware on my website? We provide a freemium service to upload large files and download them later on.

Using ClamAV, we scan every file for viruses after it is uploaded and before it can be downloaded. The file is deleted if a virus was found and a HTTP 404 is returned.

Still Google Safe Browsing keeps detecting malware on our site:

  ...the last time suspicious content was found on this site was on 2015-08-30...

(Which was yesterday as of writing).

While my logs show that viruses/malware are detected from time-to-time, I also see that these files are downloaded zero times and are being deleted automatically as expected.

I've read through "What tools does the Google safe browsing service rely on?" and the linked resources.

Still I'm not sure why I cannot get my site to be "Google Safe Browsing clean". Maybe:

the used virus scanner is not good enough and lets some viruses pass?
I'm doing fundamental mistakes due to my limited knowledge of security architecture?

My question:

Do you have any idea what to do in order to get a clean Google Safe Browsing track?

(If this is possible at all, even Dropbox or Google itself are listed there)

Update 1:

As Schroeder says, there may be other content on our site, not the files. We also do provide Windows and Mac clients. These files are all scaned and detected as virus-free.

I'm confused…

Update 2: (2015-09-24)

I've installed "Sophos Server Security" on the server in question and see lots and lots of malicious uploads being deleted by Sophos now.

So the ClamAV detection rate seems to be a lot lower than the one of Sophos.

Hopefully with the help of this new anti-virus solution my server never ever again serves as a virus source.

There are several scenarii you may think about. I am not going to be exhaustive, but I will mention briefly the milestones that can come to my mind:

Your website is effectively clean

Let us suppose your website is clean as you say. So why Google still blacklists it?

There may be several reasons for this situation:

Reason #1

Google effectively did not find anything wrong with your website by now, but it still does not trust you because it can not understand your intentions as you may be someone who wants to attack your website's visitors, so Google needs time to be sure that you are not playing a game over its head by just pretending you are not attacking any body for the moment but as soon as Google whitelists you then you come back to your nefarious habit(s) (This is said, I am not accusing you to attack people through your website, I just say why Google still does not trust you even if your website is innocuous for the moment)

1.1. Solution for Reason #1:

You need to scan more times, and in separate days using Google Webmaster Tools until Google trusts that your change (clean-up) is permanent.
Reason #2

Google believes that you have cleaned-up your website from malicious content but you did not really finish that task as you did not request from it (Google) a malware review.

2.1. Solution for Reason #2:

After you cleaned your website, request a review from Google.
Reason #3

You cleaned infected webpages from their malicious content and you submitted a review request from Google that still does not trust you.

3.1.Solution for Reason #3:

You need to delete those pages, not only their malicious content. Yes, it is a radical solution but the only one that will make Google trust you in this particular case because Google will think you have intention to use those pages to attack your clients and that is why you are keeping them there.

Your website is not as innocuous as you might think

Your domain has served as a bridge to deliver malware

Google says that Over the past 90 days, zeta-uploader.com did not appear to function as an intermediary for the infection of any sites.  But given what discussed above, you are forced not to trust this statement.

1.1. Why Google did not detect my domain as being a malicious intermediary one?

Several reasons are there to explain why Google failed to detect that:

attackers obfuscate links in your webpages to domains that attack using drive-by download attacks (which is reported by Google concerning your website).
an other reason is that Google detected the obfuscated link but can not follow and determine the malicious chain of intermediary domains
Google found the obfuscated link to the malicious domain but the attacker replaces such links frequently to new ones that may be are difficult for Google to detect so it can not be sure what decision to take

1.2. What to do then?

I do not have much ideas for this situation apart from searching for such links manually yourself or, if it is possible, to hash your webpages and develop files/directories modification notifications.
What is the situation about my real case now?

It is not that good. Under the section What happened when Google visited this site?, Google says you have:
 Malicious software includes 96 trojan(s), 14 exploit(s), 5 backdoor(s). and that 3 page(s) resulted in malicious software being downloaded and installed without user consent (drive-by download attacks).

Only backdoors can explain what really happened to your website.

What's the solution then?

This is too broad to answer because you are the owner of the website, you know its security architecture, so you are the only one who can assess that and take decisions depending on different scenarii/discoveries you may encounter. You may start by checking this: Google Webmasters help for hacked sites and see which method to use to discover, remove and mitigate backdoors on your domain... do not forget to review your scripts related to file upload ...

Good luck.

P.S.

The question you linked to, I asked it a year ago when I was developing a software for the sake of a web vulnerability scanner to detect drive-by download attacks and malicious contents on websites.


Is hashing the concatenation of my password and account type secure? Concept
The goal of a password manager is to reduce the number of passwords which one must memorize down to one, and then have all other passwords be encrypted under that master password. My solution aims to solve the same process without the use of any data storage.
Idea
First, generate a secure password. Then, conconcatenate the name of the account to the end of it and hash the result, possibly in the chain-style outlined in this answer. The final result would be my password for that account.
Example
Using an example password "GreenPlanetAboutStudentCaughtGoodbye" and my "StackExchange" account, I would hash "GreenPlanetAboutStudentCaughtGoodbyeStackExchange", and use the result as my password.
Security
The purpose of the hashing is to ensure that even if a website were to store my password in plaintext, only that password would be compromised. Assuming that accounts allow for all 40 characters of a SHA-256, the entropy of the passwords would be max(256, entropy of initial password).
Advantages

Requires no encryption
Requires no data storage
Passwords can only be lost if the master password is forgotten
Can be used anywhere

Disadvantages

Dependent on websites allowing for unlimited password length (though one could trim the hash for websites which require it)
Assumes all special character reqs will be met by the random password (highly likely but still a chance they won't)

Question
Is my idea sound (reasonably secure)? Is there any critical flaw which I am missing?

The idea is, broadly, secure. In fact, it's been implemented several times before. There are a few problems that any such approach (and a few more than an approach as simple as this) will run into, though. In no particular order:

Multiple accounts per site. The scheme, as described, provides no way to differentiate between accounts for the same site. You'd need to stick a username in there somewhere.
Password rotations (mandatory, or due to compromise). You can't change the generated password without changing the master password. While mandatory password rotations are becoming less common, they do still exist in some places.
Password complexity rules. Sites tend to have a wide-ranging (and often very bad) list of complexity rules, some of which are mutually incompatible (e.g. one site insists on "special characters", another forbids anything non-alphanumeric). This tool has no way to meet constraints like that.

Speaking of which, how exactly do you plan to encode the hash digest? 256 bits is 32 bytes is 44 (if you keep the terminating =) base64 characters or 64 hex characters... None of these are the 40 characters you mention (are you thinking of SHA1 - a 160-bit digest - in hex encoding?)

Master password can't be rotated. With normal password managers, you can change the master password (if, for example, you fear somebody may have keylogged it), and while it's a good idea to then also change all the passwords it was protecting you probably have some time to do so. With this scheme, you have to update the passwords on all your sites if you want to change the master password.
Lacks brute-forcing protection. While the master password you chose is long enough to probably be safe (assuming you use something of similar entropy), most people are going to pick more predictable passwords than that. A single round of any fast hash (including all members of the SHA family) salted with nothing but a predictable string provides very little protection against brute-forcing, these days; a decent graphics card can compute billions of hashes per second (and specialized hardware can do much more than that) trying to find the original password. You need, at a minimum, to use a few thousand rounds of hashing to slow down the search; you could also use one of the newer algorithms (like scrypt or argon2) that is specifically designed for password hashing.
Passwords are hard to transcribe. If you need to enter a password into anything that doesn't let you copy-paste it, you're in for a lot of very careful typing.
No way to look up stored accounts. While this can be a plus in the event of your system getting compromised, it's more often a minus. If you don't know whether you have an account for some service, or don't know what the "salt" for the account is (is it "bankofamerica", "BankOfAmerica", "Bank of America", "BOA", "boa", "BofA", ...?) you might spend a while trying wrong passwords without knowing for sure.
No way to store associated secrets. For example, a password manager lets you store things like multi-factor backup codes or "secret question" answers; this system doesn't support the first at all and the second only clumsily (by basically using the question itself as a site/username/salt/whatever).
No support for changing cryptographic primitives or work factors. If SHA-256 gets broken and everybody is told to move to the SHA3 family, you have to change all your passwords. If in two years you want to double the number of iterations you do to account for Moore's Law, you have to change all your passwords.

Anyhow, not saying such a scheme is actually insecure (though you might want to harden the hashing function a bit, at a minimum) but it does have a lot of limitations and potential pitfalls.


I need to transfer user's private key (RSA) to my App. Is file sharing a good solution? I've asked a similar question here earlier iOS: Is it ok to store a RSA private key (use to decrypt text) in your application document directory?

However, the person recommend me to use keychain access. This will not work for me because after further research only mac users can use keychains in the first place. Which limits the people who can do this.

I was wondering if it is secure to use Apple's file sharing https://support.apple.com/en-us/HT201301 to allow the user to use his/her private key with the iOS App? According to the documents regarding file sharing only my App should be able to access the private key because it is store in the document directory. There is some text that needs to be decrypted in my App.

I presume that you're having the user generate an RSA keypair. If that's so, you simply need to stash it somewhere that, ideally, no other applications are permitted to look.

As you said, apps can't access other apps' document directories. However, the Apple File System Programming Guide advises you to put data the user shouldn't access in the Library directory (most likely as an Application Support file). It doesn't specifically address what to do with sensitive data, though, so you may want to dig a little deeper into these documents.

Of course, this won't stop users from getting at the private key if they really want to. You can probably use file permissions to keep the private key from being exposed by a casual search, though.

I'm not sure what file sharing would do for you here - unless you're having the server generate the keypair, perhaps?

Also, are you sure that you can't use Keychain? This Apple support document says that you can set it up with Mavericks 10.9 or iOS 7.0.3

If that's the case, then it's the best option available.


Are there sensors/devices to be used for reading magnetic bits of hard disk I would like to ask about the availability of any sensor or device that can be used to read magnetic bits inside hard disks? I tried to google that but I did not see any useful thing till now. I think data recovery companies should be using something like that device.

Already there...

Spin stand microscopy of hard disk data mentions some varying technologies.
Single drive wipe protects data, research finds links to papers about how randomly overwriting data just once can make it unrecoverable.
Magnetic force microscope on Wikipedia. Include images taken from hard drives.


Does Linux “Dirty COW” Exploit allow for escalation outside a virtual machine? Vulnerability CVE–2016–5195 deals with privilege escalation in Linux systems.

In a virtual environment with hypervisor KVM and QEMU, can a virtual machine get access to it's host? If not, what is the protective layer here?

You are looking at two different vulnerabilities.

Dirty Cow is a privilege escalation in the operating system. So, if  your VM is vulnerable, that means it's possible to get root privileges in the VM's operating system, not in the host system.

In order to be possible to access the host, you need a vulnerability in KVM or QEMU that allows you to escape from the VM sandbox.


How to check who uploaded malware My website has been hacked or attempted to be hack. I can see malicious uploaded files on my website server is there any way I can reveal the IP address of who has uploaded the file?

Also my website is on WordPress and there are lots of changes and malicious code so is there any way i can see who has modified those files? I checked Awstats, webalizer but I cannot get much information.

Two possibilities, with a few Ifs.

Possibility #1:

Take a look at the created timestamps on the malicious files (assuming they're separate files); or last-modified timestamps (if malware was injected into one of your files).

If you have access to your web server access logs (depending on your hosting plan and service provider, the location, name and method of getting them would be different); and

If you have those logs for the time-range when those files were created/modified; then

Search through those logs for PUT or POST messages targeting those files.

Since you already mentioned webalyzer - you probably did some form this already. Hopefully the narrowing down that I mentioned might help; or use of another tool (even a manual search through the logs) might identify what is being missed.

Possibility #2:

Some wordpress security plugins (not all) do create separate logs that you can dig into. I know that Sucuri's service does this; and probably WordFence too. I have a product that does this (ActiFend) too, though the logs are stored on our servers.

If you were using any such plugin -or- any other remote logging solution, either you or any security analyst would be able to dig through them to get some idea of the IP address (that is not the same as who did it, but it is still something).

For the future: Being prepared is the key. If you accept that you will be hacked at some time or the other, then you'd setup both remote monitoring and recovery.


How can Cloudflare determine the owner of a website? Assume that we have two websites with two different owners. Both of them set their domain name server to john.ns.cloudflare.com and joly.ns.cloudflare.com. The first owner set both domains in his account in CloudFlare and set server IP to his server IP, How can CloudFlare determine that this person is not the owner of the second domain?

Isn't this kind of a threat of our domain being hijacked by someone else?

I asked this question from cloudflare help center and I got this answer

  When a user is signing up to Cloudflare they are provided with 2 of
  our DNS servers to switch their nameservers to from whatever their
  current value is. We have more nameservers than john and joly. The act
  of changing the nameservers to those specified for the user account
  signing up a domain to the values during the setup process
  demonstrates control of the domain.


Do I have to validate Saml2 InResponseTo? I'm implementing a SAML2 Service provider that will be running on a public facing web site. The sign in functionality is publicly available, so anyone can get hold of a AuthnRequest from my site.

When I do receive a response from the Idp, do I have to validate the InResponseTo field to make sure that the response is to a AuthnRequest I've issued or can I ignore it?

I don't understand how it would add any extra security when I'm already validating the signature of the response and have a replay protection by only allowing each assertion id to be used once within the validity time of the assertion (as specified by the condition).

Yes, according to the SAML spec this must be validated.

I'm not 100% sure of the reason or this. But just thinking out loud. With the contraint on time and sigature, you would still be able to do a replay of the message within the validity time.


MS-SQL Monitoring/Auditing of PHI for HIPAA We're currently looking for a solution (hardware or software-based) that can monitor and audit all PHI viewing activity per new HIPAA rules. We use MS-SQL for our production database. We have the following requirements:

Can track inserts/updates/deletes/views of PHI
Works for both Database Users and Application Users
Captures changes made over the network and directly in
the database (privileged users)
Works on multiple servers

There are some other items that would be nice to have (low-impact to implement, great reporting, alerting for suspicious behaviour), but are not requirements.

Has anybody implemented a solution that accomplishes something similar to this, or has worked with a vendor that offers something like this?

SQL Server itself provides a number of compliance tools that you can take advantage of to secure and audit your database and data.   There's a Compliance page on the SQL Server site and Microsoft has written a Compliance whitepaper that will get you started.

Additionally, there are huge number of third-party auditing packages available for SQL Server.   A search for a set of terms like SQL Server auditing HIPAA compliance should net you plenty of options to choose from, such as Blackbird Auditor, and OmniAudit.   The products obviously have different feature sets, spo you'll need to determine which ones best meet your specific criteria.


What is the weakest scheme in common use for password hashing? Essentially, what's the next step up from plaintext password storage?  I suspect the answer is going to be MD5, but I'm not familiar with a broad enough variety of examples to be sure.

The reason that I ask is that I'm trying to determine an appropriate strength to shoot for when generating passphrases.  I know that a dedicated cracking rig like this one can run MD5 hashes at around 300 billion per second, so I'm thinking a minimum of about 67 bits of entropy (~10 years to crack.)

Is it reasonable to treat MD5 as the lower limit for password hashing?

EDIT:  To clarify, I'm not trying to store passwords, and if I were I certainly wouldn't be using MD5.  I'm just trying to figure out what's the worst-case scenario I'm likely to run into as a user, so that I can set a reasonable minimum complexity for my passphrases.  Obviously the true worst case would be plaintext password storage, but in that case no amount of complexity will save me.

I'm pulling from a dictionary of 15 thousand words, which gives my passphrases an entropy of ~14 bits per word.  So a 5-word passphrase should get me up to about 70 bits of entropy, which should be enough to defend against most attacks even if the password is stored via MD5.

My question essentially boils down to "Is there some other commonly-used hashing algorithm, that's even faster than MD5, that I should be aware of?"  If there is, then I need to reconsider my passphrase strength.

Depending on your definition of "common," DES with passwords truncated to 8 characters (for which rainbow tables exist).


Which encryption technique should be used for cloud computing data transfer? I want to setup my application for cloud computing for Software as a Service.
There is going to be a lot of data transfer between my server and client, to and fro.
The technique I have envisaged is:

Even the smallest communication must happen through file transfer.
The file must be created in binary at the source whose file format is understood only by my application.
The binary file is then encrypted by AES 256 encryption which requires another file for decrypting instead of a string.
The generated file is transmitted via SFTP.
The client and server applications will communicate with each other using some non-standard port like say 7238 (random) instead of the standard 80.

I am looking forward to critical suggestions to my technique as I have little experience in networking applications and encryption.
Note: The key file used for encryption is already present at both the server and the client.

EDIT: As asked by Steffen here is what I want to protect:
1. Protect the server from getting hacked
2. In case the server is hacked the data stored on the server should be encrypted such that it is useless to the hackers
3. Transfer data to and fro the server and client without leaking it to an eavesdropping hacker

The first step in securing anything should be to evaluate what you need to secure and where somebody might attack you (attack surface). I don't know what you have to protect, but since you are doing your computing in the cloud you should not only ask yourself how to communicate with your cloud application, but how the application itself is secured, that is how the server is protected, who owns it, which laws apply... .

As for your idea of communication: it looks like you combine different techniques you heard about in the hope that it will be kind of secure, but you don't really understand what you are doing (otherwise you would not ask). Please don't try to reinvent security, it usually goes wrong. Use instead established technologies like TLS or SSH and understand how they work, what they offer, and what limits they have.

As for your added information of what you want to protect:

  Protect the server from getting hacked

You should be aware, that with most cloud solutions you don't have your own dedicated hardware, but share the hardware with others and only get a kind of container or virtual machine on the hardware for you. If somebody successfully attacks the host running these containers you can forget the security inside the containers.

Also, most systems are vulnerable once an attacker gets access to the hardware. So you have to put a lot of trust in the people running the infrastructure.

  In case the server is hacked the data stored on the server should be encrypted such that it is useless to the hackers.

This will not fully work. Because you have to work on your data while they are not encrypted, you have to have the necessary decryption facilities inside your cloud application. A competent attacker with full access to your machine has access to your application and can analyze it and extract the decryption part and reuse it.

  Transfer data to and fro the server and client without leaking it to an eavesdropping hacker.

I would recommend to use established technologies like TLS or SSH for this, but even these can fail if not used the correct way.

At the end it boils down how valuable your data are. Professional attackers will not put too much effort in hacking a system which has nothing valuable to protect, but will put lots of effort when really valuable data (which means money) are involved.

If it is just a play project I would not care too much with security, i.e. only secure the server so that it cannot be misused. But, if the data are really valuable you might better keep the attack surface small and not trust too much people. In this case I would not do anything in the cloud.


Is using JSON really enough to fix PHP object insertion? So I was just reading up on the OWASP site about PHP Object Injection. According to their site, the suggested fix is to not use serialze and unserialize but to use
json_encode and json_decode.

However, after doing a few tests in a limited amount of time I have found that this isn't the case at all. For example (working Codepad example):

<?php
function e($method, $args) {
    return $method($args);
}

var_dump(call_user_func_array("e", array((string)array_shift(json_decode("[\"system\"]")), "ls" )));

?>

So, my questions are:

Would you agree with me that this is not the case, and there should be more of a suggested fix rather than just using json_* functions?
Am I actually correct in assuming what I have done is correct?

Unlike unserialize, if you execute json_decode alone it will not be able to instantiate any different variable types besides simple ones (e.g. arrays, string, int, float, etc), so it is fairly safe to run it with user input data.

The problem in your code is with the e function. If the parameters you pass to it come from an untrusted source such as user input, some attacker could just pass the name of a potentially dangerous function that exists in your code, so e would execute it and it could harm your application. You should never let this happen.


Is it recommended to send an authentication request to the Resource Owner (by the Authorization Server) if it already has an active session? In OAuth 2.0 Authorization Code Flow (Grant Type), is it recommended (or is it maybe even a best practice) to send an authentication request (e.g. a login-request form) to the Resource Owner (by the Authorization Server), even if the Resource Owner has already an active session on the Authorization Server, when obtaining an Authorization Code for the first time for a certain Client?

In other words, is it recommended to kill/destroy a currently active session first, if there's one? Or is it not important at all?

Actually you won't know from the client side whether the resource owner has an active web session on the authorization server or not, and it's not the client's matter.

That's however up to the authorization to decide what to do, for instance:

Authenticate if the resource owner is not logged in
Grant immediate access without logging in again if the resource owner has already logged in, or reauthenticate him (for instance if he logged in more than 7 days ago) by killing or updating the session. Reauthentication can also consist in requiring a second factor (SMS OTP...)
Make the resource owner authorize some scopes he has not approved yet
Or even ask him to approve new CGUs
Etc

In a nutshell, it's the authorization server's matter to decide what to do (i.e. applying an authentication and authorization policy), not the client's.

If the resource owner is already logged in, has approved the requested scope, etc. then the server will redirect to the client directly with an authorization code. In this case a blank page will shortly appear, the URL will change swiftly (redirects) before the resource owner is redirected to the client. This is how SSO (Single Sign-On) works.


It is save to send sensitive data through URL parameters inside one service with SSL? I was thinking about that topic, and I am a little bit confused. I am using SSL. There is some story:

User click on the button "Give me X"
Service 1 receive it, get userName from the session and send GET to Service 2 passing userName as URL parameter
Service 2 receives it, sends the response with some data.
Service 1 receive it and send that data back to the user.

Service 1 and 2 are in this same machine, uses the same web container (Tomcat for example).
I found that when we send a request directly from the user (he can see the destination URL) is not safe, but I did not found anything about "forwarding". It is safe?

And I know that there are a lot of better solutions, but this question is purely hypothetical ;)

When you are connected with HTTPS to a website, only the domain will be visible to others when they lets say use Wireshark, not the URL parameters. However, there are more risks involved.

There is no significant difference to POST and GET requests when it comes down to altering the values for example, any user can easily edit a POST request just as easily as altering the URL. You can also see POST packages being send over the network when not using HTTPS to connect.

However, GET requests can be cached and will remain in the browser history. They can also be bookmarked and these are main risks involved. Best practice is to not use GET requests for sensitive data.


Double encryption with different keys I have a software development kit which packages the data for the finished program in a series of LZMA packages. I want to ensure that my software is the only program that can read the packages, even though they're compressed in an open-source format. I also want to be able to encrypt it, if the user wants to, further so that only the finished program can read it and not the original SDK. If I simply run it through an encryption method twice, will that work?

To put it in pseudo-code:

encrypt_file(filename, "SDK key")
user_key = get_input()
encrypt_file(filename, user_key)

The compressed packages contain common file formats like PNG images, MP3 audio files, etc. Will this method work properly, such that I can just decode it by doing something like this:

user_key = getkey() //Retrieve it from some configuration setting
decrypt_file(filename, user_key)
decrypt_file(filename, "SDK key")

If you want to ensure that only people that have your software are able to decrypt it and if only the people with the finished program need to be able to decrypt it then you should be ok since only people with those particular versions of the programs have the key.

It can not be emphasized enough, however, that anyone who possesses an installation of the software also possesses a copy of the key.  If the software can decrypt it, so can the person who runs the hardware the software is running on.  To try to make it so the user can not access it goes in to the realm of DRM and is really a hopeless cause unless you control the hardware.

Note, for efficiency gains, you could accomplish the same thing by encrypting with a unique key every time and then only encrypting the key twice.  This would greatly enhance the speed of encryption and decryption as a much smaller amount of data (the key) has to be encrypted/decrypted twice.  It also simplified changing one of the keys if a key becomes compromised since only the file keys need to be re-encrypted.


Authenticate a browser that has no user input (a kiosk) from another browser I'm building a dashboard for a client. It starts up in Chrome kiosk mode and begins displaying all activity for the day's transactions continously on a screen placed high on the wall. They asked for no user input since its going to be placed high on the wall for all the office to see.

It's an Angular UI that is served up from a Node.js server running Express.js.
That same server serves up an ionic version when hit by a mobile browser.
Neat stuff.

How can I authenticate the dashboard from the mobile site?

I'm thinking  the answer is something like WhatsApp web: Have the kiosk mode generate a QR code containg identifying data (IP, and a random hash) to be read from the mobile app. The mobile app can then scan the QR, and fill in username and password to send to the server.

Tell the server:  "I'm authenticating with these credentials, once you verify them, give access to  this {{ip}} running this {{browser}} and sending this {{hash}}."

I could find anything on two screen authentification. Whats the "good-idea" scenario here?

Sounds like you need to authenticate the device, rather than a user.  Also sounds like you have complete control over what is installed on the kiosk.

I would approach this problem using client certificates.  You would simply need to install a client cert on the kiosk (in the machine store, if it's Windows) and configure the web server to map the client certificate to a user identity.  You should not have to write any code to do any of this.


What is the best way for OWASP Zap to handle Unique Fields and API Sequences? First Situation: I proxy through some requests to zap and want to perform an active scan on them. Zap active scan is working on one property at a time, and this particular request requires some of the properties to be unique per request.

For example, a username can only be used once on registration, what pattern in zap would be best to tell active scan to change this property for every scan request?

Second Situation: This is similar to the first, but somewhat different. I have APIs that must be done in a sequence of steps. For example Step1, Step2, Step3, To perform the request for Step3, Step1 and Step2 must be completed. To achieve an optimal active scan on Step 3, for every active scan request, Step 1 and Step 2 would have to be performed before each request. What would be the best way to achieve this?

For situation one, create your own variant or HttpSender script.

https://github.com/zaproxy/community-scripts/tree/master/variant
https://github.com/zaproxy/community-scripts/tree/master/httpsender

For situation two, use the Sequence addon:
https://www.zaproxy.org/docs/desktop/addons/sequence-scanner/


Is it possible to hack an Android App or an Android device without being root? Simple question, as the title said.

I wondering if in an ideal world where rooting Android devices is not feasible mobile pen testing would be still possible or not.

Most of the sensitive folders will be inaccessible, right?

Yes.

Much of android malware applications simply abuse the api and claim to do one thing (eg an innocent game) but then do malicious activities (subscribe to premium sms, without root).

Any application that makes use of WebViews and allow for javascript execution open themselves up to standard javascript attacks(XSS). In fact recently a vulnerability was disclosed in the old browser application somewhat related to this. This was also without root.

Man in the middle attacks can be done simply by connecting to an insecure wifi hotspot, without root(from the victim's perspective).

Applications that don't authenticate with their back end APIs and servers can be subject to a number of sniffing/spoofing related attacks, without root.

So yes, root is not needed in all malicious attacks on android.


PCI Compliance question from a merchant I'm a new business that conducts online auctions for estate sales. When searching for software to use, I had no idea about PCI Compliance. My merchant account told me it was easy. It would be if the developer of the software had created a hosted form from my site to my payment gateway.

Because they didn't, I was required to have an AVS scan which failed. The software developer (who is different than the company that owns the software) told me PCI Compliance was baloney and that he has an SSL certificate so everything is encrypted and fine. He said he has only heard of PCI compliance a few times after building 700 websites and no one has been able to tell him what to change to be compliant. The owners of the software also claimed to have never heard of PCI compliance as well - they use the software and so do about 6-7 other independent businesses who have never had their merchant accounts ask about PCI Compliance (supposedly). I have ended my relationship with this company.

I am now in the process of trying out software from a different company that both owns the software and hires the developers. They claim to have a PCI Compliant environment, but they also don't use a hosted form - they use APIs to send over the info to the gateway, which likely means I will need to scan every 90 days. I'm not concerned about inconvenience, what does concern me is the safety and security of my customers and my liability.

It seems I am completely on the hook for PCI Compliance, including the fines and costs to replace cards, etc., but the developers/software companies have no skin in the game and have nothing to lose and no incentive to change to a hosted form to make PCI Compliance reasonable for merchants who don't want to or can't afford to create their own software. Is this normal? Can someone tell me why PCI Compliance is on the merchant only? I'm ready to shut down my business because it seems I am the only one holding the bag when it comes to compliance, yet I have no control over the software except for my choice to use it. I won't sleep at night unless I know I am doing the best I can to keep my customer's data as secure as possible. Can anyone provide insight or advice here? Or is this specific to my particular industry?

First, anyone who says "PCI compliance is baloney" is incompetent; you absolutely did the right thing by walking away from them.  Also note that PCI liability means you are on the hook not only for fines and card replacements, but all the fraud that was committed with card data stolen from your environment.  If the thieves buy a fleet of Ferraris, you are pretty much all done.  (There are other nuances to PCI liability, but web sales are pretty much guaranteed to be the least secure option, and will always shoulder more of the blame.)

Regarding auction software, consider looking for software that performs the functions you wish to offer, but does not perform the payment processing at all.  There are many players in the payment processing game; because Security Stack Exchange policy forbids product recommendations, we can't offer you a specific list.  There are many reputable big companies that take money over the web; you should have no trouble finding one.

A good way to find a payment company is to observe how they work.  Next time you're shopping on line, look to see if the payment company takes you to their branded web site for payment processing, then returns you to the store's site after your payment is approved.  That's the kind of payment company you should be looking to hire; it keeps all the PCI risk out of your hands.

Once you've seen how the various players in the payment space operate, you'll know what to look for and who to ask for in your auction software shopping.  Some may prefer one payment gateway over another, or offer only one option; that might be OK if you don't mind their choice of providers.  If the auction software company doesn't already offer such integration built in to their off-the-rack package, ask when they plan to offer it, not if.  Let them know you're only going to buy a package that offers you complete isolation from the payment environment.


Is it okay to reveal database's table names? I'm developing web application that uses database. I have to do some operations which needs database table names and db table schema. Will it be secure if I send this kind of information to client side (JavaScript via JSON) or should I keep those information on server side of my application?

Think about it this way

On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables table_2231 and your columns column_4231 (in which case I hate you), it's not gonna be difficult to guess your tables names anyway. If it's a news website, it's very likely you'll have a table called articles, or if you have some subscription service you'll have tables subscribers or users, and so on. Also, if your server is compromised, an attacker will figure out the table names almost immediately.

On the other hand, if there's a way around it, there's no need to disclose it. If your security is taken care of, a layer of obscurity wouldn't hurt in that case. In fact, a layer of obscurity on top of good security measures is often a good thing.

However, I'm afraid you're trying to do something like this
SELECT * FROM $UNTRUSTED_INPUT WHERE blah = 1
In that case, absolutely not. Don't do it.


Is the OAuth2 authentication code long enough to be secure? I have recently started working with the OAuth2 authentication flow. In using it, I see that in the authcode flow, the client allows the AuthServer to authenticate a user, and then returns an authentication code to the client, which the client will then exchange for a token.

The authentication code can be small: as little as 10 Hex digits. Is this really secure?
If a malicious client were able to steal legitimate client credentials, couldn't it do an impersonation attack by simply brute-force trying many authentication codes until it found one that worked?  Is this a weakness in the Oauth2 authcode flow?

Or is the length of the auth code an implementation detail left up to the authentication server?

Or is the length of the auth code an implementation detail left up to the authentication server?

Yes, the auth code is an implementation detail left up to the authentication server, but the OAuth 2 RFC has several design requirements - most notably:

Short code lifetime.
Code is usable once. Attempting to use it more than once revokes tokens tied to that code.

The "usable once" feature  means that even if an attacker can obtain/guess the code, any resubmissions to the auth server would (if possible) revoke tokens associated with that code. This is both good and bad. Good because it limits the attacker's window of opportunity. Bad because it could be used as a denial of service attack.

  The authentication code can be small: as little as 10 Hex digits. Is this really secure?

Yes. To mitigate against brute force attacks, code generation entropy needs to account for frequency of calls to the token endpoint (rate limiter can help) during its lifetime. For example, if we go with your 10 hex digits, code lifetime of 30 seconds, and attacker can submit 1000 guesses per second: probability of guessing is in the order of 1 in 270 million - you can further improve on this by picking a better character set than hex (16) such as base 64, and reduce the code's lifetime.


What are the good resources for learning Metasploit? I'm a newbie (Script kiddie) and I want to learn more about Metasploit. Not for fun, but to understand what exploits are, how they are used, and deployed. I've heard a lot about the Metasploit framework being good. I've even started reading the Offensive Security with Metasploit tutorials but I'm finding it somewhat hard to follow, as they've introduced a lot of new jargon. Also, I'm more used to coding stuff and I learn more by interacting. So, I'd like to do more like a "Hello World" sort of thing. However I didn't find any such resources. Can anyone provide me with any resources/links?

The thing is that metasploit infact is a framework, so a collection of exploits. The beautiful thing about a framework is that you don't need to understand what's happening behind the scenes.

I think that if you want to learn more about exploits and how they work, you pick yourself up some basic books like The Shellcoder's Handbook. If you want a more hands-on experience, it's better to start with easy exploiting challenges. Check out http://smashthestack.org/. They have different challenges that start really easy and steadily increase in complexity. You can then apply what you read in the previous named book. If you find yourself in a pickle, there should be ample information on the net.


Can Beehive detect a Snowden-like actor? In a seminar, one of the Authors of Beehive: Large-Scale Log Analysis for Detecting Suspicious Activity in Enterprise Networks said that this system can prevent actions like Snowden did.

From their articles' conclusions;

  Beehive improves on signature-based approaches to detecting security incidents. Instead, it flags suspected security incidents in hosts based on behavioral analysis. In our evaluation, Beehive detected malware infections and policy violations that went otherwise unnoticed by existing, state-of-the-art security tools and personal.

Can Beehive or a similar system prevent Snowden type action?

A backup operator will have the permission and behavioral markers of someone that moves lots of data around. Like any sysadmin where there's no dedicated backup operator in place.

Snowden was a sysadmin. He would knew all the protection protocols in place. He could just impersonate anyone, from any area, download things, impersonate the next one, and keep doing that.

If it's common knowledge that there's no bulletproof protection against a dedicated attacker, imagine a trusted internal dedicated attacker with sysadmin privileges.


Is there an alternative to using hashing to identify malware? I'm reading a sans paper on IOCs (indicators of compromise) in malware forensics and I came across this interesting obstacle:

  polymorphic and metamorphic codes (Paxson, 2011) result in multiple
  hash identities for the same class of malware

Now I understand the existence of IOCs and the frameworks (such as OpenIOC) purpose is to account for this flaw in using hashing as a way of identification. But I'm trying to dig in a little deeper into the way we use hashing, and perhaps create a solution. Unless there's already a solution in which case that'd be the answer to this question

Is there an alternative to using hashing to identify malware?

My idea is to create a way to hash something that expresses the level of difference between the two, maybe call this a "measured hash," where the first, middle, or last portion of hash of length x, shows the same values for binaries with the same values. Maybe, by definition, what I'm describing is no longer a hash but it'd still be a program or function that takes a binary and outputs a fixed length representation of that binary for identification purposes. Then if only one small element of the binary is different, we'd be looking at a hash that is very similar to the hash of the original.

Using sha1 hash as an example:
CA422BBF6E52040FF0580F7C209F399897020A7A

Is the result of this sentence:

  I'm stealing all your files using this binary but then I'll recompile another binary after adding or subtracting a few blocks of code

Now if I change the last three words of this sentence I get:
F5BB055C7F7E76275C6F0528D2ACD6F288CE7496

Which is no surprise for anyone who knows hashing 101. My proposal is to use a mechanism that gets me something like this for the before
CA422BBF6E52040FF0580F7C209F399897020A7A and this for the after:
CA422BBF6E52040FF0580F7C209F399897029B10 because, after all, only three words were deleted and replaced by a single word.

What I'm NOT looking for in an answer, is a list of artifacts or frameworks that are already being used to identify malware. What I would like to know is if such a tool already exists or if my idea is preposterous and wouldn't be of value to forensic investigators looking to share the intelligence of their research.

It depends for what you need to use hash-based signatures, but if we look in clamav signatures there are some options:

Hash-based signatures

To create MD5 signature you can use sigtool:

sigtool --md5 test.exe > test.hdb

You can also go with SHA1 and SHA256 signatures:

HashString:FileSize:MalwareName

Another options is Hash signatures with unknown size:

HashString:*:MalwareName:73

  Is there an alternative to using hashing to identify malware?

And then you have body-based signatures.

  ClamAV stores all body-based signatures in a hexadecimal format. In
  this section by a hex-signature we mean a fragment of malware’s body
  converted into a hexadecimal string which can be additionally extended
  using various wildcards.

Simple rule format can be used in this way:

MalwareName=HexSignature

You can also check YARA tool for creating body-based signatures.


How do attackers find the database technology used by a web application? These days there are several database technologies are available for data storage purpose.

While performing injection attacks, how do attackers actually identify the database used by a website?

If it is possible by any queries or commands through any application entry points, can someone

explain to me the instructions to identify some leading databases like MySQL and Oracle.

There are three common ways to deal with the variety of databases out there:

Many web applications are tied to a specific database backend, rather than being able to use a variety of backends.  For example, if someone's using MediaWiki, you know they're using either MySQL or MariaDB.
An attacker can attempt to generate an error condition, then look at the resulting error message for clues as to what database is in use.  This is one reason why error messages displayed to the end user should be as generic as possible.
An attacker can simply try everything.  There aren't that many common database backends in use, and making a dozen attack attempts isn't much harder than making one.


SMS verification, is it secure? In my web app (everything works with HTTPS), I send the user an SMS with a unique 5-digit code to a cellphone number he provides. I then ask the user to enter in the browser the code he received. Apart from the pure luck of guessing the 5 digits, is it 100% secure or is there a way to temper with this method?

Thanks.

I'm going to say no. While SMS is a generally accepted 2nd factor, there have been a number of cases where an attacker has used social engineering to break into a user's carrier account and pick up the verification code and use it. So to answer your question, is it 100% secure aside from guessing, no.

EDIT: To add to this information, even NIST is removing SMS as a valid 2nd factor from their standards for security.