What can be done with MySQL password Let's say there's a simple website hosted on the web, based on Flask + MySQL. The website's functionality is secure and does not allow arbitrary queries to be run against the database.

However, let's say someone gains unauthorized access to the username and password of the MySQL database (i.e. those used in the database URI).

Will this information actually allow them to do anything?

The website's functionality is secure and does not allow arbitrary queries to be run against the database.
However, let's say someone gains unauthorized access to the username and password of the MySQL database (i.e. those used in the database URI).

Not sure if this is what you're implying, but it's not enough that the website's functionality has to be secure - the whole server running the MySQL database has to be secure as well. Your website can be as watertight as it likes, but, to take the extreme case, if the backend MySQL database is running on a publically accessible IP, and listening to requests globally, that username and password will then allow you to connect to it and run all the arbitrary queries you like.
Bypassing the above, other aspects such as password reusability, and assuming everything is "completely" secured and locked down, then yes, those credentials aren't of any specific use. Like pretty much every strategy in this domain, keeping them secret is to add a layer of security should vulnerabilities ever be found that would make those credentials useful.
In practice, locking those credentials down should be pretty easy. So if an attacker has got their hands on them in the first place, the implication is that your setup is definitely not secure, and there's likely a whole host of other vulnerabilities yet to be unearthed.


Publicly available Botnet Traffic dataset Is there any publicly data set on botnet traffic for machine learning purposes. i.e traffic set for both bad and good bots

One malware that I know is available and used for building botnets is kaiten.c


ASP.NET vulnerability CVE-2008-5100 (assembly signing bypass): is there a fix? The short version of this question is:  Is there a fix or mitigation for
the ASP.NET vulnerability

CVE-2008-5100, which allows attackers to bypass assembly digital signature checking?

I'll give some background.  I apologize in advance for the length; this
seems to be a complex subject.

We ran a security scanner against our Windows 2008R2 website running our
ASP.NET application, and the scanner claimed we were vulnerable to
CVE-2008-5100.  As stated on mitre.org and many other websites, this flaw,
first reported in 2008, consists of:

    The strong name (SN) implementation in Microsoft .NET Framework 2.0.50727
    relies on the digital signature Public Key Token embedded in the pathname of
    a DLL file instead of the digital signature of this file itself, which makes
    it easier for attackers to bypass Global Assembly Cache (GAC) and Code
    Access Security (CAS) protection mechanisms, aka MSRC ticket MSRC8566gs.

This seems to be an embarrassing design flaw in the implementation of the
.NET Framework, allowing an attacker who has access to the target system's
filesystem to substitute a malicious DLL that will inappropriately be validated
as the victim's original DLL.

This vulnerability has
a CVSS score of 10.0, making it the equivalent of the worst possible
vulnerability ever encountered.

The security scanning software advised:  "Update the version of ASP.NET".
However, in my extensive Googling of this topic, there's no evidence that any
other version of ASP.NET is less vulnerable.  In fact, given how serious
this flaw supposedly is, it's surprising that none of the websites tracking this
flaw has been updated since Jan 2009.  The only relatively recent mention
of a flaw like this that I could find is in

Ian Picknell's blog, in which he describes a very similar unfixed flaw in
the .NET Framework 3.5 SP1 (as of Feb 2010).  Also somewhat alarming is that
fact that a security vendor just added this flaw to their scanner in Jan 2013.

In the interests of brevity, I will avoid a long discussion of the meanings of ASP.NET versions.  However, it appears that the scanner is
keying off the HTTP header "X-AspNet-Version: 2.0.50727".  Our application
emits this header because it was compiled with build flags targeting the .NET
Framework 3.0.  Indeed, the application reports this version of ASP.NET
even when it's run on Windows Server 2012.  If we recompile the app with a
target of the .NET Framework 4, we get the header "X-AspNet-Version: 4.0.30319".
We could probably get the scanner to stop complaining by using this compiled
version, but is that really changing the way that .NET checks assemblies at
runtime?  I am skeptical, but I cannot find any evidence one way or the
other.

I am not so concerned about the application actually being exploited, since
it requires write access to system directories.  I am concerned, as is my
management, about following best practices.

Thanks.

As far as I understand, this CVE is a dud. The strong name is basically a signature on the DLL, and the public key is identified by the "public key token", which is a SHA-1 hash of the key truncated to 64 bits. The core functionality of the "strong name" is to avoid clashes when several developers, who do not know each other, publish different DLL with the same name.

Strong names are also supposed to support a code integrity framework: a given application will reference a DLL by name, version and public key token; matching DLL will be found in the Global Assembly Cache. An evil attacker could try to load into the GAC a malicious DLL with the same name as a genuine DLL, hoping for another application (launched by another user) to load his DLL instead of the correct one. To do that, since the application contains the "public key token", the attacker will have to sign his Evil DLL with a key which matches the public key token -- and the public key token being a cryptographic hash, he cannot.

The CVE-2008-5100 is mostly about somebody noticing that signatures on DLL are actually verified when the DLL is installed in the GAC, not when it is loaded from the GAC. This makes sense: the GAC is protected from arbitrary alterations by the operating system. Thus, if the DLL was good on entry, it is still good afterwards. Or, more accurately, to modify a DLL which has been installed into the GAC, you need extensive administrative rights which make all of this moot: if you have that power, then you already own the machine in all possible ways. This explains the deafening silence of the Web about this CVE: it is a non-issue. It is like claiming that a lock which can be opened from the inside of a house is a security vulnerability, because a burglar who is already in the house could then open the door, and let... burglars come in ? See, when I use an analogy without the veil of technical jargon, the whole things becomes ridiculous.

So the report from the scanner is not appropriate. Your problem is to find the right way to shut it up. My recommendation would be to not use a "security scanner" which makes such stupid reports.

Now if we look at the details, there is something "suboptimal" in this "Strong Name" business; namely, the hash is truncated to 64 bits. This means that resistance to preimages is 264, which is high but still technologically reachable (an effort of that magnitude has been done publicly at least once)(apparently, a second effort of that kind has begun in several universities, to solve discrete log in a 128-bit elliptic curve -- to be concluded within an estimated ten years). An attacker could try to generate a public key which matches the public key token used for a specific DLL; if he succeeds, then he can make a fake DLL that will be accepted by applications, and for this he would only need "normal" access to the GAC (still not a worry if no potential attacker can open a normal user session on your machines).

Producing 264 RSA key pairs is expensive (not as much as you would believe because the attacker can make somewhat invalid keys, but still expensive) so I doubt this attack would be very practical, but the security margin is rather low.


SQL Injection explain this query ' 1=1 GROUP BY CONCAT_WS ('~',version(), FLOOR(rand(0)*2)) having min(0)

1>> My first question is what is CONCAT function is being used for in this query

2>> And Why do we use having min(0) in here.

Well, let's dissect it:

CONCAT_WS - Concatenate with separator.
version() - Returns the version of MySQL.
FLOOR(rand(0)*2) - Emits the following sequence of numbers: 0, 1, 1, 0, 1, ...
having min(0) - By itself, this is illegal, as the HAVING clause requires a condition. This, and the fact that there's no ; -- on the end, implies that the injection is expecting a condition at the end.

So, this concatenates the version string and a sequence of numbers across a group. The sequence of numbers for the group clause is derived from FLOOR(rand(0)*2).

The thing about GROUP is that it requires unique group keys. Since version() will return the same value each time, concatenating that and the output of FLOOR(rand(0)*2) three times will result in two different numbers (0, 1) then a second instance of 1, which causes an error (duplicate entry for group key), which is displayed back to the user. That error looks something like this:

  Duplicate entry '5.6.24-1~1' for key 'group_key'

This causes the version number to be leaked back in the response as part of an error-based SQL injection attack. This can then be expanded to perform other attacks.

As for why the attacker chose FLOOR(rand(0)*2), it's a dead-simple expression which is reliable (the rand() function is a PRNG which takes a seed parameter; the same seed produces the same sequence always) and satisfies the requirement of having a duplicate output relatively quickly. You could pick a value other than 0 and it would still work.


Keyless entry security systems and HIPAA implications We are upgrading our office to have badged security doors.  What I would particularly like to know is if Keyless Entry systems exist or are of decent quality.  By this I mean, I would like the doors to behave like the new keyless entry cars (you get close enough to the car with the key fob in your pocket and it unlocks).

I've found plenty of door badges that use fobs, but they all need to be within 10cm to register... I was looking for more like 1 foot. So not just a badged door, but one in which I don't even need to swipe

So my questions:

Do these systems exist?
Are they reliable?
Would they satisfy HIPAA regulations**?
Would they offer an API that would let us tie them in with Active Directory or some other central management.

(Also, as a development shop, if there is a "rough around the edges" product, I am more than amiable to writing a custom solution against an API or SDK)

** On the HIPAA note: We are a software consultancy, so we as an organization are not required to be fully HIPAA compliant (as the physical security aspects of HIPAA go) but we have several clients who are, so we merely need to "make a good case" to a HIPAA clients that our machines and the code on them are only being protected by more than a deadbolt on the front door.

Physically, it isn't difficult to make them read at a greater distance - get a decent antenna and power level and you can make it work. Some people locators in offices do this - not for access control, but for logging as you pass through doorways.

There is a very good reason why this is not done for access control - it presents a couple of considerable security risks:

With close proximity devices You require the person to be at the door scanner for it to register, so the card holder is the one entering. With a longer distance, someone else could when the card holder is nearby.
At close range, or contact, the signal strength is very low, which reduces the risk of an attacker picking up identifying information for reuse themselves**

**Had a play with some kit ADT were demoing on Thursday - a proximity cloner for RFID access cards. Hidden in your sleeve it could take 2 seconds to clone an access card in your target's pocket, and then can retransmit it to the door scanner!


Where and how to store admin account credentials for enterprise systems? To my understanding, password-protected spreadsheets are not best practice for storing admin creds, whether it's a company of 5 people or a company of 50,000 people. In such a case, what are some best practices for storing admin account credentials?
My two cents: An obvious answer might be encrypt the data and store it in a db. My response to that is say there's a data breach, the db is compromised, maybe the nefarious user(s) grab a copy of your db, deletes the db, and now your admin creds are all gone and you cannot access any systems because you don't know the admin credentials. Maybe storing it n the db is a good move to help ensure the data is encrypted and in one centralized location, but you're still vulnerable if an attack is successful.
There's two-factor authentication and store the data with a third-party but does it make sense to store company sensitive admin credentials with a third-party?
So, I go back to password-protected files or spreadsheets. If only a limited number of people within an organization need to know the admin creds, does it make more sense to store it in a spreadsheet or file, password protect it with AES 256-bit encryption using a very strong password (longer the better), and securely pass the file around to those who need it and update the passwords on a frequent basis? The file would be stored on the local machine of each user who are privy to the information. And maybe break out the creds into several files and each file has a different password to open it.
I'm very curious to hear what others in the community would recommend.

I'd rather have a password manager with 2 factor auth.  You're quite right, in that it's a target, and it's got to be one of your #1s in any kind of DR scenario. I think the advantages of one source of truth, secure password sharing, true random password generation, and granulated access control are worth the hassle of having another system to make highly available, etc.
There's so many disadvantages with using multiple copies of anything, so many ways it's open to abuse and human error...even within a small team.


What's the best place to hide long lived encryption keys I am considering encryption options for a new Sybase project (internal facing only, sitting in our intranet) for a client that has a security policy that requires all sensitive data to use DB encryption, and be only available to a trusted few. I am thinking that Sybase encryption is the wrong strategy because a) dba's can get in easily, and b) if and when we migrate to SQL Server or Oracle I don't want to deal with different encryption strategies.

Therefore I'm thinking of maintaining a single table of sensitive data, and to encrypt that column (symmetric encryption) in my Java code before storing it in the DB.

Now, the encrypted fields better not have their encryption key changed, ever, except in a very controlled environment, which for me effectively means never. So it's going to be a permanent password.

The question is, where to keep it. If it's in a properties file, any developer with access to our Git repo could see it.

We could hard code it in the source code, but good lawd, that's a bad practice.

We could generate it in source, like the 10th Fibonacci or 3!+8! that would be hard to locate, but it's still rather exposed.

We could have the sa's maintain it in the environment, but then where do they file it for future reference?

So many poor choices. Are there any good ones?

Well if you're really really really serious about the security of your keys then there's only one answer.

HSM

Encrypt your data at rest using a symmetric algorithm and encrypt the keys used for the symmetric algorithm using asymmetric keys, the private key for which is stored in the HSM.

HSMs are carefully and purposefully designed so that once on them, keys cannot be exported from them.  You send a command to the HSM asking it to "do something" with your key (e.g. encrypt, sign, decrypt), but the key never, ever leaves the HSM in any readable format whether printed on console or exported to a file.

If you can't justify the cost of an HSM because your data is not valuable enough or you simply can't get the budget, then the "next best" option is probably going to be a hosted "cloud HSM".

Sure there are risks involved with a third-party hosting your HSM, but those risks are probably lower than you trying to be clever (and failing at)  obfuscating your keys and trying to "hide" them yourself just because you don't want to pay for your own HSM.


Will dm-verity protect against firmware malware on storage devices likes HDD or SSD? Malware on the firmware level can potentially mess with data on the storage device. There is no point in doing that for encrypted data except maybe corruption. But what about a smartphone or other device with dm-verity where the system partition is not encrypted. Could this kind of malware break dm-verity?

Absolutely. dm-verity operates at a higher level than firmware, so as long as the malware does not show its true colors, dm-verity will do nothing.
Such a malware could only operate (apart from destroying the data on its storage) by supplying different data than it is stored. For example, upon activation, malicious code would be "read" from the disk where intact code is actually stored. That operation would be caught by dm-verity:
From the docs:

dm-verity protection lives in the kernel. So if rooting software
compromises the system before the kernel comes up, it will retain that
access. To mitigate this risk, most manufacturers verify the kernel
using a key burned into the device. That key is not changeable once
the device leaves the factory.

The firmware hack does compromise the system "before the kernel comes up", but then it would hit against the read-only key check. So the hack would need to also disable the verity code (which may or may not be possible depending on where exactly this code resides).
On the other hand, how exactly is the key recovered? The kernel has to ask the device for the key, and while an external program cannot change the key, the hacked firmware can ignore this fact and report a different, changeable (and changed!) key.


Why do most hashing functions produce hashes that have characters a-f 0-9? This is something I never understood about hashing functions.  I know that algorithms like whirlpool and blowfish both produce outputs that don't follow this pattern, but why is it that most do?  Is it some kind of hardware/software thing?  If they did produce outputs that went a-z0-9 instead of a-f0-9, wouldn't that increase their complexity?

It's just hex encoded. A 16 byte md5 hash can contain non-printable characters, so it's encoded to a 32 char hex string.


Can you ever get partially decrypted data from a decryption algorithm? I'm decrypting some data using Java and Apache's most recent WSS4J library with 128-bit AES decryption.

I setup the the cipher which appears to be correct with the right padding, decryption algorithm, and cipher block mode.

I then make a call to doFinal() on the encrypted data bytes and it successfully returns a value.

My question is would it ever return a value that is only partially decrypted?

For example, let's say the first 16 bytes are still jumbled up after decryption, but the remainder of the data returned has been successfully decrypted, and is human-readable with the expected data there.

Would this mean that there could be an issue with my decryption process? Or would it not even be able to return a value from the doFinal() step if something was even slightly off with the decryption setup?

If I get a value returned from doFinal() would that mean that 100% the data returned is the original data before it was encrypted?

I'm decrypting data from a web service call and the owners of the web service are claiming that I must be doing something wrong during my decryption process and that they are sending the data correctly.

Depending on the block mode you are using, you can get partially decrypted data. For example, in CBC mode, if an incorrect IV is supplied, the first block of data will not decrypt properly. However, the rest of the data will decrypt successfully (assuming you are using the correct encryption key). This is because the IV of block (x + 1) is the ciphertext of block x.

Wikipedia's diagram is pretty helpful in visualizing this.

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29


Is there any way my password is hashed, if I'm only ever asked to provide 5 out of many characters? There is a system that, on a login form, presents about 40 boxes for password letters (to hide password's actual length), and only random ones (the same amount each time) are editable. Explanation is - to secure me from keyloggers. Seems legit. But does it means my password is kept in plain text? Or is there any known hash algorithm that would permit this?

Note: I'm not asking if it is a good or bad practice, I ask about possibility / feasibility / method of hashing.

No - there's no practical way to hash your password in this case.

For the website to work this way, the hash would have to allow you to verify that a 5-character subset of the password matches a certain value. That means you could brute force those 5 characters on their own, which is readily practical, and once you know 5 characters, it's easy to brute force the rest. This is somewhat similar to the weakness of LANMAN passwords.

Partial passwords do have security benefits, especially against key loggers. Banking apps sometimes have a normal password that is hashed on the server, and an additional authentication code, which you only enter partially, and is NOT hashed on the server. This is considered completely acceptable, but becoming less common as multi-factor authentication is a better solution.

In this particular case, it is not clear-cut that this is a bad idea. You need to weigh the risk of server compromise against the risk of client-side key loggers. In fact, it is the client that is at greater risk. So despite going against normal best practice, this website is not so dumb after all.


Standard digital signature data representation I am creating digital signatures using various scheme, e.g. RSASSA-PSS.

The result is bytes that represents signed data with private key.

I would like to store signature as a standard data representation that would be understand by third parties software, including what type of signature data represents, etc.

What should be used?

Is CMS Signed Data structure good for this purpose?

CMS can be good if you want to store the signed data with the signature.

If you are signing always the same type of file, some formats can be preferable :

PADeS for pdf files
XADeS for xml files
CADeS for any file

Each format can have different levels, which match with different trust levels.
They can be found on the ETSI site.

If you are using Java, the open-source library SD-DSS is available an do it very well.

sources :

CADeS : https://www.eldos.com/security/articles/7031.php?page=all

ETSI documentation : http://www.etsi.org/standards-search

SD-DSS : https://joinup.ec.europa.eu/software/sd-dss/release/all


Constant time compares when array sizes are not equal? What is the preferred or recommended way to pursue contestant time compares when array lengths are not equal?

Should we exit as early as possible? Something like:

if (array1.size() != array2.size()) {
    return NOT_EQUAL;
}

int accum = 0;
for(int i = 0; i < array1.size(); i++) {
    accum |= array1[i] ^ array2[i];
}

return (accum == 0) ? EQUAL : NOT_EQUAL;

Or should we avoid the early exit, and compare as much as possible in hopes of masking as much as possible? Something like:

int size = min(array1.size(), array2.size());
int accum = (array1.size() ^ array2.size());

for(int i = 0; i < size; i++) {
    accum |= array1[i] ^ array2[i];
}

return (accum == 0) ? EQUAL : NOT_EQUAL;

Or something else?

Or is this question more appropriate for the folks on the Crypto.SE because its  theoretical minutia?

EDIT: this seems to be related to Timing attacks on password hashes. But the cited question is a particular instance of the generalized problem (and I'm interested in the generalized question).

I'm not sure I agree with the cited question's answer or assertion that "Using timing attacks in this case will in no way tell an attacker more than what he would know if he had the actual stored hash and salt..." because the attacker could be trying to recover the hashed password though timing attacks. Given a hashed password, its only a leap back to the password in some cases.

Aborting early is fine, as it doesn't reveal timing for anything secret (unless you consider the length to be a secret, which doesn't seem plausible).

As for your edit, comparing password hashes in non-constant time is also fine. The attacker has no efficient mechanism to "choose" password hash outputs such that he can iterate through all possibilities for a byte at one position while holding the preceding bytes constant. So there is again no timing attack — not even to reveal the hashed password.


Is (safe) encryption over compromised line impossible? I realize something like this would be the holy grail of communications security and have never heard anything to suggest it has been done.

Am just wondering. A lot of mathematicians and computer scientists spend time doing proofs for theoretical situations. Has anyone done a proof to rule out the possibility of ever doing a key-exchange (or some other encryption setup) over an open or already compromised line?

To be clear I mean : A and B are communicating while C has the potential to be listening (ideally C is not listening in real time and is only logging A&B for action later). Is it impossible for A and B to ever exchange information over the compromised line to setup a new encrypted line that C can't immediately crack?

Last Clarification : I'm realizing public key may technically satisfy the problem by not transferring the whole method of encryption over the line. Is there anything else you do, even if only theoretical? This feels like more of a loophole than directly solving things.

If the attacker is only passively listening to the connection then Diffie Hellman Key Exchange can be done to create a common key known only to the communication peers.

But, if the attacker can not only listen to the connection but also actively modify the transferred data, then the attacker might mount a man-in-the-middle attack and claim to be the expected communication partner for both A and B. This can only be prevented if  A can identify B before starting the encrypted communication and thus knows that it exchanged the key with the expected partner. For this it needs a secure way to verify the identity even if the line is compromised. This can be done by public-key cryptography. But of of course it needs some kind of prior knowledge about the expected identity of B, i.e. either A knows B already (direct trust) or it knows somebody who knows B etc (trust chain).

You'll find an implementation for all of this with SSL/TLS and the associated PKI. This is used with https in the browsers and the necessary trust anchors for building the trust chain are the public certificate agencies which are either known by the operating system or by the browser. For more information see How does SSL/TLS work?.


What are the differences between JSON Web Tokens, SAML and OAuth 2? What are the differences between JSON Web Tokens, SAML and OAuth 2. Please provide some pointers and high level overview of their functions.

Specifically, why would one use SAML over JSON Web Tokens or viceversa? Does one need to have OAuth 2 to use JSON Web Tokens/SAML? Or can JSON Web Tokens/SAML be used independently?

SAML and OAuth 2 are protocols used in authentication/authorization. JSON Web Tokens (JWT) is a specification for a token that can be used in many applications or protocols - it happens that the OpenID Connect (OIDC) protocol uses the JWT. SAML also defines its own token: SAML Assertion; as does OAuth 2: Access Token. Tokens used by these protocols denote you have been authenticated/authorized and convey information about you or the session.

+----------+----------------+-------------------------------+
| Protocol | Token          | Technologies | Design Pattern |
+==========+================+==============+================+
| SAML     | SAML Assertion | SOAP, XML    | Facade         |
+----------+----------------+--------------+----------------+
| OAuth 2  | Access Token   |              | Proxy          |
+----------+----------------+--------------+----------------+
| OIDC     | Access Token,  | REST, JSON   | Decorator      |
|          | ID Token (JWT) |              |                |
+----------+----------------+--------------+----------------+

The software design patterns associated with each of the protocols in the table above summarizes in one word what these protocols were intended to accomplished.

SAML. The Facade pattern provides a unified interface to a set of interfaces in a subsystem. SAML is the original federated identity system, invented by universities to allow students to access other university libraries, but each university maintaining their own student identity system. De facto standard in most enterprise environments. Built around XML and SOAP.

OAuth 2. The Proxy, much like its name suggests allows clients access to your information as if they were a proxy for you.

OIDC. Extends OAuth 2 by adding user ID and user info to the protocol. Often regarded as a modern version of SAML. Widespread use in the consumer space - almost all social media sites support OIDC. Built around JSON and REST.

Hopefully, this untangles your questions a little. You can't quite compare SAML (protocol) with JWT (token), but you can compare SAML with OIDC. You could however compare a SAML Assertion with an OIDC JWT. The OAuth 2 specification does not specify the underlying structure of its tokens. You might also find it interesting that OIDC can consume the SAML Assertion as well as its own JWT.

The consensus is that OIDC will eventually supplant SAML, but SAML has been around since 2005 and is very mature - an important trait in enterprise environments. Even though OIDC is relatively new (2014), authentication solutions these days (2018) are expected to support it. SAML was designed in an era where Web browsers were dominant and has somewhat of an awkward time with Mobile or modern Web applications. OIDC on the other hand supports modern technologies such as REST and JSON that makes it much more accessible from applications these days.

However, OAuth 2, OIDC and SAML do not actually specify how authentication and authorization are done in the way those two terms are traditionally defined.

When you hear authentication you think of a login/password, or fingerprint, or passcode sent to your phone - none of these protocols cover these  specifics, rather authentication is delegated to the identity provider (IdP). These protocols specify how you should be redirected to an IdP to get authenticated, and if successful how the tokens/assertions are returned.

OAuth 2 "authorization" deals with obtaining user consent, i.e. whether to give a service access to your information/data - it does not mean authorization in the access control sense. OIDC much like OAuth 2 also supports a means of obtaining user consent. While SAML supports user consent as well, it is not generally used within an enterprise/intranet environment.

Authorization (referring to the more traditional access control meaning) is also not in OAuth 2, OIDC and SAML specifications, but they allow for tokens to contain claims such as whether a user belongs to an administrator group, which client services can interpret however it likes.

OAuth 2, OIDC and SAML are great facilitators for different authentication and authorization (access control) schemes, but do not actually specify the actual underlying mechanisms.

UPDATE 9/5/2018. Updated for 2018.

UPDATE 4/26/2017. Fixed incorrect statement about SAML not supporting user consent - it does, but not widely used.

UPDATE 2/22/2017. Clarify authentication, authorization (access control), and user consent in response to user comment below.


If most ATMs are Windows XP, and Windows XP is no longer updated...? ...how do banks keep their ATMs safe?

Have a handful of companies sprouted after XP's end of cycle offering patches?

ATMs normally lie on a isolated network directly to the bank that owns the ATM. This is normally enforced by a VPN-router if theres no leased point-to-point line at the location, where the local end does not allow any traffic outside the VPN, even if malicious software on the ATM deliberately tried, and the remote end's firewall is configured to not allow any traffic other than is required for ATM operation.

This means normally that the ATM does not have access to the internet, nor does the internet have access to the ATM.

As the customer also never gets to have any physical input to the ATM, like usb, keyboard or mouse, rather the customer input via cardreader, pinpad and screen selection buttons, are managed via RS232, and similiar interfaces, so the ATM software has full control and customer cannot send any data to the underlying operating system, the ATM can be considered being isolated and safe.

Thus:
Since theres no possibility to inject malicious software, neither via the local console (if you don't have the keycard to open the restocking/maintenace room, but then the security of the ATM computer is less of a issue since if unautorized access has happened to that room, ATM is usually replaced as a precautionary measure), and neither via the internet, unless you do have access to the bank's server hall where the VPN terminates.
There cannot be malware or hacks on the ATM in the first place, regardless of the security of the OS.

And in addition, even if someone managed, despite all security measures, to plant some sort of malware on the machine, the malware cannot send its data anywhere.

Communication with the card reader, pinpad and cash unit is usually encrypted end2end.

In other words, by planting malware on a ATM, you would just get a fancy receipt printer, or you can prank the user by changing the amount the user want to withdraw - eg user select "10$" but a "50$" bill comes out and "50$" is pulled from account (and most users would regard the ATM as broken and depoist the sum they got "too much")

So the security of the operating system on a ATM does not really matter. The security around is normally so tight so it compensates.

In addition, some newer ATM provisions their operating system and relevant ATM software via PXE, and reboots regularly, to clear out all and any unauthorized changes to the system installed on the ATM.


PIN delivery: do PCI DSS requirements prevent sending the PIN to an end-user's mobile phone? Do PCI DSS requirements prevent processors from sending to endusers' mobile phones the PIN?
I went through many PCI documents, such as the PCI security requirements 2.0 and this isn't mentioned. I'm not sure this is mentioned somewhere else, but I'd really like to have proof on that.

Storing PINs is prohibited under PCI DSS so one can assume transmitting PINs is not compliant.


How do you destroy an old hard drive? How do you destroy an old hard drive? To be clear, unlike questions Secure hard drive disposal: How to erase confidential information and How can I reliably erase all information on a hard drive? I do not want to erase the data and keep the hard drive, I want to get rid of the hard drive for good. It's old, small, may (or may not) contain personal information, and is not connected to a computer (a step I prefer to avoid). I might as well destroy it because it is easier and more certain that the data is destroyed too.

Any other advice is also appreciated as an answer. Keep in mind I am looking for an easier and more reliable data-destroying solution than wiping drives.

Physical destruction of a drive is tricky business. There are many companies that deal specifically in the field of data destruction, so if you are doing any kind of mass you may want to at least look at their price list. If you contract, make sure the company is properly bonded/insured, and provides audit trails for each  destroyed item. In the worst case scenario that your information does get out, you want the document in hand that says your contractor properly destroyed the item in question. Then, at least, you can transfer the liability.

When it comes to drive destruction you typically see one of two main fields:

Disk Degaussing
Physical Destruction

Degaussing

Degaussing used to be the norm, but I am not such a big fan. On the plus side it is fast, you'll normally just dump the disks on a conveyor belt and watch them get fed through the device. The problem is auditability. Since the circuitry is rendered wobbly, you won't be able to do a spot check of the drives and verify that the data is gone. It is possible, with some level of probability unknown to me, that data could still exist on the platters. Retrieving the data would, without question, be difficult, but the fact still remains that you cannot demonstrate the data is actually gone. As such, most companies now will actually be doing physical destruction.

Physical Destruction

At the low end, say a small box of drives at a time, you'll have hard drive crushers. They're often pneumatic presses that deform the platters beyond useful recognition. At the risk of supporting a specific product, I have personally used this product from eDR. It works well, and is very cathartic.

At a larger scale, say dozens or hundreds of disks, you'll find large industrial shredders. They operate just like a paper shredder, but are designed to process much stiffer equipment. The mangled bits of metal that are left over are barely identifiable as hard drives.

At an even larger scale you can start looking at incinerators that will melt the drives down to unidentifiable lumps of slag. Since most electronics can produce some rather scary fumes and airborne particulates, I would not recommend doing this on you own. No, this is not a good use of your chiminea.

Manual Dis-assembly

If you are dealing with one or two drives at a time, then simple dis-assembly might be sufficient. Most drives these days are largely held together with torx screws, and will come apart with varying levels of difficulty. Simply remove the top cover, remove the platters from the central spindle. Taking a pocket knife, nail file, screwdriver, whatever, have fun scoring both surfaces of each platter. Then dispose of the materials appropriately. I cannot speak to how recoverable the data is afterwards, but it is probably sufficient. The biggest thing to keep in mind is that while most desktop hard drive platters are metal, some are glass. The glass ones shatter quite extravagantly.

You should also take care of removing and destroying the memory chips on the board because of cache memory and (with "hybrid" drives) of NAND chips containing up to 4GB of cached data.
A good way to do that is to wrap the board in linen or another coarse cloth and hammer it, that should keep broken parts from flying everywhere.

Additional Considerations

Before you decide on a destruction method, make sure to identify what kind of data is stored on each device and treat it appropriately. There may be regulatory or legal requirements for information disposal depending on what data is stored on the disk. As an example, see section 8-306 of DoD 5220.22-M.

For hard drive destruction, DoD 5220.22-M section 8-306 recommends:  "Disintegrate, incinerate, pulverize, shred, or melt"

All that being said, performing a single pass zero wipe is probably sufficient for your purposes. Modern research indicates that modern hard drives are largely immune to the "magnetic memory" problem we used to see on magnetic tape. I would never bother doing anything more on a household drive unless the drive itself was exhibiting failures.


How can Nmap bypass Windows Server firewall rules? I need to block all communication (inbound/outbound) from server A to server B (all ports/all protocols). Server A should communicate with every machine except server B. I can't place firewall rules on server B, so I have placed all rules on server A.

I have done the following on server A:

First I disabled all default firewall rules (inbound/outbound) on server A. (This is required.)
Then I created an inbound rule that allow access from anywhere.
Then I created an inbound rule that deny access to server B (all protocols/ports).
Then I created an outbound rule that deny access to server B (all protocols/ports).

I have tested that the access is restricted via ping from both servers, and it seemed to work. But then I installed Nmap on server A and scanned server B. My assumption was that Nmap would not be able to scan server B, as the firewall would block it. But Nmap is able to scan open ports of server B. How is that possible?

Windows Server 2008 is installed on both machines.

As others mentioned it could be related to the ordering of your firewall rules.

Also modern host firewalls also allow for process/program exceptions so it's possible that during the installation of nmap the installer added a process exception for itself to the windows firewall allowing itself to bypass other rules.


Three Message Authentication Protocol I have a protocol where "A" initiates communication with "B". "B" then sends a challenge to check if "A" is really "A". "B" does not remember sending the challenge so "A" has to respond by sending the challenge back along with encrypted challenge with her key.

Example:

A ----Hi i am A-----> B
A <-- challenge --- B
A --- Challenge + Encrypted challenge ---> B

Modified

A ----Hi i am A-----> B
A <-- challenge + encrypted challenge with "B" key --- B
A --- Encrypted challenge with A+B Key ---> B

Are any of these two  protocols secure for "A" authenticating itself to "B"?

So

A ----- says wants to contact B ----------------------->  B

A <---- encrypt some challenge with his private key ----  B

A ----- decrypt the challange with B public key
    encrypt the challange with A private key
    encrypt the challange with B public key
    send both to B ------------------------------------>  B

    decrypt the challange with A public key   ---------   B
    decrypt the challange with B private key
    they are the same? ok, so I could open a
        a message to me (good) that was sent
        from someone who have the A private key.

Problems with that:

Does B have the public key from A?
If not, where does he gets it ? (answer: some PKI ?)
If yes, is he sure that the keys belongs to A? (answer: certificate)
and he verifies that A's key is valid (answer: CRL or OCSP)
Does A have the public key from B? The same questions apply.

Doing those verifications, it would work. Not doing then means that you'd have a problem with:

A not knowing that he contacted B
B not knowing he received a message from A


Recovery plan in case of lost Android smartphone with Google Authenticator? So I am using Google Authenticator as my two factor authentication.

I'm not a security expert, but I was thinking late last night as I was about to fall asleep:

  How can I login to my favourite 2FA-enabled websites if I lose my Android?

Can someone with knowledge of this kind of thing please advise what I might do to safeguard against losing my Android? I run pretty mission-critical stuff on Amazon EC2 and have 2FA enabled.

Hi everyone, so I ended up going into all my accounts and disabling 2FA. I then re-enabled 2FA in all my accounts, but also saved the QR code in my encrypted folder. I think that's the best solution? This way, I'm not relying on Google...

First make sure nobody can abuse your codes. This may be even more harmfull than you not being able to login for a short time. So encrypt your phone and your external SD card if data is stored there. This requires that you use a PIN or password to use the phone. So nobody can use Authenticator without knowing that PIN. Don't use 0000 or 1234 but something complicated and easy to type that is long enough to make it impossible to break by hand.

Use backup codes, and you can use a backup phone number for Google login, possibly for other logins as well.

Root your phone, use Titanium Backup to backup your phone, including apps like Google Authenticator, including user settings and data. When you restore this - like in a VM - you can keep using your 2FA like normal. Backup to a local computer, and backup to an encrypted drive if you need the security. Keep multiple backups at different locations if necessary.

Create an Android VM, install Google Authenticator on it. Make new syncs. If you want to protect this VM, install the virtualbox disks on an encrypted disk.

Update

Lately I use the Authy app, which makes it possible to make backups and which can be used as a Chrome app.


Can too restrictive Linux MAC policy decrease security? Can too restrictive MAC profile (e.x. AppArmor profile) decrease application security?

For example: could it be that too restrictive environment for web browser will protect host system very well while disabling some internal browser security features (because browser will not get enough support from host system for its security features)?

This question probably is even more generic for any application.

A MAC policy should be extremely fine-grained, not necessarily extremely restrictive.
It can decrease security under certain conditions. Applications, especially complex ones, often have fallbacks when a given resource cannot be accessed. The reasons for this can be anything from being unable to access a security service to entering an insecure compatibility mode for an older and less secure system. Sometimes the issue is simply that the application has not been thoroughly tested and being unable to access a normally present resource leads to security bugs.

As mentioned in a comment, the Secret Service on many Linux environments provides an API for securing passwords, without which browsers and other applications may attempt to store passwords internally, potentially with less security.

LibreSSL infamously attempts to generate its own randomness from the environment if it cannot read the randomness character devices or any other fallbacks, leading to predictable output. This issue has actually lead to the development of a randomness syscall so applications can access entropy even in overly restrictive MACs or chroots.

Programs with PAM support will not be able to obey PAM policies if they cannot access the relevant libraries and configuration files. Breaking PAM doesn't directly reduce security as the fallback is to access system passwords through the normal methods, but it can break complex policies that increase security. This may, for example, break keycard recognition.

When developing an access control policy, it is important that none of the normal resource access attempts for whitelisted applications are denied unless you have a solid understanding of all of the implications of denying the resource. For example, denying access to /etc/localtime is likely to result in an application using UTC time only, whereas blocking access to a standard file guaranteed to exist on all systems may cause unforeseen and severe bugs. When a denied access is triggered, the event should be logged for later review. If you find out that the access is benign and not likely to increase attack surface, you can add it to the whitelist.
I suggest you look into AppArmor abstractions which allow the inclusion of sub-policies with specific purposes, such as whitelisting audio access. This allows you to simplify your policy by adding an #include <abstractions/audio> rather than having to whitelist individual objects. This makes AppArmor policies significantly simpler than they otherwise would be, while still maintaining a high level of security. Many MAC architectures support a similar feature.


Having a consistent "don't reveal email addresses of members" policy Developers are dogmatic on having "invalid username or password" on login screens; our applications should not reveal if somebody is a member given an email address.

But there are two other ways our application can reveal a member:

the signup page returns a "this email was registered by somebody else" (often this is a dedicated endpoint for Ajax)
the reset password page has a "your link has been sent to your email" or "provided email does not exist in our records"

Why are we only worried about the login screen revealing membership? Should we plug these holes as well?

The "provided email does not exist in our records" on reset password page is useful when we have entered a wrong email or we signed up with wrong email address. Example: I am named Raj, have wrongly signed up with ral@example.com (mispelled J) and I try to send a reset request to raj@example.com.

If this is supposed to be a secure system to that extent and since the email address is disclosed elsewhere, the developers could make the username a randomly generated number instead of the user's email address. This closes the information leakage gap.

For instance, for a generated numerical username:

Failed login: "Username incorrect"
Failed password: "Password incorrect"
Already registered: This error won't occur with a surrogate username key unless you have a company policy that people (e.g. in a family) can't use the same email address.
Password reset (by username): Email address isn't disclosed as message can say "Reset link has been sent to the email address associated with this username."
Password reset (by email address): "Reset link has been sent to this email address for all accounts that are associated with this email address."

Besides, the either/or fallacy of login field validation adds only a few bits of extra entropy to the overall brute force security whilst decreasing usability. Just increase the minimum password length requirements to gain the same effect sensibly. One assumes that exponential delay exists on the password attempts in any case.


Can your iphone be unwittingly jailbroken? Is it possible for an iphone to be jailbroken by visiting a malicious website in your iphone's browser?

Jailbreaking from the browser used to be possible. Older iPhone OS's will still have this potential vulnerability. That being said, jailbreaking via a browser has now been outdated and patched by Apple. I believe it was patched in iOS 5.0 and has been patched since. So older iPhone users (pre-iOS 5.0; which are few and far between) might still be vulnerable and potentially a malicious website could exploit this. As of now, all jailbreaks (to the best of my knowledge) require a physical attachment to a computer in order to load on the jailbroken firmware.

That all being said, I will be one of the first to say that jailbreaking a device does not make it unsecure. It becomes unsecure when you jailbreak and install potentially harmful apps only available with a jailbreak or apps which create extra security holes. However, there is the concern that if a jailbreak can be installed via an iPhone browser, a modified firmware with security holes and viruses could be installed to. Again, though, I wouldn't concern myself over it as long as you're running a semi-new iOS firmware.


Any example where client certification is required? There are some optional cases in SSL/TLS where server can demand the certificate of the client. Can anyone give me any example regarding this?

Thank you.

An SSL server requires a client certificate if the server says so. In an overall system, this makes sense only if authorized clients have been provisioned with certificates, which is not a very common situation.

In my daily work, we develop and deploy a PKI for distributing smart cards, and certificates on smart cards, to physicians. This is so that the said physicians may access from their computers centralized medical records for patients. Medical records are "very private" and thus strong authentication is needed for access; when using Web-based technology (the tool on the physician side of things is a Web browser), the authentication is based on SSL and the SSL server demands a certificate from the client.

PKI is complex (the software is simple, the procedures are mindbogglingly twisted and byzantine) so such things happen only when someone injects a lot of money in the project.

Some banks have played with the concept of issuing certificates to their customers -- for Web authentication (in SSL) and, more importantly, for digital signatures on bank order submitted online (this kind of signature is not an SSL feature). I think UBS was doing that at some point; I am not sure they still do.


Does an SSL Certificate (https) guarantee security without every page being SSL secured? I'm writing a paper for class and one of the things I'm writing about is internet security. I know that SSL certificates can be easily obtained and are supposed to encrypt data on SSL certified pages.

I know that people experience issues with making their site fully secure even with purchasing SSL certification - so just because one page shows the SSL badge or has https protocol, doesn't mean that every page on that site is secure.

I'm going to present a hypothetical situation and reiterate my question to hopefully clarify what it is that I'm asking:

Suppose I go to a website that shows it's SSL secured. I click to create an account and the new user registration page also shows that its SSL secured. The login page is also SSL secured and I login to my new account. (so far everything has shown to be SSL secured). As I explore this website (logged in) some of the pages I go to DO NOT show the SSL emblem.

My question is: If I have only entered information that should be secured, on pages with SSL.. Does that guarantee that it's actually secure?

Additionally.. Does that information remain secure from the admin? Like can a site appear "secure" but be exposed vulnerabilities or be a mockery of SSL certificates?

Thanks!

"Secured" is an overloaded non specific term.

SSL encrypts the connection between the server and client at the point in time that a connection is open.  That means the data is encrypted while in transit between the client and server.  It also provides cryptographic assurances that the certificate used to encrypt the connection was issued by a trusted certificate authority to an entity that has administrative control over the domain name in the address bar.

What happens after that is outside of the scope of SSL.  So no, once you're done submitting your secure information via a form, there is no reason to believe that it would be secured from the admin.

Something else to consider:

Just because a form is on a page that is using SSL, doesn't mean the form submission itself is secured with SSL.  The html form tag has an action attribute which points to a url on the server. The value on the action attribute can be setup in a 1 of 3 ways.

Use SSL if the containing page is using ssl.  Don't use ssl if the containing page is not using ssl.  An action attribute of this type would take the form of action="/formprocessor"
Always use ssl regardless of the containing page this would look like action="https://example.com/formprocessor"
Never use ssl, regardless of the contaning page.  This would look like action=http://example.com/formprocessor"


Fuzzing with SPIKE - the \r\n not being taken into account I would like to fuzz FTP protocol, and currently I have the following:

 s_read_packet();
 s_string("USER test\r\n");
 s_read_packet();
 s_string("PASS test\r\n");
 s_read_packet();

I've also tried with s_readline(); The problem is that I'm getting what's shown in the following picture:

I should be getting what's on following two pictures:

It looks like the SPIKE doesn't know about "\r\n" characters. Any ideas on this, why isn't it parsing the CRLF characters correctly?

When writting my response to you, I remembered what might be the problem and I've tested it and bingo - that's exactly what's wrong.

The problem isn't with a script, but with a generic_send_tcp - this is not acting as it should. If I use the following command line:

line_send_tcp 10.1.1.169 21 ftp.spk 0

instead of

generic_send_tcp 10.1.1.169 21 ftp.spk 0

everything works. So that's it. Thanks.

I guess now we need to ask ourselves why does generic_send_tcp misbehave?


Can a data requester get the sender when "Sealed sender" is enabled in Signal? The Signal app offers to seal the sender. The whole process can be summarized in the following steps:

The app encrypts the message using Signal Protocol, as usual.
Include the sender certificate and encrypted message in an envelope.
Encrypt the envelope using the sender and recipient identity keys.
Without authenticating, send the encrypted envelope to the Signal server along with the recipient's delivery token.
The message recipient can then decrypt the envelope by validating the identity key to know the sender of the message.

Is Signal able to give out the sender to a data requester, for example the FBI, with the mentioned process of sealing the sender?

In the blog post about the new feature, Signal says:

  Message contents are end-to-end encrypted with the Signal Protocol as normal, but the “envelope” containing the sender certificate as well as the message ciphertext is then also encrypted using the sender and recipient identity keys:

The feature is designed to hide the sender of the message from plain view, and leaves this inside the encrypted envelope, so only the recipient and sender can know who actually sent the message.

So yes, it disallows Signal from knowing the sender of the message, yet allowing the recipient to know.


What is a typical response from webserver for POST request? My web server is returning a 200 OK after submitting a POST request, but it does not seem to be a good idea according to a security team.

It should return a 302 "Object Moved", so that it avoids caching sensitive information.

"If a form posts sensitive data through a POST request, the server should return 302 "Object Moved" response, to redirect users to a different page. This avoids caching sensitive information"

To me returning HTTP status code is really up to the web application and the framework it is using and how it is designed.

Not sure if every POST request should result in 302. If I log into a website instead of doing redirect it is returning 200 OK.

As long as it is doing it through POST request over SSL I am not seeing problem with it. Can you guys enlighten me on this?

The question appeared to deal with the HTTP Response method chosen, and it's impact on caching.  See "POST Caching" below for the answer to that question.

Clarifications by the OP in comments suggest that the security team is concerned with the browser remembering values entered into field forms, such that they're accessible to 'back' or 'autocomplete' usage.  That is completely unrelated to the HTTP response that the server chooses to issue; even if a redirect is used, that just increases the number of 'back' clicks necessary to return to the information.

The HTML form autocomplete attribute and HTML input autocomplete attribute are used to request that the browser not remember the values entered.  However, these are requests, not prohibitions.  Browsers can do whatever they want, and have been known to ignore or misinterpret these tags, and to exempt anything they find interesting from being subject to them.  Chrome, for example, has had this thing where "off" doesn't work but "false" does.

So - there's things you can do to help it, but not to control it.  And a 302 instead of a 200 isn't one of them.

POST Caching

A POST with a 200 response will not be cached unless additional HTTP headers in the response specifically request it.  See Is it possible to cache POST methods in HTTP? from StackOverflow; to quote their quote of RFC 2616:

  9.5 POST

  ...

  Responses to this method are not cacheable, unless the response
  includes appropriate Cache-Control or Expires header fields. However,
  the 303 (See Other) response can be used to direct the user agent to
  retrieve a cacheable resource.

Your security team had a good thought, but failed to ask if the architects of HTTP managed to have the same good thought first.

In practical terms, this is why your browser prompts you when you try to reload a page that was the response to a POST form submission - it tells you the request will be retransmitted to the server, because the browser did not cache the original response.


Password Managers: Which passwords to still remember? Let’s say I use a password manager (like 1Password) on all my devices. In my personal opinion it makes sense to have some passwords in your head (you could still have them in the password manager, and they should be unique).

One example is the Apple ID Password or Google Account, whatever mobile you are using: Say your mobile gets stolen and you want to wipe/track it as soon as possible. If you know your Apple ID password, you can ask anyone around, log into your id on their phone and wipe your stolen device.

Are there other passwords which it makes sense to remember for certain situations?

I have read this question, but that asks if you should leave certain passwords out of your password manager, which is not what I’m asking.

I think it depends on your threat model, how you use your devices, what services you need to use, and some other details. Personally I would not enter my passwords on someone else's device (a stranger on the street?), so I would not do what you suggested in case my phone was stolen. I'd just hope my screen lock prevented the thief from accessing anything, at least until I got home on my computer to track or lock the device. If my screen was not locked, well, uhm, let's say my mitigation of this threat is still in progress.

Anyway, here's a list of passwords that I think should be remembered in general:

Password for the password manager (master password)
Password for full disk encryption of your computer
Passwords for full disk encryption of your backups (external HDDs, USB sticks, etc.)
Password for logging in or unlocking the screen of your computer
Password to unlock the screen of your phone
Passwords to access the most important services (at least your main email account from which you could reset the passwords of most of the other services)

Note that most of the above passwords won't be difficult to remember, because you are forced to use them every day (to unlock the phone, boot your computer, etc). Also, if you use an online password manager, you don't really need to worry about remembering the passwords for your backups, because if your computer blows up you can always log in to your password manager from anywhere and retrieve the passwords. But in my case, since I use a local password manager, if my computer blows up I'll have to rely on my backups and be able to access them.

So as you can see, it depends. If your threat model requires you to be able to access a certain service quickly without using your password manager, then yes, consider learning that password (or change it to a passphrase you can learn and remember more easily).


Why is security generally overlooked in application code until it's too late? Programmers do not receive security training, is it due to costs? How can we overcome the externality problem?

It's due to the fact that application security is an economic externality (https://en.wikipedia.org/wiki/Externality);  The party who is suffering from the lack of application security is not the one who makes decisions about the security.  It's the same economic problem as pollution.

Let's make up an example.  I write server software for SOHO routers.  Multiple router manufacturers use my software, and end users by the routers from those manufacturers.   Spending the time/money to implement a secure SDLC means that my prices will go up.  Since the router manufacturers are not impacted by any security flaws (the end users are, in this case,) they have no incentive to pay a higher price.  As such, I have no incentive to spend extra money to secure my product.

Edit:  To answer your question about externalities, the answer is regulation.  I'm not sure if it needs to come from the industry level or the government level, but the only answer is regulation.


Security assessment of a legacy SSL/TLS implementation on an IoT device I am doing a security assessment on the communication security of a legacy IoT device. The objective is to assess and find security gaps in the current design/implementation.
The mode of assessment is manual, primarily with the reference of existing design and code. This is only client-side at device; while server is a cloud-based server. The device is using a GSM module (SIMCom SIM900) and makes HTTPS communication to server over internet using GSM AT commands.
Based on my understanding on SSL/TLS, I am considering below parameters or criterias for this assessment:
a. TLS protocol version
b. Cipher suites used
c. certificate and key management
d. Root CAs installed on the device
e. Embedded PKI aspect for device identity management
f. Hardware crypto aspect (SHE/TPM)
Am I doing it in a right way? Though I think above list of parameters are not specific to Device HW/SW platform; rather generic. but I guess that's how it should be! I mean parameter list will be pretty much same; however actual assessment on these will depend on security requirements and other aspects like device footprint & its platform etc.
Is the assessment parameter list I am considering is good and adequate?

This is a good start, but a thorough assessment would need to go much deeper than this.  For example:

How does the client generate random numbers?  Does it use a CSPRNG?  Or, does it use a weak random number generator, like the one used in early versions of Netscape Navigator, where a passive attacker was able to guess the random numbers generated for the session keys, and thus decrypt the ciphertext going over the network.

Does the client leak information when it encounters a padding error?   If so, then it might be susceptible to a padding oracle attack, as was the case with the Steam Gaming Client.

How does the client implement ECDSA?  Does the client generate a new random k for each signature that it creates?  If not, it may be possible for a passive attacker to calculate the private signing key after observing a few signatures, as was the case with the Sony Playstation 3.

These are just a few examples.  But, as you can see, subtle mistakes in the implementation of cryptography can have disastrous consequences.  This is why cryptography is so hard to get right.


Can keyloggers read what's in a field, or only your keyboard inputs? What about mouse movement? I thought of a simple way to throw keyloggers off when typing sensitive information into a field, however this method presupposes that the keylogger can't actually read what's in the field, and also that it can't record the exact movements of my mouse and exactly what was on my screen and in what position as I was typing and moving my mouse about. So that's my question, do keyloggers simply record key presses, or can they also track your exact mouse,  movements, and exactly what was on your screen at the time these moves were made, like the field in which the information was typed? In essence, do they have a clear picture of exactly what went on on my monitor when the information was being typed?
I'd rather not disclose the method I mentioned. I'm certain it's not even remotely as clever as I think it is, but still.

What a keylogger can do depends on how it's been programmed. The name "keylogger" is just a generic term to refer to a program that records what you do on your computer. Originally, simple keyloggers were just keyloggers, that is, as the name suggests, they recorded your keystrokes. But more advanced keyloggers have then been developed, capable of recording your screen, tracking your mouse movements, etc. This kind of malware could hide inside a simple program, or it could even hide inside a kernel module, so "keylogger" is really a very generic term.

The real problem you have is that if you want to defend against "keyloggers", whatever that means, then you also need to defend against all other kinds of malware. What are you going to do about that? If you think you can get infected by a keylogger, why can't you also get infected by a browser plugin? Why can't a "keylogger" also have a module that will patch your browser, giving the attacker full control over what you do online? Why can't the "keylogger" be just one part of the whole infection, which might actually be a rootkit? In other words, I see some problems with your threat model, which I suspect is wrong or incomplete. You want to know how keyloggers work exactly, so that you can find a way around them, but your threat model should also include a lot of other threats in the same scenario. Then you'll realize that knowing how keyloggers work exactly isn't going to be very helpful.


How to scan a PDF for malware? Can anyone suggest an automated tool to scan a PDF file to determine whether it might contain malware or other "bad stuff"?  Or, alternatively, assigns a risk level to the PDF?

I would prefer a free tool.  It must be suitable for programmatic use, e.g., from the Unix command line, so that it is possible to scan PDFs automatically and take action based upon that.  A web-based solution might also be OK if it is scriptable.

Very easy.

Didier Stevens has provided two open-source, Python-based scripts to perform PDF malware analysis. There are a few others that I will also highlight.

The primary ones you want to run first are PDFiD (available another with Didier's other PDF Tools) and Pyew.

Here is an article on how to run pdfid.py and see the expected results; Here is another for pyew.

Finally, after identifying possible JS, Javascript, AA, OpenAction, and AcroForms -- you will want to dump those objects, filter the Javascript, and produce a raw output. This is possible with pdf-parser.py.

Additionally, Brandon Dixon maintains some extremely elite blog posts on his research with PDF malware, including a post about scoring PDFs based on malicious filters just like you describe.

I, personally, run all of these tools!


IOT secure data transfer I have a question about a monitoring software architecture.

Think about 50 different locations in different cities. Assume that these locations are small plants.

In every location there are approximately 50 devices which produce small amounts of data which is a string and an integer counter.

I need to take these data from devices and save them in a server database within the plant.

Periodically I need to send these data from the server to HQ for reporting.
I don't want to send data from plant to HQ in realtime as the connection might be down for a day or 2 between the plant and the HQ.

Assume that we don't trust plant operators and products can be stolen. E.g. 50 products are produced in the plant but only 40 are reported to HQ.

Basically, a string and an integer should be taken from a device and transmitted to the HQ in another city.

There are 3 places where data should be secured, I guess.

Between device and server. (Both are in the plant, they will be connected via ethernet or serial)
On the server
Between the server and HQ

1) For the first path; device will be in a hard case which can't be opened by anyone except authorized personnel.
Software on the device will have a SHA key and it will encrypt data and send to the server over serial or ethernet. Server will write encrypted or decrypted data to a database.

Is encrypting data and sending it over TCP socket secure enough?
As the device can't have a Hardware Security Module, the encryption key will be hardcoded and it will be in memory. Is there a way to secure the key other than locking it in a steel case?
If the server has the same SHA key which is on the device, should it be on a Hardware Security Module?

2) The server will be secured by a hard case and will be accessible by the HQ over the remote desktop connection as well. Antivirus and firewall software will be installed and configured.

3) Should I again encrypt data on the server and send it over TCP sockets and decrypt at the center?

Should I use a protocol like https and use REST?
Do you recommend another solution?

I will assume the devices will transmit tuples (serial, counter, key, value) where:

serial: an unique id for the device (ideally set at the factory).
counter: a keeps track of the number of messages sent to the central server
key: name of the parameter you are sending
value: the number

Make the devices encrypt that big message with the public key of the center (if you can afford also having a private key per device, add a digital signature, too. Otherwise, use a fixed part on the serial id field that was generated at random and is not known to third parties).

The plant server only ever sees encrypted messages, so he can't modify them. It could choose to miss some messages, but you would notice the gap in the counter. Or that a given device stopped sending data two weeks ago.

Note that we go from "securing data on three places" to just "secure between device and center". Of course, there's no reason the plant server couldn't additionally use https when connecting with the central server, but that wouldn't be necessary for the confidentiality of the messages themselves.

You talk about "SHA key", which doesn't make much sense (SHA is used for message digests…). Simply use asymmetric cryptography. Your devices can probably use elliptic curve crypto.

You still need to get the other bits right, like using an authenticated encryption mode (eg. GCM) or else performing additionally checks, an attacker that compromised the whole device, could impersonate that device (but only that). The central server should check that things make sense... but otherwise this should provide a good basis to start.


Do fake-address generators work? There are several pages on the Web that generate fake e-mail addresses so spammers can harvest them; the purpose is to fight spam. (Some examples of this concept under discussion and, in some cases, in practice.)

For this to work, the spammers have to (a) harvest addresses off of the Web, (b) not 'blacklist' such pages (either on autodetection or on manual detection), and (c) care that their mail gets sent to real addresses. Are all these true? Do these address generators work?

And if so, then how do they work? Is the idea that the spammers will be inundated with returned mail and implode? That they'll have too a low a return (real responses) on their investment (e-mails sent out) and go out of business?

Fake email addresses most typically server as spamtrap (kind of honeypot). They idea is, since that such a email address would never be used to receive any legitimate emails, anything that comes is a spam. These spam messages are later analysed and used to update various RBLs (Real-time Blackhole List), nowadays most typically DNS based black list.

Upon receiving connection from blacklisted spammer, rather than rejecting connection right away many servers would use tar-pit technique. Which means basically keeping connection open until it times out. The idea is, that SMTP is typically transported over TCP, meaning that single computer has limited number of simultaneous connections (open sockets) it can make. Thus, should spammers use standard SMTP server with standard settings, tar-pitting would seriously hamper their throughput. However, all of above techniques are completely useless when spammers use botnets.


Why isn't a standard for encrypted but open WiFi developed? With passwordless public WiFi hotspots, it's easy to demonstrate that packets can be sniffed and (in the case of non-HTTPS traffic) private information gained. While the long-term solution would be to completely implement HTTPS and deprecate HTTP, why is there not a way to encrypt traffic? Traffic traveling through an SSH tunnel is encrypted, so why can the device not negotiate an encrypted transmission with the hotspot so that even HTTP traffic is unreadable? Does such a system/protocol exist, or why has no-one developed one?

There is at least one proposal for this: Opportunistic Wireless Encryption.

In this proposal, the WPA2 password is the same as the SSID, and automatically used by the connecting software.


TLS/SSL Offloading to PA220 without requiring clients to load additional CA If I'm understanding this correctly, the Palo Alto PA-220 allows for SSL/TLS traffic decryption using its proxy feature. By generating a Certificate Signing Request and loading it into the firewall, Clients should never receive a browser warning when accessing HTTPS sites?

You misunderstand how TLS works.
A certificate signing request is exactly what it sounds like: A request for a certificate authority to sign a certificate. The request alone is worth nothing. Compare that with the request to be released from prison, compared to a signed pardon letter.
As Z.T. pointed out in a comment, the requests needs to be signed from a certificate authority.
You have two ways of going about this:
For outgoing traffic
Your company should have an internal certificate authority, which is rolled out automatically to all clients using your endpoint management system. Then, the proxy can generate a private key and a CSR, and the IT department can sign the CSR with the private key of the internal certificate authority.
It is typically then configured that all outgoing traffic from employee hardware is rejected and required to pass through the proxy.
For incoming traffic
Since you mentioned that you don't want clients to install additional certificates, I assume what you want is to monitor incoming traffic. The proxy would then act as a reverse proxy, taking incoming traffic, inspecting it and forwarding it to the designated endpoint.
The setup is identical to that of your currently externally visible endpoint. You take the private key and certificate from that server and place it on your proxy. To the end-user's computer, this proxy is the endpoint. The TLS connection ends at the proxy, where the proxy can inspect the traffic.
The request must ultimately be forwarded to the endpoint (if deemed safe), and I recommend using an internal certificate for that, meaning you create a new TLS connection between the proxy and the endpoint. This has the advantage of making it harder for internal attackers to gather sensitive information from the communication between proxy and server.


CORS vulnerability or secure? Testing a website i am in this scenario, i found a CORS endpoint that allows any subdomains to access it, so for example:

Real request:

Origin: https://abc.realwebsite.com   --->
access-control-allow-origin: https://abc.realwebsite.com

but as it accepts every subdomain i am able to change it like this:

Modified request:

Origin: https:/mywebsite.com/hey.realwebsite.com   --->
access-control-allow-origin: https:/mywebsite.com/hey.realwebsite.com

Is it possible to exploit this? How would the origin header handle a directory instead of a domain? How can i reproduce this to make a proof that it is exploitable.

First thing: unless the CORS headers also allow credentials or are on a server that isn't supposed to be accessible from arbitrary IP addresses (or returns different content depending on the request source), this isn't really a vulnerability at all. If the browser cannot make authenticated requests (or at least not see the responses), then it can't do anything that the attacker couldn't do by just using curl on their own computer.

Next, the Origin header is only controlled by the browser, not the user. An attacker cannot cause a request to be sent with a custom origin, nor is there any circumstance where the browser would send an origin containing a path (protocol, port (if non-default), and domain only). As such, the server properly ought to be rejecting your requests as invalid, but what you've demonstrated is not exploitable in any way.


How can I encrypt compressed data safely? As mentioned in this particular answer, compressing data before encryption may lead to the CRIME attack, especially if the hacker has collected many similar versions of the transmitted data.

Let's use the following example for this particular security case:

Bob is using an encrypted personal diary program which is stored in a file which is encrypted using AES-256 in CBC mode with a SHA-256 HMAC (or AES-256 in GCM mode).

The journal compresses entry text using LZ or DEFLATE compression upon saving them.
The journal file structure is a fairly simple BSON tree (think JSON, but binary so no need to escape strings/etc.) which simply compresses the actual journal text upon file saving, but not the journal entry titles, dates, etc.

Bob stores this file in a Dropbox folder which is synced across his machines.
One of Bob's machines is compromised and Oscar now has access to his Dropbox account.
Oscar can download all history for the journal from Dropbox.

What is the main attack surface, if any, for Oscar? Does having compressed data in the encrypted journal file offer compromises which Oscar can exploit?

As far as I understand your scheme is not vulnerable to CRIME in the scenario you present, CRIME style attacks needing the attacker to be able to induce Bob to compress then encrypt material of his choosing, then being able to observe at the very least the size of the result.

However, if I was to attack your scheme, I'd target the part you left out : key generation and more generally key lifecycle.

If you generate your encryption key from a password, do you enforce strong password and do you use a good key derivation function, are you sure you e.g. don't lose entropy with some silly mistakes like playing with encoding or somehow normalizing the password?

Is the key randomly generated (it then begs the question, how good is your randomness source) then itself protected by another mechanism, and how strong is it?

You mention Bob machine being broken into, are you sure no key material is left behind? Do you lock key material in memory? Do you zero it properly once you are done with it? Do you avoid passing it on the command line?


In Snort for Windows, how do I limit log file size, keep that file, and make another file instance I have Snort for Windows.
I am trying to make a log file of say size limit 1MB.
When the log file hits the 1MB maximum, I want it to
close that file (snort.log.1234567890)
and open a new log file instance (snort.log.1234567891)
until that gets to the maximum,
then make another log file instance (snort.log.1234567892).
I should be able to take the now closed log files and read
them back in and analyze them, as Snort continues to make
new logs.

I tried to make such a size limit in the snort.conf file,
with the size 1 (and no nostamp), which should make a
unique snort.log.123456wxyz (timestamp extension).

I tried it to the snort.log.123..., the snort.alert.123...,
the tcpdump.123... but have not been successful.

The results are either no timestamp extension, or does not
limit the size to 1MB, and same file keeps growing and growing.

For snort3 you can do that by adding this line in the snort configuration file (snort.lua).

log_pcap = { limit = 1 }

Unfortunately, I haven't used snort 2 to tell you :(


Connection between "Security Requirements Engineering", "Risk Analysis" and "Threat Modeling" I am trying to figure out how the above concepts fit in together.
As i understood it Security Requirements Engineering (SRE), Risk Analysis (RA) and Threat Modeling (TM) are methods that ultimately allow an Information System to come closer to the desired security goals (CIA Triad, IAS Octave or whatever).

My question is, are they disjoint concepts that can be performed independently one from another, or is there a sort of hierarchy?

Would i be wrong to say, that SRE is the encompassing procedure, which can than contain RA, which in turn can use TM to determine threats?

Does anybody have good sources regarding the fundamentals of SRE and the concepts it includes?

A lot of confusing terms and language here. For correct information risk language, please consider FAIR, or Factor Analysis of Information Risk

The terminology "Threat modeling" was correctly replaced by Cigital with the term "Architectural Risk Analysis". Using `threat' here is especially incorrect.

Risk assessment (e.g., OCTAVE, OCTAVE Allegro) is also very different from Risk analysis. A risk assessment is a documented, point-in-time questionnaire at best. A risk analysis can be much more useful when the input variables are selected and formulated correctly. By "useful", I mean that they reflect reality closer to what a human can correlate and fit to normalized patterns.

Without invoking the book, "Software Security Engineering: A Guide for Project Managers", I can tell you that security requirements engineering, as you request, is not a clearly-defined problem to solve in cyber risk. Many document-heavy projects based on Waterfall or other lifecycle prescriptions were abandoned in Information Technology and Application Development circles in the late 1990s. Today, our practices and value chains are aligned towards Scrumban, the most-modern evolution of xp.

If you can follow the FAIR model, then you'll understand how information risk will fit into your organization. This exists outside of your business processes -- it's a standard language to communicate with the multitude of players who could show up to the cyber risk conversation. Threats, as in TCom and TCaps, are an important piece of the FAIR model, so you must quantify threats in order to quantify risk. You must also understand the business. If you identify a vulnerability, or a control-set issue, then you will want to elicit root cause. Root cause is never a patch -- it's always back to the business process, typically consequence management or even crisis management.

If you want to see how you can truly fit these pieces together, I suggest you do check out FAIR, but integration is key -- and OpenSAMM makes that integration cleaner than anything else I've seen. If you need a strategic map to forecast your future outputs (or collect the right input variables in the first place), then OWASP OpenSAMM can be fit to any cyber risk need. You'll see the correct language around "security requirements engineering", "threat assessment" (your risk analysis), "design review" (your threat modeling), and much more explicitly defined and explained within.


Is it a good idea to to use secure_hashing_function(mypassword.url) as my password? Like many users it's very difficult for me to use a different password for every website I have an account with. It does not matter how complex my password is if ONE naive website stored it in clear text.

Is it a good idea to use the salted hash of my password instead of my password?
The salt itself would be the url (or part of it) of the website I am visiting.

It's better than using a single password, but not much. If you have one site store the new password in clear, and if your hashing algorithm isn't strong, someone could notice that hash sitting in a list of otherwise clear text passwords and try breaking it. Assuming they know where they got the original list, if they find "passwordexample.com", they are going to be pretty confident that other passwords you have will be "passwordexample.org" and "passwordexample.net", hashed with whatever hash function you chose.

If you can remember a single strong password, which I'm assuming you can from the question, use a password manager. You can either use an offline one, such as Password Safe or Keepass, or a cloud based one. Either way, you can generate unique passwords for each site, and only have to remember one password yourself.

There are attacks against password manager apps, but they generally require either access to the machine which the app is currently running on, so assuming you don't leave your app open, are very unlikely in practice. Similarly, cloud based ones have been hacked before, but attackers don't appear to have been able to get access to the passwords stored in them.


Why the ARP entry of the router recover so quickly after ARP poisoning? I use Cain to ARP spoof my host and the router. Then I use arp -an to show the ARP entries on my host.  For a second or two, I can see the router's MAC address is changed to the address of the attacker, but it recovers to the router's valid MAC address immediately.  Both Linux and Windows 7 are installed on my host, both have the same phenomenon. I use wireshark to sniffer the packets, there's no packets sending from the router.  How to explain this?

Every time a host wants to communicate with another host on a local area network segment it must somehow determine its physical address (this is what a MAC address is, after all).

The process of physical address resolution occurs with the ARP protocol. This process consists of an exchange of ethernet frames in order to map logical addresses to physical addresses (most commonly, IP addresses to MAC addresses).

Now if this process happened every time 2 hosts wanted to exchange data on network segment, this would negatively impact the network performance -especially in cases where there is a large number of hosts that constantly communicate with each other.

To solve this problem, networked systems cache the physical address entries locally for a certain period of time. This way, each time a system wants to interact with another system on the local network, it looks up the physical-to-logical address mapping in a table stored in its memory. This is much, much faster than the address resolution process mentioned earlier.

The entries in the ARP cache are not permanent, though. They have a certain lifetime and once it expires they are refreshed again through a new ARP lookup. This method minimizes the global number of ARP lookups required for communication and at the same time keeps the logical-to-physical address mappings up-to-date.

In order to "preserve" an ARP Man-In-The-Middle situation, you need to constantly spoof the MAC addresses in order to keep them in the ARP caches of the targeted systems for the duration of the attack.

The lifetimes of ARP cache entries are implementation-dependent and vary from operating system to operating system.

You mentioned that you didn't see any "packets" in Wireshark, therefore I assume you were capturing IP traffic. The ARP look-ups occur on a lower level (Layer 2) and it uses ethernet frames and not IP packets for data exchange.


Generating x509 PEM files for testing PEM parser I need to test a parser of PEM formatted certificates. Thus, I need to generate many variations including variations that are invalid for various reasons. Obviously I can use openssl or a library like Bouncy Castle to create valid certificates, but what about forcing errors? Can anyone point me to tools that can help?

More specifically, the kinds of errors I want to be able to generate are primarily
valid PEM files that parse to the DER structure, but the DER is invalid in some way. Such as bad length values, undefined tag values, incorrect version, invalid signature, etc... Of secondary interest to me (at least right now) are corrupted PEM files and PEM files of something that isn't a DER cert.

A few attempts I made at making bad X.509 certs using phpseclib, a pure PHP X.509 parser.

Adding random characters at the end of a SEQUENCE:

http://pastebin.com/5Jcy0d90

Replace the RSA / DSA part of an X509 cert with another X509 cert:

http://pastebin.com/570bR2jz

A cert with the same extension multiple times:

http://pastebin.com/acmcXbAg

Invalid OID:

http://pastebin.com/3svVQyP3

A bazillion nested SEQUENCEs:

http://pastebin.com/fKw6XAEp

Non-constructed sequences:

http://pastebin.com/kpajfQyD

Having a signature that doesn't match the signature algorithm:

http://pastebin.com/GAED5xQe

To get that last one working you'll need to do http://pastebin.com/Dq2XAAGG to get it working.


Can a malicious SSH server successfully *pretend* to know a client's public key? Yes, I know that after giving an SSH public key to someone else, one should always assume that it might have been swiftly published somewhere. (For instance, give your SSH public key to GitHub, and GitHub will publish it. E.g. presumably this one belongs to @Jeff Atwood, aka Coding Horror.) This question is about an exception to that general rule.

Suppose:

SSH client C is attempting to log in to an SSH server S for the first time, as user u, via public-key authentication;
C does not know S's SSH public key fingerprint (i.e. the host key fingerprint);
S has a copy of C's public key in /home/u/.ssh/authorized_keys;
nobody but C and S know C's public key;
M is a malicious server identical to S in all respects (e.g. equally as capable as S is of presenting itself to C at the IP address where C expects to find S), except that M does not know C's public key.

Question: Can C distinguish between M and S?

So if the client has no knowledge of the servers public key, and no authority to verify anything, then there is no way to distinguish between the authentic server and a malicious server. Because the malicious server would just generate a new private  public key pair and provide the matching public key to the client and all the match would check out.

However the premise of the attack " equally as capable as S is of presenting itself to C at the IP address where C expects to find S" is unreasonable because every hope would need to be working together to incorrectly route to the wrong ipaddress so the malicious server could manipulate the packets without breaking the tunnel. Not impossible but definitely an edge case.


Is it secure to use HMAC to pass a string to be verified? I am working on a Django project and trying to create a REST API to verify email without using any database. My present server connection is HTTP and not HTTPS.

So someone using the API end point POST his email:

REQUEST:

curl --location --request POST 'http://127.0.0.1:8000/api/openlogin' \
--header 'Content-Type: application/json' \
--data-raw '{
"email":"test13@test.com",
}'

Now I am generating a random 6 digit number, eg. 435667, and an email will be sent to test13@test.com:

send_mail('PIN TO VERIFY','ENTER THE PIN 435667',None,[test13@test.com])

The HMAC value of 435667 is sent as a response to the API call:

    raw = '435667'.encode("utf-8")
    key = 'SOME_SECRET_KEY'.encode('utf-8')
    hashed = hmac.new(key, raw, hashlib.sha1)
    pin_hmac_hash = base64.encodebytes(hashed.digest()).decode('utf-8')
    eg: pin_hmac_hash = "SOME_HMAC_HASH_OF_PIN"

So the response for /api/openlogin will be:

{
'email': 'test13@test.com'
'pin': "SOME_HMAC_HASH_OF_PIN"
}

Now the user sends me back the PIN along with the HMAC hash in the response:

curl --location --request POST 'http://127.0.0.1:8000/api/verifypin' \
--header 'Content-Type: application/json' \
--data-raw '{
'pin': "SOME_HMAC_HASH_OF_PIN",
'email': 'test13@test.com',
'emailed_pin':'435667'
}'

Could someone guess the PIN from SOME_HMAC_HASH_OF_PIN?

Of course I will further try to autenticate the API using JWT token. So the email cannot be tampered.

This is an example of PIN but it can be any string of sensitive information. Can I rely on HMAC?

It sounds like what you are wanting to implement is a signed URL, similar to Amazon S3 URLs. As long as your secret is strong and secure it sounds like a reasonable way to verify the email address in a stateless fashion.

At the moment you are only signing/hasing the PIN and this is an issue with your code. If I get a valid PIN/PIN_HASH combination for email address A from your service, I could still submit this valid combination with a new email address B and it would pass your verification test.

I would suggest a slightly different solution. Use a timestamp instead of the PIN and use it as an expirey date.

created_at = int(round(time.time() * 1000))
payload = email + "-" + created_at
hashed = hmac.new(key, payload, hashlib.sha1)

Then send the created time back to the server instead of the pin. This allows you, after you verified that the hmac signature is correct, to also check how old this request is and reject it if it is older than x minutes.

This still leaves you vulnerable to replay attacks within the time frame, which might be ok, if you check that the user does not exist yet and reject the api call if they do.

PS: without https you are still at risk that someone intercepts and steals this information before it hits your server. I would strongly suggest to use https (LetsEncrypt certificates are free and easy to get)