Integrate PHP and WebSocket authentication securely I have a PHP server that runs a website, and the website has features such as live notifications, which are basically notifications that get sent to you once a user likes or comments on one of your posts, live.

I decided to use WebSocket for this, just for practice.
To use WebSocket, I need to authenticate the user and use his information in order to get and deliver data to other connected users.

Stage one

I know that PHP gets the session id of the logged in user from the cookies, and uses that ID to retrieve his session file, which holds his user id.

I thought of saving the session id in a database, linked to the user id, and then when the websocket connection initializes, I send the cookie session id and then the websocket server checks the sent ID from the database.

Stage two

If you like or comment on a post,  you need some kind of a service that handles it, whether if you can like or comment, and what it does when you try to do that, and in my opinion that logic should be done on the web server, on the PHP project.

What I thought of doing is first sending an XMLHttpRequest when you like or comment on a post, and that request returns status, if it succeeds or fails. If it succeeds, then the response will contain the ID of the post or like, and it will be sent over to the websocket server, and the server will notify all users after verifying that it's real.

Can you find any flaws in one of these stages? Am I thinking the right way?

[...] if you can like or comment, and what it does when you try to do that, and in my opinion that logic should be done on the web server, on the PHP project.

Oh absolutely. Otherwise you would implement the checks on client side, in which case the web application decides, whether the user is allowed to comment/like a given post. You can do that but implementent server-side checks too! Otherwise nothing prevents me from pretending to be another user and sending the request directly without using your web app. Client-side checks should never be used as the only safety measure.

I'd also implement some sort of one-connection-per-user policy. In case somebody steals/guesses the users session ID, he/she can establish a websocket connection and maybe even use your other endpoints (depending on how they are authenticated). This is a weak spot, as your websocket connection can be established (and other endpoint can be used) by just throwing a valid session ID at your server (regardless of username/password in your scenario!). Make sure sessions time out after X minutes and session IDs are way harder to guess than password (i.e. using a cryptographic hash function or a safe random number generator).

Allowing only one Websocket for each session ID (and only one active session per user?) prevents an attacker from hijacking an actively used session unnoticed.

As usual "don't roll your own crypto" (if you think about using it as production software). As you already mentioned that "PHP gets the user data from the session ID", I assume you're using some sort of framework, as PHP does not do this on its own. Maybe the authentication functionallity is already implemented.

tl;dr

Implement all security checks at least on server-side (client-side is User Experience, not security)
Make sure that guessing session IDs in not feasible. This includes cleaning up sessions which are no longer in use. Maybe a policy enforcing one session per user and one websocket connection per session if it fits your use case. So nobody can hijack a session unnoticed.


Is there a method to detect an active man-in-the-middle? Suposing an attacker that has gained access to the router. Is there a way, for the victim, to notice that is being attacked?

I think one of my friends is a victim of this kind of attack. How can I be sure that this is the attack that is being performed over him?

More details: Someone is changing constantly his passwords of facebook etc.

There are multiple 'tells' your friend might pick up on if he is a victim of a mitm vector.

Is your friends connection slower then usual?
Is the facebook page exactly like the one he sees at work, school, etc?(compare source)
Ettercap has a few modes designed to detect a mitm attack that your friend can make use of.

None of the above methods are fool proof, but together they build a picture of possible side effects.
Your friend can bypass a dns_spoof by navigating to facebook by its ip (66.220.149.88) and us a vpn tunnel (tor is free but slow)

Having said all this, it is unlikely that your friend is a victim to a mitm attack. It is extremely probable their machine is infected with keyloggers.
Have your friend run a virus scan, clean them out and then check all facebook security settings.

Also, if your friend uses yahoo have them switch to gmail.


With the recent denouncing of SHA-1 by Google, should SHA-1 based PBDKF2 now be avoided? Google recently announced "the first practical technique for generating a collision" for SHA-1. I'm currently planning a password hashing implementation for a website, and historically we have used PBKDF2 as that's the default tool on our framework of choice - .NET.

They've specifically condemned SHA-1 for TLS certificates, but does this condemnation still apply to password hashing for websites? Is PBKDF2 no longer a safe pick given this revelation?

The use of SHA-1 inside PBKDF2 or other password hashing methods is not affected by the collision attack shown by Google. In functions like PBKDF2 it is important that the used hash can not simply be reversed, i.e. it is not possible to construct the input from a given output (preimage attack) and thus not reconstruct the password based on exfiltrated password "hashes" in case of a hacked system. Apart from that SHA-1 is used in several thousand iterations inside a single run of PBKDF2 which further makes it harder for the attacker even if he has some kind of (probably very slow) preimage attack against SHA-1.


How to capture a TLS resumption traffic using Wireshark? I'd like to capture the TLS resumption traffic using Wireshark. The traffic is recorded while I open a connection in a tab, close it and then re-enter the url and load again. I've noticed two traffic patterns. One is full handshake. However, the other doesn't seem like a TLS resumption. Any any expert help to confirm it or suggest a correct way to obtain resumption traffic? Thanks.
The screenshot below shows a full handshake

This is another pattern. Can this be TLS resumption pattern? However, it's not like the normal resumption handshake as described in some document

...normal resumption handshake as described in some document...

It is unclear what some document you are referring to is and what you consider normal. Session resumption can be done with either session id or session ticket. While your capture shows that no session id was used there is nothing known or shown about the use of session tickets. Therefore my guess is that you did not know about session ticket and thus did not look for it.

Also, given that the ClientHello you show in the screenshots have the same random bytes it is likely that both screenshots actually show the same ClientHello (i.e. either from first or from second, don't know) which makes analysis based on your screenshots hard.


Host header attacks: Possible exploits We have an API server hosted with amazon elb. The server has only one virtual host and hence it doesn't enforce Host header. But if we manually add a Host header along with the request with a valid host name, the server returns a success.

Is there any possibilities by which this can be exploited in general?
Is it usually recommended to use a Host header with every request?

I would say this is not a vulnerability in itself, but enables the exploitation of other vulnerabilities.

Recently an attack was published for Wordpress that depended on the site being available independent of the value of the Host header.

Attacker requests a password reset with Host header set to attacker-controlled domain: Host: attacker.com.
Wordpress sends a password reset token to the email address of the user, with the sender set to wordpress@attacker.com.
If this email bounces or is replied to, the attacker receives the token on wordpress@attacker.com.

Edit: a DNS rebinding attack also only works if the web site ignores the host header. It works like this:

A user visits attacker.com.
The attacker changes the DNS entry for attacker.com to point to your amazon elb server.
The page on attacker.com does a HTTP request using Javascript to attacker.com. This is permitted according to the same-origin policy, but since the DNS has changed it is actually a cross origin request.


Are there any standard practices for protecting against malicious links being entered in a public form? A website I'm working on needs to have a form for any visitor to submit a request for information about a service. The user will not need to create an account, and contact details are just part of the form. The user can also enter a free form message. This information is to be forwarded to someone non-technical who will contact them about buying services. (So yes, this is pretty much marketing stuff.)

My concern is that the user could enter something malicious. Obviously, I can do some things to mitigate if they try to enter HTML or JavaScript (e.g., escaping the content), but what if they just enter a URL? Some e-mail clients (e.g., Outlook) automatically convert URLs into clickable links even if the e-mail was sent as plain text. Is there any standard technical practice I can implement to protect the recipient of this info from blindly clicking it and winding up on a malicious site? Or do I have to rely on the user's Junk Mail filter and judgement (possibly augmented with training)?

A point of clarification: this app is being built as contract work, so we have pretty much no control over the e-mail systems of the people who would receive these requests.

Before the email is sent, you can grab all URLs with a regexp, and then submit them to Googles Safe Browsing API to check if they are known to be malicious. If so, just don't send the email or include a warning.


How WPA supplicant can determine whether switch supports authentication or not? If a client(supplicant) configure to perform EAP-TLS authentication connects with a switch which doesn't requires authentication.

How can supplicant determine that authentication is not required and go ahead without authentication?

This can be done in two ways, based on whether machine IP is statically configured or dynamically configured.

If machine is  configured for DHCP than a client can initiate the DHCP DISCOVER and wait for response from switch (authenticator). If a DHCP offer is received at client side than switch doesn't supports authentication and client can go ahead with further communication. If authentication is supported then switch will trigger the EAP request (identity) to the client (supplicant), so that the client can complete authentication. This can delay authentication by a few seconds depending upon the how fast switch sends EAP request on getting DHCP packets.

In case of statically configured IP, either a server can be configured so client server can communicate to check whether they have IP connectivity or not. For this approach, we need to make sure availability of the server. Alternatively, a client can send EAPOL start and wait for 30 seconds to check whether the switch asks for EAP request(identity) or not.


Store SQL database credentials in a webserver I'm trying to make a connection to an SQL server in php. Is it safe to just put the database credentials in plaintext in the .php file? Can a user edit the php code in a a .php page and change the way an input is handled?

The best way to enter database credentials is creating the config page(.config) and store the values in it.
No the user cannot view the file unless he has administrator privilages to the sql server


Are ECB and CBC modes of operation generally insecure? In some Java code that I'm reading, I stumbled over the following encryption algorithms passed to the Cipher.getInstance(...) method:

AES/CBC/PKCS5Padding
DESede/ECB/PKCS5Padding
RSA/ECB/PKCS1Padding

Note: In the Java model, the first substring represents the cipher, the second the mode of operation, and the third the padding scheme.

Now, I believe that ECB is generally insecure (independently of the used cipher / padding scheme), because it preserves the structure of the plaintext.

In addition, I also read that CBC can be insecure, depending on the implementation. More precisely, if the implementation is written in such a way that it is revealed whether some given ciphertext was correctly padded or not, then this can be exploited to decrypt encrypted messages. In the case of Java, the problem is that different platforms / Java implementations / crypto providers are available, so it's hard to tell in general whether using CBC as a mode of operation is fine.

That leads me to think that all three of the above algorithms are potentially insecure. But perhaps I'm overestimating the problems of ECB / CBC, and they can be used in a secure way?

Hence the question: Can/Should the above algorithms be considered as secure or not, and why?

Update: To provide some more context, the code I'm referring to is the OWASP Benchmark. This benchmark consists of thousands of test cases, some of which intentionally contain actual vulnerabilities, while others intentionally contain "fake" vulnerabilities (i.e., code that looks like it might be vulnerable but actually isn't). Some of the test cases labeled as "fake vulnerabilities" encrypt some text using one of the three algorithms mentioned above. Since OWASP considers these as "fake vulnerabilities", that implies that OWASP considers these algorithms as safe, which surprised me. I'm wondering whether OWASP is right in considering these algorithms as safe, or whether these test cases in the OWASP Benchmark really ought to be labeled as "actual vulnerabilities" rather than "fake vulnerabilities".

An example of such a "fake vulnerability" test case in the OWASP Benchmark is the test case 54, which encrypts some data using AES/CBC/PKCS5Padding, but is labeled as not being vulnerable to CWE 327: Use of a Broken or Risky Cryptographic Algorithm.

DESede/ECB/PKCS5Padding

DES is already broken and TDES is created to use until a new cipher is developed, called now AES.
The block size of DES or TDES is 64-bit and this is insecure, see Sweet32.
ECB mode for block ciphers, forget about it. It is not even a mode of operation. It reveals a pattern in your data. See the penguin on Wikipedia. In some case you may need it like equality queries in DB, however, it still can leak information, see How can frequency analysis be applied to modern ciphers?
PKCS5Padding See in the next section.

  AES/CBC/PKCS5Padding

AES is a block cipher and is supposed to be a pseudorandom permutation. It can achieve IND-CPA or IND-CCA or authenticated encryption using AES, by using the appropriate mode of operation together with AES. It is still secure after more than 20 years
CBC mode requires an IV and that not only unique but also must be unpredictable
PKCS5Padding is vulnerable to padding oracle attacks. Actually Encrypt -than-MAC can solve this issue.

  RSA/ECB/PKCS1Padding

RSA is not mean to encryption. It can be used for signatures with PSS padding or Key encapsulation mechanism like RSA-KEM with Data Encapsulation Mechanism. Composition of a KEM and a DEM provides the standard of IND-CCA2/NM-CCA2—ciphertext indistinguishability and non-malleability under adaptive chosen-ciphertext attack if an authenticated encryption mode is used like AES-GCM, ChaCha20-Poly1305, or crypto_secretbox_xsalsa20poly1305
ECB has no meaning here. It doesn't implement ECB. None is better here.
Here the PKCS1Padding indicates RSA with PKCS#1 v1.5 padding for encryption. There are at least 8-byte makes this padding probabilistic, i.e. if you encrypt the same text you will get a different ciphertext.

Using RSA PKCS#1 v1.5 encryption securely is hard and one should not be used to. There are Bleichenbacher's attack and its variants on PKCS#1 v1.5 padding. Also, there is no security proof of it, but Optimal Asymmetric Encryption Padding (OAEP) has been proven secure in the random oracle model. If you want to encrypt you should OAEP it, but better not to use it. Prefer the Hybrid Encryption.

Short conclusion

None of the above-listed modes is preferred today. In TLS 1.3 now we have only authenticated encryption modes.

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256

CBC, gone, TDES no more, all static RSA and Diffie-Hellman suites are removed.

Stay with the recommendations. In modern Cryptography we want

IND-CCA2/NM-CCA2—ciphertext indistinguishability and non-malleability under adaptive chosen-ciphertext attack

Therefore you need authenticated encryption modes.


What is the following regex trying to protect against? I am looking at a Java web application that compares all incoming request params and cookies against the following regex. If it matches, it is considered "an attack" and refuses the request. I'm guessing it's trying to prevent SQL injection / class loading or something, but I'm not sure. Can anyone help?

(.*\.|^|.*|\[('|"))(c|C)lass(\.|('|")]|\[).*

I'll take a guess... parsing the regular expression, it appears to be matching:

Anything (optional)
. OR ^ OR anything OR [
Quote (single or double)
The literal string class (case insensitive for the c only)
. OR quote (single or double)
] OR [
Anything (optional)

I'm not 100% sure on this.  Sometimes the precedence rules are tricky, and I can't easily test this in java to see exactly how it behaves.

In general though, I find that breaking out the regular expression doesn't shed a lot of light!  Certainly, it's not a very helpful rule.  It seems to mainly be focused on finding instances of class, but it only does a case insensitive search on the c, so you could easily bypass this rule with clAss.

Given the search for class and quotes, I would guess that this is aiming to find an XSS payload (perhaps someone tried to inject something into the class parameter on a tag).  However, it's hard to say for sure.  Given that this appears to be a very poorly executed WAF rule anyway (for instance not properly checking in a case-insensitive way, and a few other minor details), I doubt the person who wrote this rule really knew what they were doing, which might make devising their intent much trickier.


Can the wifi administrator in a shared office see mail sent through outlook? I am hot desking in the same office as a potential competitor & would be using the same wifi. The building owner runs the competitor company.

My question is, can the wifi administrator see mail I have sent through outlook (via Google apps) when using my personal machine? Concerned about email content but also the actual recipients email address as would rather they did not know the companies I was working with. Would the recipient email be visible?

If yes, is there anyway to protect myself?

Assuming the "WiFi administrator" only has access to the network, and isn't actively trying to attack you, I think your email is safe if properly configured.

Because they control the network, they can see all the traffic that crosses it. This would be a problem for unencrypted connections (e.g. HTTP traffic, or unencrypted POP or SMTP traffic).

However, the Google Apps Sync for Microsoft Outlook plugin specifies port 443 needs to be open for communications, and port 80 needs to be open so it can receive a certificate revocation list. This strongly indicates that TLS or some similar form of certificate based encryption is in use.

If you're using IMAP/POP/SMTP settings instead, the help page indicates that they can be configured to use encryption.

  Incoming Mail (IMAP) Server - Requires SSL

imap.gmail.com
Port: 993
Requires SSL:Yes

  Outgoing Mail (SMTP) Server - Requires TLS

smtp.gmail.com
Port: 465 or 587
Requires SSL: Yes
Requires authentication: Yes
Use same settings as incoming mail server

Therefore, if you have configured Outlook properly on your computers, the WiFi administrator won't be able to see your email content or recipients. They can only see encrypted blobs (essentially random noise).


Vulnerable CRLF environment I'm looking for a vulnerable CRLF environment. So far I've tested PHP and JSP.

In PHP 5.6, header gives you a warning if you try to insert a newline:

<b>Warning</b>:  Header may not contain more than a single header, new line detected in

In Java 1.8 + Tomcat 7.0.78, response.setHeader replaces the \r\n symbols with spaces.

So, starting from which version did Java and PHP fix the CRLF vulnerability?

PHP - 4.2.1 - CVE - Or see the Anders answer.
TOMCAT - Before 6.0.37 / 7.0.30 - CVE

Since CRLF Injection is directly related to HTTP response splitting attacks, I recommend you to read the question I asked, here. The answer was above my expectation.

EDIT

For some reasons, I needed to test some PHP header injections today. @Anders is right, the exploit I linked in the CVE is much more difficult to execute than the exploit stated in his answer below.


How to secure MySQL data from changes? I'm looking for a way to secure MySQL data in particular tables for example settings table.
Ideal solution would hook up to database and log all INSERT, UPDATE and DELETE requests to particular tables, preferably on low level.

I believe on one of INFOSEC events there was some solutions that allowed to monitor requests to database server and trigger various actions, but I don't remember names of those solutions.

you can create additional users with different privileges for different tables

see the following for a better explanation:
https://stackoverflow.com/questions/6288554/mysql-grant-all-privileges-to-database-except-one-table

doing this would mean you could create a user able to insert/update/delete all other tables apart from the settings (or other tables).

I hope this helps :)


How to acquire DNSSEC root trust anchor from IANA? I want to establish trust in a DNSSEC record. I found, that it can be done

$ dig +sigchase +trusted-key=./root.key @8.8.8.8 eesti.ee

root.key could be obtained with

$ dig . DNSKEY @8.8.8.8 | grep -Ev '^($|;)' > root.keys

however, this would be insecure and suspectible to mitm attacks.

I believe that IANA publishes the root key on https://www.iana.org/dnssec/files (where it is signed with HTTPS, PGP, etc.), but it is in XML format and I failed to use it with dig.

How to convert it from XML to same format as root.keys ?

You can download the Root Zone file on the IANA website (HTTPS). This file contains the root keys you need. You can use grep to get the DNSKEY.

$ curl -s https://www.internic.net/domain/root.zone | grep "^\.\s\+[0-9]\+\s\+IN\s\+DNSKEY" > root.keys

$ dig +sigchase +trusted-key=./root.keys @8.8.8.8 eesti.ee


Is string concatenation vulnerable to null character in aspx? I just see this line of code in VB in one file .aspx

FileUpload.SaveAs(sPath & "/" & FileUpload.FileName)

This line save a file that an user uploaded. It use the SaveAs method. I was worried about the sPath because the user can edit it.

The user can only save image, so it check the filename extension. I thought someone can use a null character to save another file, like:

/path/evil.aspx0x00/image.jpg

Fortunately, this don't work. But is there another way to manipulate? Can someone send another way of null character?

-- Edit

As far I know, I list this types of null character

0x00
%00
/0
/x0
&#0;
&#x0;

There is more?

--Edit 2

Lol, this list give more types of null character

In a file upload mechanism a few things should always be considered to be checked, basic checking on file extensions only is not sufficient enough in my opinion.

File header checking: Read the first few bytes of the file and determine if it is an image or not.
Convert the image: If step 1 is successful, convert the image to a format other than the uploaded format. This is to delete possible malicious code in images.

As far as your question regarding nullbyte injection: Besides 0x00, %00 can also be used in file names, for example:

/path/evil.aspx%00.jpg

I doubt this will work in ASPX but depends on your configuration.


Ruby Devise salt exposed The remember_user_token cookie token generated by the Ruby Devise authentication component reveals part of a bcrypt salted credential when decoded.

For example:
remember_user_token=W1sxNF0sIiQyYSQxMSRtSHhGeWd3VkFNdzdxd3VmUE04MWdPIiwiMTUyMTA4NjEzMy4wOTU3Il0%3D--96341f2abb8e9fa777d9ad5199b2231f3d22e1d7

Decodes to:

[[14],"$2a$11$mHxFygwVAMw7qwufPM81gO","1521086133.0957"]

The second part of this tuple is the bcrypt cred up to the salt.
As the hashed password portion is omitted, I believe recovering the password would not be feasible. However, this does not seem like good practice and I am not clear on why this function has been designed to reveal even a part of the user's hashed credentials.

What are some scenarios where this information may help an attacker gain unauthorised access to the application?

Source code below:

http://www.rubydoc.info/github/plataformatec/devise/Devise%2FModels%2FRememberable%2FClassMethods%3Aserialize_into_cookie

http://www.rubydoc.info/github/plataformatec/devise/Devise/Models/Rememberable#rememberable_value-instance_method

The "rememberable" Devise strategy is used to re-authenticate a user from the value stored in a persistent cookie (the remember_user_token that you decoded) with the following format:

[[<user_id>], "<user_salt>", "<cookie_generated_at_UTC_time>"]]

The cookie is signed to prevent tampering of the cookie values (the signature is the blob you can find after the "--" in the cookie).

The application you are testing uses the default implementation of "rememberable", which does away with the need of having a database column to store the per-user "remember tokens"; instead it uses the user id + password salt as the key to uniquely identify the user. When the application receives back the signed id+salt cookie, it looks up a user with the matching id and if the salt matches that of the cookie, it successfully authenticates the user and continues the processing.

The use of the salt as unique identifier avoids having to store "remember tokens" on the server side; as a trade-off it reveals the salt. Giving an attacker access to the bcrypt salt without the actual hashed password is useless (the salt is only used to avoid pre-computed hash attacks, forcing an attacker to bruteforce each hashed secret separately). If an attacker gains access to the user password they will also get access to the salt, so the security of the "rememberable" strategy is not compromised by the sharing the salt.

I would personally be more concerned by the sharing of the user ID (the first field in the cookie), e.g. it may be later re-used in direct object reference attacks.

If you are not comfortable exposing the user password salt you can implement your own remember_token method in your Devise user class, see the rememberable model, e.g. for instance creating random tokens and storing them on the user database table.


Is this key exchange algorithm secure and valid? I'm writing reliable UDP implementation and I want it to be secure. Also, I want to make use of elliptic curve cryptography. I don't have the proper education to really understand the math behind this kind of cryptography, but I understand how to use it (at least in general).

Given the next preconditions, is this algorithm secure? What steps can be skipped without compromising security?

(opt.) Is it ok for parties to use a single ECDSA key pair for all interactions in a long period of time? I mean do not change this key pair at all and use it to sign any messages.

Preconditions

Interaction is going between two parties A and B
Both A and B have predefined ECDSA key pair
Digital signature also works like a hash

Algorithm

A computes and sends to B her epheremal ECDH public key
B computes the shared epheremal ECDH secret and hashes it with SHA-256, using the key A sent her in step 1
B randomly generates 256-bit static encryption key
B encrypts her ECDSA public key and the static encryption key from step 3 using the epheremal secret from step 2 with AES-256 algorithm
B signs the result from step 4 with her ECDSA private key
B sends to A the result from step 4 alongside with the signature from step 5 and her epheremal ECDH public key
A also computes the shared epheremal ECDH secret and hashes it with SHA-256, using the key B sent her in step 6
A decrypts the result from step 4 using epheremal key from step 7 with AES-256 algorithm
A checks the signature B sent her in step 6 using B's ECDSA public key she received in step 8

If something goes wrong (the signature is invalid or step 8 lead to corrupted data), A gives up
At this point, A has everything she needs to send messages securely

A signs and encrypts her ECDSA public key using AES-256 algorithm with the static encryption key she received in step 8

A can also sign and encrypt some payload in this step

A sends to B the result from step 11 with the signature
B decrypts the ciphertext A sent her using AES-256 algorithm and checks the signature

If here something goes wrong, B gives up

Now both A and B know ECDSA public keys of each other and the shared encryption key, so they can interact securely and be sure nobody can modify their messages

Disclaimer: this is an answer for why this question is too broad. I am not attempting to actually answer the question because that would be, well, too broad.

In comments, you said:

  I think that my question really belongs here and not in cryptography section because it contains nothing about custom techniques and algorithms. The key exchange scheme I suggest is really very likely TLS, but simpler. I want to know if this simplification I made is correct in general.

But, in fact, you are creating a custom technique. Everything in TLS is there for a reason. Believe me, the TLS people are obsessed with efficiency, especially with TLS 1.3; if they could remove something from TLS to make it simpler, they would. Designing a secure cryptographic protocol (that is, a protocol that makes use of cryptographic algorithms) is hard.

For example:

TLS 1.2 is listed as having 25 authors and went through 10 revisions over 2 years.
TLS 1.3 is listed as having 92 authors and went through 28 revisions over 4 years.

It is not easy to build a handshake protocol like TLS and build it properly.

The fact that you think your question is simple enough to ask on stack exchange, tells me that you should not be asking it at all.

I strongly suggest that you find a well-known implementation of a well-known protocol (like (D)TLS, IPSEC, etc), and use that, rather than trying to invent your own cryptographic protocol


Storing TOTP secret in database, plaintext or encrypted? I've been reading about 2FA and how it is used, and the thing that struck me most is that everyone seems to be storing the TOTP secret as plaintext in their database.

I understand you need the secret as plaintext in order to verify the OTP, so you can't hash it, but couldn't you at least encrypt it in a certain way, in case your database gets leaked? I feel like there are ways to make this a bit more secure but I'm wondering if there are downfalls to the ideas I have.

Encrypt the TOTP secret using key stored on the server: This wouldn't be ideal since you'd be encrypting everything with the same key, but a database can be leaked without the attacker having full access to all files on the server. In that scenario, at least the TOTP secrets are still protected.
Encrypt the TOTP secret using the user password: When the user logs in and the password hash check is valid, the same password that was sent could be used as a key to encrypt/decrypt the TOTP secret. When the user first sets up his 2FA, you require that they enter their password so we can use it to encrypt the TOTP secret. When they login with a correct password, you decrypt the TOTP secret using the password, and you validate the OTP. If your database is leaked, password is hashed and TOTP secret is encrypted, so the attacker has no information on any account unless they know the password.
Combine both methods: Combine the password with a locally stored key, and use this as the encryption key for the TOTP secret. This way, if the database is leaked and the attacker knows the password, they still can't decrypt the TOTP secret unless they have access to the stored key

Are there any flaws in this, and if so, what are they? I feel like anything would be better than just storing the TOTP as plaintext.

Where have you been reading about 2FA and why do you assume that everyone stores the secret keys in plain text?

As you are talking of TOTP you should probably read RFC4226 and RFC6238.

Yes, e.g. the Google PAM module stores secrets in plain text in the users home directory. But please note: The HOTP algorithm was published in 2005, the iPhone 1 was published in 2007. We can simply deduce that the HOTP algorithm was not ment for smartphones - neither the TOTP algorithm, which was published even later.

The problem with encryption or plain text gets immanent, if you are using HOTP/TOTP to authenticate on a local machine. But the OTP algorithms are designed to be used with a trusted backend system. A local machine of course can not be trusted, as an attacker might sit in front of this very machine.

Take a look at section 7.5 Management of Shared Secrets, RFC4226:

Here it is recommend to encrypt the shared secrets, just like you suggested in #1. And of course if someone gets the encryption key, the authentication is useless. But this is a backend system, you need to protect.
E.g. our (disclaimer!) open source software privacyIDEA actually encrypts the shared secrets and if you want to even with a hardware security module. (Again - this is a backend system)

You might also want to read a bit more about the flaws of the Google Authenticator design: https://netknights.it/en/the-problem-with-the-google-authenticator/


What OpenSSL v1.1.1g Commands Require A Configuration File? It's my understanding that the OpenSSL v1.1.1g commands ca and req require sections to be present in an OpenSSL configuration file in order to operate.  Are there any other OpenSSL v1.1.1g commands that require a section to be present in a configuration file in order to operate?

A quick grep through the man pages shows the following:
$ zgrep -l "\-config" /usr/share/man/man1/openssl*.gz
/usr/share/man/man1/openssl.1ssl.gz
/usr/share/man/man1/openssl-ca.1ssl.gz
/usr/share/man/man1/openssl-req.1ssl.gz
/usr/share/man/man1/openssl-srp.1ssl.gz
/usr/share/man/man1/openssl-ts.1ssl.gz

This means the following commands:

openssl: just mentions the fact that some sub-commands accept a config file
ca: you're already aware of it
req: you're already aware of it
srp: maintain SRP password file: see wiki
ts: Time Stamping Authority command: a related PKI utility to obtain timestamped signatures.

Note that they do not necessarily require a config file, just that one can be used.


Are SAN SSL certificates a possible avenue for security compromise? When looking to purchase an SSL certificate recently I noticed that this vendor was offering subject alternative names (SANs) certificates. When you look at the cert details you can see that all of the extra domains that a cert authenticates.

Surely this is information leakage allowing a would-be hacker to glean more information about your organisation than you intend?

Also, does it not complicate any possible revocation scenarios in that if one host is compromised then they'll all need to be changed?

Also, does it not complicate any possible revocation scenarios in that if one host is compromised then they'll all need to be changed?

When the private key (for which the certificate is associated) is compromised, then the certificate(s) for that key are revoked.

Whether or not the certificate applies to a single domain, many Subject Alternative Names (SAN), or is a Wildcard certificate; it is still a single certificate and does not complicate the revocation process.

And supposing there are other certificates for the same domain(s), if they are from different uncomprimised private keys, then those will not be affected by revocation of the aforementioned certificate. Domain name overlap notwithstanding.

  Surely this is information leakage allowing a would-be hacker to glean more information about your organisation than you intend?

It is quite possible that a SAN will list a subdomain that could not be found otherwise except by Brute Force, I think in this particular case, these subdomains are probably easily found by other means.

Even if they were intended to be secret, software designers should not rely on the secrecy of their hostname. This is stored in browser history, synced to the cloud, and likely emailed to co-workers.

So the fact that SAN lists these domains might save an attacker some time in finding subdomains, publication of this information is not considered a vulnerability.

The real risk for vulnerability would be in the application, and that is where the security focus should be.


Malicious code in image. Harmful? In my website, a user can upload his profile picture. After analysis of some pictures, I have found some pictures with malicious PHP code, just like the upload script. As an example, I have found a single line code of PHP:

<?php echo $_GET['a']; ?>

So by using this code, if he can upload this picture as a .php file, such as picture.php, then he can run this script by doing something like url/pictur.php?a=[anything]. But the picture can't be uploaded as .php extension since all picture extensions are automatically changed to .jpg. Additionally, I never include the picture by php function include. Rather, I always add image with html img tag.

I know that the best practice to stop malicious people is to resize image. Is it possible for a  malicious person to harm with this kind of image?

While you may never run the code locally on your server, it may be possible to upload malicious JavaScript code. Then the attacker can point to your site when he needs to reference the code in other attacks (e.g., XSS). There may also be rare situations where PHP or other server side code may be consumed from this image.

There may be misconfigurations in your server or the attacker may just upload the attack image wherever hoping for some kind of include() of eval() to take place.

e.g., see this example (from 2008, but some attacks may still work on outdatted webservers - I recommend reading through the rest of the thread for interesting concepts):

  If the server changes the extension to .JPG/.GIF (or only allows those
  extensions), then you need to be more creative. On Apache, you can
  name a  file something.php.jpg, and Apache will still treat it as PHP.

  Another option you can try is by sending an upload request (with a
  tool or  a HTTP request editor) that embeds a NULL byte before the
  .JPG extension.  ASP scripts tend to be vulnerable to this -- the
  script will see the  entire file name, but the underlying file
  operation will truncate the  name of the file after the NULL byte. So
  something.asp%00.jpg would  become something.asp.

Another walkthrough of an PHP code embeded in an image.


Besides OpenVas and Nessus, what are my other options for vulnerability detection? I know of Nessus (which is $1300 for a pro feed) and OpenVAS (which I don't like).

I use Linux so do I have any other options for vulnerability detection?

There are quite a few (read loads) in this space. Some examples:

nmap - can run on *Nix'es and Windows

The following offer internal or external vulnerability scanning and management

Core Impact - may be outside your budget
Microsoft Baseline Analyzer - free (but obviously focused on Microsoft)
Retina
Nexpose
Qualys
Randomstorm
Accunetix
GFI
Outpost
Appscan
etc.

Then you have web vulnerability scanners like nikto and code assessment tools like Fortify

Have a read of Fyodor's sectools list


System for securely authenticating content acquisition I'm having trouble designing a system for authenticated content from my site distributed by other people. I'm working in Ruby on Rails, but I don't think that at a theoretical level my question isn't restricted to that framework. In order to not give too much away, my site (let's call it www.site.com) helps businesses keep inventory of who has purchased what item, and allows customers to view their purchase history.

Hence, I have the following problem:

Suppose Alice sells cheeseburgers. Alice makes an account on site.com and registers her cheeseburgers as an item that she sells. Consequently, site.com stores Alice's cheeseburger in a SQL database with the id 92314
Bob is a customer at Alice's cheeseburger stand and has recently purchased a cheeseburger.
Alice would like to tell Bob about site.com and its ability to track purchases. Hence, Alice sends a request to site.com to return hashA that corresponds to item with id 92314.
Bob visits www.site.com/purchase/hashA and is prompted to either create an account or sign in to log his new cheeseburger purchase from Alice's Delicious and Delectable cheeseburgers.
Charlie also visits Alice's cheeseburger stand and purchases a cheeseburger.
Alice would also like to tell Charlie about site.com and sends a request that generates hashB for Charlie to use in the same manner.

My question is, how do I come up with a scheme that can generate hashA and hashB in a way that my web server can efficiently lookup the items. I suspect that hashB can be generated from hashA using some sort cipher using hashA as a seed. I don't know how, upon receiving hashA or hashB, site.com will know that it corresponds to item 92314. I suspect that using a nonce will help.

Things that I would like to avoid include:

Having Charlie use hashA after it has been used by Bob
Exposing the id 92314 to the user
Having a single point of failure (i.e. a single key that encrypts hashes for all ids)
Having things break if Charlie uses hashB before Bob uses hashA.

Disclaimer: My expertise is more in computer graphics and less in web development or cryptography, so pointing me towards things to Google is helpful. If this belongs in any of the other stackexchange sites (Cryptography, Programmers, etc). Feel free to let me know and I will move it.

Whoa! You're overcomplicating the issue to a high degree; the matter at hand is way simpler.

Table 1 (products)

product_id - product_name - product_key

product_key can simply be the sha1() of product_id, product_name, and some random bytes. Or, better, just grab random 16 bytes and pass them to sha1().

Table 2 (requests/invitations)

request_id - product_id - request_key - valid

request_key is generated the same way: the sha1() product of request_id, product_id, and some random bytes. Or, simply, the sha1() of some 16 random bytes.

Now, when Alice wants to tell Bob about site.com, a row in "Table 2" will be generated, and she'll simply send him the link site.com/purchase/request_key.

Same thing happens when telling Charlie; a new row in "Table 2" will be generated (new request_key), thus, a new link. Once the link is visited, you check if valid is true. When the key is used, you set valid to false.

The key can only be used once.
The ID isn't exposed.
No fancy encryption.
Each request key is independent.


How is an X509 certificate signer verified? Lets say I create a self-signed X509 certificate A and use it to issue certificate B. I put certificate A in my trusted root authorities so that all certificates signed by it are accepted. My question is:

When I then use a service protected by cert B, how does my computer know it was actually signed by cert A? Is the parent certificate somehow embedded into its child?

In a X.509 certificate, the name of the issuer (in your example, A's name) is also included (as issuerDN). Also, a certificate can contain an extension which points to a place where the issuer's certificate can be downloaded (the "Authority Information Access", section 4.2.2.1 of RFC 5280); note that since all certificates are signed entities which are accepted and use only after having verified these signatures, they can be downloaded and transported with little care. Finally, it is customary, in protocols where a party can show a certificate, to actually show a list of certificates containing needed intermediate CA certificates. This is what happens, for instance, in an SSL Certificate message.

All this gives a lot of ways for a computer to do certification path building, i.e. reconstructing chains of certificate on which validation (including verifying cryptographic signatures) seems relevant.


How effective is something like Deep Freeze against boot sector infections? I work for an embedded system manufacturer and on our older generation systems, which are powered by Windows Embedded, a number of customers have been experiencing virus infections.  Due to the real time nature of these systems, anti-virus solutions are not particularly practical.

These are primarily caused by their employees being on the internet and downloading inappropriate material to the system.  We require the browser for customer service reasons, so simply locking it out isn't an option.

We've been exploring Deep Freeze as a way of mitigating the issue, this tool is designed to restore the file system state.

I'm uncertain as to whether this will be effective against boot sector viruses, does anyone have any experience with this?  Has anyone used Deep Freeze for this sort of purpose?

Where can I obtain reasonably relevant boot sector viruses for testing?  (For anyone concerned about the legitimacy of this part of the question, I can be contacted at my work email for verification, it's the email associated with this account).

Forgive me, but the #1 solution for a real-time dependent system is to not let undesignated junk run on it. Users shouldn't be browsing the Internet with an RTOS setup. That needs to stop yesterday.

At least in good theory, Deep Freeze type systems will protect your computer from any permanent modification. They intercept all write activity and remap it. That means that any changes, including to the boot sector, would be dereferenced upon boot. Frozen data is never overwritten, just pointed away from until the system is reset.


Possible ways for hackers to alter kernel behaviour without root I'm wondering is it possible to harm kernel (by injecting shared library, loadable module or something like that) without root. If yes, how hackers can achieve it?

There's not supposed to be any way for unprivileged users to modify the running kernel. The two ways that such an attack could happen are either to first exploit a bug in a privileged service or setuid binary to give them root (such as CVE-2010-1646, the secure path vulnerability in sudo), or to exploit a bug in the kernel itself (such as CVE-2017-6074, the DCCP double-free vulnerability).


Is it appropriate to block a sender's email address This morning I received a mail from Apple suspension UK <do_not_reply@apple.co.uk> with the subject Apple "Unauthorised transaction alert".

The mail was sent to one of my company's distribution groups, rather than to a real person; so I'm confident it is not genuine.

I reported this to our Exchange support team, who responded saying they'd blocked all mails from do_not_reply@apple.co.uk.

I suspect that's the wrong course of action; since the sender's email address is presumably a valid one / likely to be used a lot by Apple; so now we've introduced an issue where no one will receive genuine mails from this address.  Rather I assume the spammers spoofed this sender's address, so can just pick a different address and get through again.

Question:

Is blocking a sender's mail considered a good approach?
Is there something I could be doing (e.g. attaching the spam to a new mail and forwarding it to a service which will analyse it and highlight if it's a security risk / automatically work out a new signature to blacklist)?

Update

Exerpts from Message Header:

Received: from mx0b-001b1801.pphosted.com (148.163.158.1) by
Received: from pps.filterd (m0077987.ppops.net [127.0.0.1]) by
Received: from 190.106.222.31 ([190.106.222.7]) by mx0b-001b1801.pphosted.com
Received: from unknown (HELO 8erd) ([173.233.206.183])  by 190.106.222.7 with
From: Apple suspension UK <do_not_reply@apple.co.uk>
Return-Path: do_not_reply@apple.co.uk

Blocking the senders e-mail address is unlikely to be an effective measure as spammers/malicious actors will commonly change the address they use on a regular basis.  That said it's worth noting in this case that a quick search for do_not_reply@apple.co.uk shows the only indexed instances of this address being spam related, so it doesn't appear to be one that Apple use.

Generally the best response for individuals to these mails is to ignore them and do not open any attachments or follow any links that they contain.

At a network or company level the best approach is likely to make use of an anti-spam service which will attempt to idenify and block this kind of message.  These systems will cut down on the volumes of spam that get through, although they are not perfect and there is always the risk of false-positives which could lead to legitimate mail being consigned to the spam folder of your mail system.


In case of TOTP code generation, why do products prefer a generic authenticator apps, such as Google Authenticator? All the products supporting TOTP-based 2FA use one of the common authenticator apps such as Google Authenticator, Authy, etc.

I want to understand whether there are any security reasons behind why the implementations prefer to use the generic authenticator apps and not build the TOTP code-gen application themselves or even have it in the main app (the one that relies on TOTP for 2FA)?

I see a few concerns:

Most of the TOTP use-cases are for login, so I understand the need for a different app to share the code, instead of having the code-generator within the parent app, which cannot be accessed - well - until one login. However, 2FA can have use-cases other than login
Time-sync on the local device can be hard, so one can rely on apps like Google Authenticator to implement it rather than implement it themselves.

What are the other reasons? Are there any security concerns? I could not find any reference in the RFC specs.

In my opinion you are essentially asking why developers rely on existing and established apps instead of inventing their own? There are many reasons for this, like

crypto is hard so better use something proven
shorter time to market
less development costs
maybe these apps are already familiar to the end user, i.e. less friction for the user and less support costs for the developer


Detecting/preventing rollback of encrypted data on a server I need to store a frequently-changing set of encrypted data in a database. This can be encrypted and decrypted with an internal key. The data is based upon other metrics within the system, mostly the number of times various things have happened.

Encryption in this case only provides security by obscurity, in that if a person figures out where this data is stored and has database access then they can simply 'roll back' this encrypted blob to an earlier version, thus reverting its contents to a past state.

An HMAC of the data wouldn't help, as an adversary could simply roll back the HMAC along with the message it represents.

Is there a way that I can, at least, detect cryptographically that this data has been rolled back?

My feeling is that I'll need to make some element of the stored data refer to the current state of the system, or make it time-based.

The prevention of roll-back on Databases is not easy. Let's talk about rows.

Adding date and time  will not help, you need to store the date of update locally and id of the data.
HMAC will not help, same as above
HMAC and date : will not help, same as above
Channing all rows will not help. The attacker can revert back to an old state in all of the states. You can store the last value of a chain, then you need to look for the validity of the chain.

Is there a solution?

Better use Merkle Tree, which is optimal and requires only log n data transfer. Keep the HMAC of all cells of a row in the last column of the row and use the Merkle tree on this column only. With this, you need only store one Hash value, locally.

If your application servers are also under threat, than you can uses either

a third party, or multiple of if so that in any conflict you can be sure about the change.
Another solution is using HSM in application servers to store the value.

There are some academic articles about the integrity and authenticity of the databases, most of them missing/hiding the rollback problem. The Merkle-Tree is the king.


Access protected (from export) private key in windows certificate store I have created a CSR with the option to disallow the export of the private key. Can I still access it?

If not, how is it protected?

You can try using Mimikat'z crypto module. Most A/Vs flag Mimikatz as a "threat",  add appropriate exclusion.


zip password cracking with permutation I have a zip file (.zip created by 7zip v15.10) that I remember the password to (~12 characters long), but it seems I've typed the password wrong while zipping it and now it doesn't open.
What are the best tools to recover the password based on the permutations of what the password should have been?
Some paid zip cracker software claim that they're able to find the right password based on what the password should've be by trying the permutations of it, what I want to find out is: are their claims true?
A year ago I've tried the trial version of one, it had one method that I would start typing the password and at some point it told me that "password found" but to see the password I had to pay for the full version first. I couldn't verify that their claim was true and since their last update was 5-7 years in the past, I was hesitant paying to find out.

The tool you need is called HashCat.
In the first instance, you need to specify or extract the stored+salted hash that is within the zip file, eg:

hashcat -m 13600 "your_zip_file.zip" ^ (for 7z zip files)
7z2hashcat (for 7z files)

(^ See this discussion on various zip formats in hashcat: https://forum.hackthebox.eu/discussion/3783/zip-password-crack)
Then, you need to configure hashcat to limit the range of characters from which it will draw its possible combinations. This is addressed in the documentation.
edit: to clarify: you don't specify the total number of possible characters in your question, so it's not possible to predict or speculate on possible hashcat configurations, however, the tool allows you to specify the charset that applies for a particular placeholder, viz. https://hashcat.net/wiki/doku.php?id=mask_attack#examples - in your case I would recommend creating more than one (max four) custom charset with the possible known characters at various regions in your password - the more constraints you can impose, the less the total number of tests that must be executed.
Depending on how many possible combinations there are, you may wish to parallelise the operation. This is beyond the scope of this answer, however, here's an idea about how to approach the problem: Hashcat performance on AWS EC2 GPU instances de Koning 2019
Let us know how you go ... good luck!


Converting an intranet site to internet We currently have a web application with client sensitive data that is only accessible by the intranet.  The management wants to open this to the internet because there will be a need to have other companies to access this application.

Has client sensitive data
Only authorized person (inside or outside) can access it
Account management is handled by IT only (i.e. no account creation by user, no "forget my password" mechanism)
Current security measure: hashed password, SSL, no direct SQL statements used, database audit tables

I want to know if there is any guidelines that I should follow when assessing the risk.

Very broad question, but here is a baseline of security additions I would add

Firewall rules to block ALL except authorized sources
Remote syslog/event logs
Web Application security test

This is beyond broad, and scattered. The reasoning? I have no idea what your risk is. Only you and your organization can determine that. So a quick risk analysis on a 50k view:

Question: "I need to put this server online, what is the risk someone will get my data?"

Answer/Question: Who has access to data (what network and why). Can I minimize this via a certificate, SSL, VPN, ACL?

Answer/Question: Once someone DOES access this site, what permissions do they have? Can they access all data, some data, how does it get processed, can someone attempt to access something they have permission for, if so will I know via logs, alerts?

Answer/Question: Can this be done safely over the Internet? Should I be introducing this risk not only to myself, but to my clients? Can I enable a VPN transaction, with this procedure documented so my clients understand I value their security?

Then there is the more granular problem outside of that server. "What if someone compromises this server, what can they do once on the server. Can they pivot back into the corporate network. Can they pivot unto any network in the routing tables? Can they sniff other client connections and compromise other clients?" This question is rather broad, and I hope I gave you some things to think about. There is no "what framework/standard/guideline" I can think of because 1) I don't know your industry 2) I don't know the purpose of your application 3) I don't know your organization's risk tolerance.


How can I objectively evaluate trust in a person? (Systems Admin, or other) When recruiting for positions that require a level of integrity and trust, I'm looking for objective ways of accessing that, either positively or negatively.

Is there any any guidance one should use for accessing an individual's propensity for theft, or other unsavory acts w.r.t. Information Security?

It would be similar to the challenge of hiring a janitor for a building, he would get to have all the keys, he can open any door, but the reason is because he needs them to do his job. Symmetrically one can think of this age old problem and look at ways trust is granted historically.

Although there's no clean-cut technical solution to this human problem, the fact that there's none shouldn't be a reason that we don't try any, an aggregation of imperfect solutions can give somewhat great results.

A model where trust is earned:

Give less permissions to begin with
Gradually increase permissions
Put a honeypot and monitor what happens in the coming days
If he reports it and doesn't use it for his advantage, that's a good start

Implement several levels of administrative powers:

Level 1: Can modify lower tier of configuration files
Level 2: Can modify slightly higher tier of configuration files
Level 3: Can modify slightly higher tier of configuration files and OS settings

Always create an environment where total access by one person is not possible:

Split systems in clusters
Give cluster admin powers to different groups
Minimum 2 groups

Use the Two-man rule when doing high-level core changes:

https://en.wikipedia.org/wiki/Two-man_rule
Require an admin from cluster1 and cluster2 for core changes

Trust and verify:

Log everything
Log monitoring and alerting
Ensure all actions are distinguishable

Paperwork:

Have them sign paperwork to have the legal system be able to help you by suing them if they hurt you gives more incentive not to do so


How to find why so many host are talking to an IP which is blacklisted In my SIEM tool, I got multiple alerts for communication with malware sites from Palo Alto firewall.
I have seen many outbound communications from internal IPs toward IP: 74.217.31.51 having host name: match.basebanner.com which is having many blacklisted domains to which internal host are communicating.

Reference:
https://www.virustotal.com/en/domain/match.basebanner.com/information/
https://www.virustotal.com/en/ip-address/74.217.31.51/information/

Now I need to find out why these machines are communicating to these IPs.
How to trace them and what proper remediation that I should recommend to my client to handle them?

Tell your client that they need to run virus scans on the source IPs and to inspect the browsers of those machines. They can also run netstat on the Windows machines:

netstat -a -o -p TCP

That will show them the process that initiated each TCP connection.

Once they know what is triggering the connections, they can plan how to address the problem.


sql injection, exec and preg_replace filter Ive been informed this is not safe to use in regards to sql injection:

preg_replace("/[\"'%()@$.!&?_: #\/-]/","", mysql_real_escape_string($_GET['var']));

what would be the difference in the following change?

mysql_real_escape_string(preg_replace("/[\"'%()@$.!&?_: #\/-]/","", $_GET['var']));

how about if no database connection was made, for example exec was called, how could this be bypassed? working example? a better way to guard against injection?

$theVar = preg_replace("/[\"'%()@$.!&?_: #\/-]/","", mysql_real_escape_string($_GET['var']));
exec("zip -r archived.zip ./".$theVar."/");

The only sure way to guard against SQL injection is by using parameterized queries. See: SQL Injection Prevention Cheat Sheet by OWASP.


Is clipboard secure? Can a browser get the data on my clipboard? Data could be for example my temporary password?

Any browser or operating system that allows this?

For Javascript, Internet Explorer allows you to block that specific functionality, without disabling Javascript altogether.
In Tools -> Internet Options -> Security ->  -> Custom Level, you can find the following setting:

Sadly, I wasn't able to find an equivalent setting in neither FF nor in GChrome.

Additionally, however, as it has been mentioned, there are other ways besides Javascript for a browser/webapp to access your clipboard. Some have some forms of controls available too, but I'm not familiar with all of them (e.g. Silverlight has CAS, but I dont know SL well enough to know how to block it).


What is "Intentionally misleading Artificial Intelligence to create a misleading outcome" called? I'm writing about a computer system that relies on Artificial Intelligence and the threats that this may include. One threat vector (for example) is to seed Bayesian AI with content to skew the outcome.

Question

Assuming that AI can't tell the difference between a fact and fiction, what is the term used to intentionally bias the system so that a desired result is achieved?

"Hacking" is too broad
"phishing" is about misleading humans to disclose information.
"Fox-News-ing" humans seem to be the most appropriate analogy, but I need a term the already exists... or I can invent one, given that I define the term in the beginning of the paper.

My draft is using the term "Foxing A.I." for now

This question may be better suited for English.SE.

Disinformation is defined as the the act of misinforming someone by giving them deliberately incorrect information, often with the purpose being to change the actions or behavior of the target. This is not specific to humans, and disinformation would be applicable to an artificial intelligence that implicitly trusts input and will act on it. This has a nefarious connotation.

An example could be telling a military tactical advisor computer that its country's adversaries have just amassed a large quantity of weapons of mass destruction. Despite being programmed well, the machine may conclude that the best course of action is a massive preemptive strike.

Garbage In, Garbage Out, or GIGO, is a term in analytics and logic, very often applied to computer programs, which essentially means that the conclusion made by an algorithm is unsound if the premises are flawed. This term came from concepts in scheduling: First In, First Out (FIFO) and Last In, First Out (LIFO). Phrased another way, no matter how sophisticated a computer is, the computer's output is only as accurate as the information given to it.

An example of this could be providing a utilitarian political advisor supercomputer with incorrect utility values, leading to felicific calculus giving an incorrect or even horrific answer, despite the machine attempting to improve the quality of human life. If you tell such a computer that people get a huge sense of thrill out of being robbed, it very well may suggest reducing the budget to fight crime.


Are most MiTM attacks done to impersonate web sites, or simply decrypt traffic? The more I read about impersonating web sites the more I get confused. Does an attacker need the private key of the server in order to impersonate a website or does having the private key simply give him the ability to decrypt the communications?

When I think of impersonating a website I think of a collision attack, where an md5 hash has been broken and a fake cert can then be used in order to effectively impersonate a website using a new key pair.

When I think of a MiTM attack I think of an attack where the person in the middle gets the private key of the server and forwards traffic back and forth between the client and the server, allowing the attacker to decrypt and view all communications. This to me, is not "impersonating a web site". Can someone please clarify my confusion here?

Generally the main use for MitM at the moment is for the attacker to impersonate the website to the victim.

The aim being, usually, to get hold of the victim's credentials in order to impersonate them, authenticate correctly to the website and make off with the contents of their bank account, data store, intellectual property etc.

This is done, typically, the way you state in your final paragraph. As far as the victim is concerned, they see their website. This is impersonation.

I'm not sure your collision attack is a likely scenario for impersonation, however faked certs are certainly an avenue to attack.


Could access to the WHOIS contact methods for a domain name provide any form of access or leverage to the domain? In WHOIS, every domain name has at least an email address, physical address and phone number that can be publicly accessed (assuming privacy is off).

Could the ability to receive messages/mail at these contact points allow an attacker to take over the domain or gain any other form or leverage? Or are they used purely for human contact/abuse reporting? Social engineering is allowed here.

For example:

The email account registered on the WHOIS contact is compromised
The phone number is hijacked (SIM swapping, etc)
Mail to the physical address is intercepted (social engineering a delivery person, etc)

This is assuming that the contact details publicly accessible in WHOIS are different to those used to access the domain registrar account.

Note that public whois data may get a good bit scarcer because of GPDR.

Email, fax, SMS, mail, or phone to a whois contact are some of the ways a Certificate Authority can validate the right to obtain a cert according to https://www.cabforum.com Baseline Requirements 3.2.2.4. Thus, unless the legitimate owner has set a CAA record to only the CA(s) it actually uses (who can recognize you as a fake) (and you haven't compromised the logins to such CA(s)), you may be able to get a fraudulent cert for (or under) the domain name.

If you are also able to divert or intercept traffic to that domain name (e.g. DNS poisoning, BGP 'mistakes', ARP spoofing, etc.), and the legitimate owner/site hasn't set HPKP or DANE, using this cert you could impersonate the site.

... except to users who do extra cert checking manually or with a browser extension or similar, and probably many(?) of those users read this Stack and are already on to you :-)


Is using Argon2 with a public random on client side a good idea to protect passwords in transit? Not sure if things belongs in Crypto SE or here but anyway:
I'm building an app and I'm trying to decide whatever is secure to protect user passwords in transit, in addition to TLS we already have.
In server side, we already have bcrypt properly implemented and takes the password as an opaque string, salts and peppers it, and compares/adds to the database.
Even though SSL is deemed secure, I want to stay at the "server never sees plaintext" and "prevent MiTM eavesdropping from sniffing plaintext passwords" side of things. I know this approach doesn't change anything about authenticating, anyone with whatever hash they sniff can still login, my concern is to protect users' plaintext passwords before leaving their device.
I think Argon2 is the go-to option here normally but I can't have a salt with this approach. If I have a random salt at client side that changes every time I hash my plaintext password, because my server just accepts the password as an opaque string, I can't authenticate. Because of my requirements, I can't have a deterministic "salt" (not sure if that can even be called a salt in this case) either (e.g. if I used user ID, I don't have it while registering, I can't use username or email either because there are places that I don't have access to them while resetting password etc.) so my only option is using a static key baked into the client. I'm not after security by obscurity by baking a key into the client, I'm just trying to make it harder for an attacker to utilize a hash table for plain text passwords. I think it's still a better practice than sending the password in plaintext or using no "salt" at all, but I'm not sure.
Bottomline: Compared to sending passwords in plaintext (which is sent over TLS anyway but to mitigate against server seeing plaintext passwords and against MiTM with fake certificates), is that okay to use Argon2 with a public but random value as "salt" to hash passwords, to protect user passwords in transit? Or am I doing something terribly wrong?

Argon2 is not meant to protect anything against MITM. It's not the right tool for the job. Using Argon2 on the client side (with or without TLS) will force you to either store the plaintext password on the server side, or it will make the hash become the password: in both cases you end up usually worse than when sending the plaintext password over TLS.
You might need to think more about your threat model.
Extended answer:
A "solution" can be worse when you look at your overall information system, and not just on one threat. An extra layer that does not significantly improves security might needlessly increase the complexity of the system, the chances of bugs to happen and the number of interfaces an attacker could try to exploit, thus decreasing the overall security of the system.
In your case, if your hash becomes the password, and you save this hash in the database, it is as bad as saving plaintext password in the database; especially since you are assuming an attacker able to do MITM in TLS, who should be able to replay the hash to authenticate. If you are not assuming that an attacker can have this capability, you do not need this extra layer of protection.


Protocol/standard/software for requesting PGP signing/verification of content? I have a small web forum and would like to promote the use of PGP signing of messages. Users can sign their posts and verify the posts of other users but currently the process is manual. Depending on the software they're using and OS integration some users can use keyboard shortcuts to sign their messages or verify messages from other posters, but some are simply copy/pasting content between another piece of software and the forum. This seems fine from a security perspective but it's not a great user experience.

Ideally I'd like to request signing before message submission from the user's local PGP software so my service never comes into contact with private keys in any capacity, it simply requests signing from some service that's aware of the user's private key, receives a signed response, and stores that. Is this possible? Would this represent a risk (from the user's perspective) of a chosen plaintext attack?

On the other side it would be nice to automatically verify signed messages. This seems more difficult since even if I as the service know every user's public key and can do the verification, users still have to take it on faith that my reporting of signature verification results is reliable, although perhaps there's some way for the user's software to report verification failure.

Does anything like this exist where a website can request crypto services from another piece of software that's trusted by the user? Is there any fundamental security issue with such a setup?

Assuming you are using forms one could add accept=multipart/signed,application/pgp as an attribute of the appropriate input element.  I don't think there is anything out there that would actually do anything with this information but it is a standards compliant way of expressing that you want signed data submitted.

As far as security issues go I think as long as whatever does the signing makes it clear to the user what they are signing and gets their consent it should be fine.


Risk of issuing a client-certificate for every user in application level I'm currently working on a project that includes client-authorization using client certificates, where my app is the Certificate Authority.
Doing that, every user that registers to my web server gets a p12 signed certificate issued especially to his username as common-name.
Currently the app signs every CSR it gets, only if the CN is not in the users database.

Am I exposed to potential risk doing so? Can the client abuse it somehow? Do I need to check more carefully the PKCS12 parameters?

Thanks

Possible risks include:

Complexity. The clients will have to generate and submit CSRs, securely store private keys, and renew them when they expire. That’s a lot more work for them than simply storing an API key.
Response time. If you decide Client B needs to have their credentials revoked due to an incident, you may not want to sit around waiting for their certificate to expire, or for the next round of CRLs to be published.
Spoofing. You have to validate the identity of each client as they request a certificate. How will you validate them so you know you aren’t giving a certificate to an impostor?
Maintenance. You have to support expirations, renewals, revocations, and everything associated with running a PKI. This is a non-trivial amount of work.
Dynamic clients. A certificate is associated with one instance. If you validate their domain name, they’ll need a new certificate for each instance. This might be OK for desktops, but gets tougher when you’re talking about mobile phones or kubernetes pods and docker containers.
Lopsided capacity. As your root certificate approaches expiration, you can expect a giant rush of client renewal requests. So for a once a year occurrence, you may have to scale to handle a lot more traffic.

On the plus side, mutually authenticated certificates form a trustworthy bond in both directions. That’s worth a lot of headaches.


Does changing the default number of iterations in KeePass (or other encryption applications) increase security? Inspired by this question about the difficulty of cracking a KeePass database, I'm wondering if changing the default number of iterations in an encryption application (e.g., KeePass) increases security. I'm hoping the question is applicable to a variety of applications; if not, I guess today I'm curious about KeePass.

My reasoning is that an attacker doesn't know the number of iterations ahead of time and therefore has two options:

Assume the user of the encryption application didn't bother to change the default number of iterations, or
Check for password validity for a range of thousands of possible iteration choices (the default is 6,000, so maybe anything from 5,000 to 20,000 or more)

Because #2 is much more work, it's a safer bet for the user to change the default. My theory would be that using a number like 6,001 actually substantially increases security since the attacker is going to focus efforts on the default value of 6,000.

I've read some related questions, which discuss generally how many iterations to choose. What isn't clear to me is whether using an application such as KeePass, where the default number is known to the attacker, makes it important to change the default. If my hunch is wrong, you'll tell me that using 6,001 iterations in KeePass is just as secure as 6,000.

At what point does adding more iterations to PBKDF2 provide no extra security?
Recommended # of iterations when using PKBDF2-SHA256?

Before we start, I think it's important to point out that the round count is stored in the KeePass dictionary file header, so that KeePass itself can open your password files regardless of the setting in its preferences. Otherwise you wouldn't be able to open a KeePass file on another machine if it had a different number of iterations, without first reconfiguring KeePass to that same iteration value (which you may not even remember).

Trying to keep the number of iterations secret is largely pointless, and it's in direct contradiction of Kerckhoffs's principle - only the password should be considered secret; the algorithm and its general parameters should be considered known.

The most important thing to keep in mind is that PBKDF2 is designed to be secure against both precomputation attacks (e.g. rainbow tables) and brute-force attacks where the attacker has immediate access to the hash or an equivalent oracle. Increasing the number of iterations makes the attacker work harder for each password guess, at the cost of taking longer to open the vault legitimately.

Essentially, the security system relies upon the fact that you have to do one quantum of work (let's call this W) when entering the known password, but the attacker has to try hundreds of thousands of passwords (100000 * W), and therefore has to do hundreds of thousands of times more work than you. If your KDF is particularly fast, then W might only involve a millisecond or so of computation, meaning that 100000 * W is only a minute or so. However, if you can tolerate a one second delay, you can increase the work factor W such that the attacker's work takes days or years, not minutes.


Iso 27K Implementation Suppose we buy a new cisco router or any IT equipment. How can we employ ISO 27k/NIST 800-37/NIST 800-53 or any other related information security management standards technically? I mean what should we do about it? Should we install software to check its vulnerability? Or should we check that the equipment has well known vulnerabilities and obviate them?

Thanks in advance.

1) Build the system according to the vendor's configuration guide. Look at NIST, SANS, Centre for Internet Security for security benchmarks for the product and harden the system.
2) Follow industry best practice for unique user names, role based access control, strong password policies.
3) Enable configuration backups and diffs to identify unintended or malicious changes, enable logging and review.
4) Run a vulnerability scanner against the system IP and see if there are known vulnerabilities; remediate these.

The above will cover you for industry best practice.. ISO, NIST, PCI etc


Spam mails originating from botnet Background

I am working on spam detection at the receiver side,i.e where all mails are delivered,i.e at the mailserver side.
Spammers are capable of sending spam mails through Bots,Open relays and many other sources.

Query

Is,there any way/method to say that a spam mail received,is sent out through bots?

Being a mail system administrator, I suppose you know that email messages do not contain anything that would allow you to identify whether they are sent by a human or a machine.  The BOT will certainly not indicates that it's a BOT in the message or even the headers.

Common SPAM detection methods apply to any messages whether sent by a BOT or not.

I suggest you look at existing SPAM detection solutions such as SpamAssassin along with the different plugins available for it.  As you will see, with proper training, it actually does a very good job.


Is generating keys on a remote computer unsecure? Say I'm on machine A and have SSH access to machines B and C. I'm logged in to machine B. I generate keys on B that I use to authenticate my access from B to C.

I've read that you should never generate keys on a remote system "over the internet". Why?

I believe what is discouraged generating a key for use on a local machine remotely. The situation you outlined is secure (assuming machine A and B are both trusted machines) if you're simply generating keys on machine B (and keeping them on machine B!) for use on machine B to connect to machine C.


Can hackers steal money from my PayPal if a web shop is compromised? Say if I were to purchase something on somewebsite.com using PayPal. If somewebsite.com was compromised, what are the chances of my PayPal account being hacked compared to before the breach?

With a proper setup the Paypal credentials itself are not known by the shop so they should be safe if the hack occurred after you've bought something. But some data like shipping address or email might be shared with the shop by Paypal and thus can be compromised. Also, if you enter your credentials after the shop was hacked it might be that the attacker changed the site so that it now grabs your credentials, i.e. similar to what many sites do which are involved in phishing.


Bypass x-frame-options for clickjacking Is there any way to bypass the x-frame-options header without using a MitM or changing the packets in another way?

So actually getting a site that has x-frame-options: DENY to be shown in an iframe.

There is one caveat when using X-Frame-Options header: it only checks the top level frame. This means that if you have nested frames, i.e. frames within frames, it is still possible for another origin to include a site with a X-Frame-Options: SAMEORIGIN header.

In this regard the header Content-Security-Policy: frame-ancestors 'self' is better, because it checks all frame ancestors.


Securing a multi-tenant API with SSO and different roles per tenant I am working on developing a REST API that will be used by first party clients that we develop, and third party clients in the future.  The first party clients include a SPA client side application, and programs that run on client PC's (can't guarantee security of secrets).

Furthermore, this API is pseudo-multitenant.  We have multiple tenants, and each tenant can have one or more active instances in the API, each with it's own set of security roles, each with varying permissions.  All of this data however is stored in the same database, and we want the ability to allow users to switch the instance they're working on (both in-tenant, and out-of-tenant).  Sign in CAN be allowed using third party providers (Facebook/Google/etc).  Also, their sign-in should allow them to access the other instances without re-authenticating.

I'm getting a little confused on exactly how I should be implementing the authentication/authorization logic given the multi-tenant/multi-roles nature of the API.  What I am thinking the right path is to implement OpenID Connect authentication to the API, and then OAuth to delegate the access to the specific instances that the user is attempting to.  My confusion comes into play when I attempt to determine what tokens should be in use where.  We want the ability for our users to remain signed in to the SPA, and still change their instance.

I've seen information on securing multitenant/multidatabase REST api's, but the roles appear to be consistent, so I can't extrapolate the handling to one database with various roles.

So these are my questions:

Is it correct to use OpenID Connect and OAuth2 given this information?
It appears that OpenID Connect allows for advertising the scopes that you wish to delegate.  How would this be handled with roles indeterminate until after authentication and when their tenant is known?
Is it correct to delegate the individual permissions via OAuth (what I want to do), or should OAuth just delegate their assigned roles per instance, and the application then have to lookup the permissions?
Should there be two separate tokens, one for general authentication, and one for the authorization per instance?  What would be the standard for passing these to the API.  Currently we are using JWT and an Authorization Bearer header.  I like the simplicity of one token, but if that needs to be adjusted, amended, we can do that.

I have been searching for articles for the past week or two on this, but haven't found anything to help clarify what type of flow would be best for my situation and how I handle the variability from instance to instance.  If you think I've missed an article, please feel free to add it to this as a comment and I'll review it as well.

I'm not a programmer, but I have reviewed an org that seems to do something similar.  Here's how they do it...

AngularJS client authenticates with an application security API we have via OAuth.  The system hosting the API then passes the authentication and requests the authorization from a second system.  The second system returns the authZ token, username, and claims to the security API system.  The security API calls to a token manager system that creates a JWT and returns it to the security API system.  Finally, the security API returns the encoded JWT to the AngularJS client.

An individual call goes from the AngularJS client to the actual application API, providing the token.  The application API system gives the token to the token manager for validation.  If valid, the API returns data (or throws on invalid or expired tokens).

For renewal, the AngularJS client contacts the security API again, which contacts the authZ token system, returning the renewed token to the security API system, which send it to the token manager for creation of a new JWT, which the security API returns to the client.

At change of tenant, it does an authZ token transfer request call to the security API that goes all the way to the authZ token server, a new authZ token is created and sent back to the security API along with username and roles, it requests a JWT with that, and once returned, passes it to the client.

To more directly answer your questions...

It seems correct to use OAuth and OIDC
I don't know about scope advertizing.
I'm in security, so I'm a fan of role-based access control for everything.  :-D  So I'd say to have the application do the individual perm lookups from the roles embedded in the token.
Two separate tokens appears to be how this org deals with it.  One, which seems to function as both identity and session ID.  The second is the JWT which includes that first token and the roles/claims for the current tenant.


Does the Windows Surface RT or Pro (Windows 8) support local encryption of Activesync data? Our company policy is requires the local encryption of data for all email (in case the device is stolen)

Does the Windows Surface (either version) support local encryption?
Is the local device information sufficiently protected from offline attacks

The Surface Pro runs Windows 8 Pro and has a TPM, so in theory at least, you should have all the available security features of any Windows 8 laptop, including BitLocker.


why does ssh prompt with the ECDSA key instead of RSA When I use an Ubuntu from linode

ssh-keygen -l defaults to looking for an RSA file to "list".

Yet ssh issued from a client asks for verification of the remote linode's ECDSA key.

This means that on the linode the following

ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub would have to be issued in order to know the key which is inconvenient and hard to remember.

Should it not be that both tools default to RSA or that both tools default to ECDSA. Why are the defaults "out of synch"?

Edit: To clarify, ssh-keygen -l seems to default to RSA and it knows the default path. If ssh would prompt with an RSA key then ssh-keygen can be used with the shorter command. Unfortunately, ssh prompts with the ECDSA key.

ssh-keygen -l seems to default to RSA and it knows the default path.

ssh-keygen -l defaults to use a RSA key within the users home directory, i.e. ~/.ssh/id_rsa. Keys in the home directory are used to authenticate the client to the server. What you want to verify instead is the host key which is used to authenticate the server against the client. To get this fingerprint you need to specify the key with the -f argument no matter if RSA or ECDSA is used since it is not located in the users home directory but in a system directory, typically /etc/ssh.

  If ssh would prompt with an RSA key then ssh-keygen can be used with the shorter command. Unfortunately, ssh prompts with the ECDSA key.

SSH prompts with whatever key the server is presenting to the client, i.e. it fully depends on the server setup and not on some SSH builtin defaults.


Hashing password with salt I read from wiki:

  The attacker has access to both the hashed password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password.

I have two questions:

Should the attacker not get  the hashed (password + salt) instead?
Is it true  that the attacker can get the salt?

Obviously, preventing access by an attacker to the stored hashes is preferable. Hashes are the next line of defense after access denial fails; when the attacker dumps your database, he has to run a dictionary attack on the hash to discover the plaintext.
What salts prevent is the use of a pre-compiled "dictionary", aka a "rainbow table". Without a salt, or with a universally-constant salt (same thing), any and all previous efforts to compute hashes can be re-used by remembering and storing the message and its hash, then simply searching for a matching hash. However, with a unique, random salt for each hash value, now no work can be reused; the message has to include that specific salt value, and it's extremely unlikely that an attacker would find a working message in a rainbow table.

Yes, the attacker can get the salt. It's technically "public" information, because it must be available to any machine attempting to verify a hash. As Xander said it's usually either stored in a different column of the same database, or its prepended as a number of character-encoded bytes onto the hash digest itself.


GDPR data minimisation session cookies I have a research study being run. Participants are asked to;

Fill out a consent form (contains personal information as per GDPR)
Complete a questionnaire.

My hopes was that the questionnaire responses could be anonymous, I would store the forms and questionnaires responses in separate databases with no reasonable way to match them up. The issue however is I must ensure no one can complete the second step, without competing the first.

My plan was to use PHP sessions, until I remembered that they could be used to match up the two databases. Or perhaps the second step is located on a secret URL  to hope people don't find it? (Not really suitable...).

Given the problem, anyone have an idea on how I could go about ensuring the steps are done in order?

You could do something like that (other solutions could be possible):

Step 1: The user fills the consent form.

Step 2: The server validates the consent form then generates a unique link to the questionnaire, not tied to the consent form. This link that can only be used to validate one questionnaire. The server flags (in its database) the session cookie as "consent form validated", but again, without linking to the consent form.

Step 3: The user fills the questionnaire.

Step 4: The server validates the questionnaire and the cookie, then invalidates the unique link and clears the session cookie.


Code Review Strategies As per my information, there is no hard and fast rule for doing a security code review but we all develop our own strategy for the same. I was wondering if we all can share the different strategies involved or used in security code review.

As @sonofaaa mentioned, in the book, "The Art of Software Security Assessment", the authors discuss code-auditing strategies in Chapter 4 (end of Part I).

In particular, external flow sensitivity (data flow and control flow) and tracing direction (forward or backwards slicing) are discussed along with many neutral methods of review. Other topics are discussed in great detail. It's the best written material on the subject of secure code review.

I should also mention "Secure Programming with Static Analysis" -- a book by Brian Chess and Jacob West of Fortify Software. They cover the internals and use of security-focused static analysis tools and compare them to other forms/tools in the secure code review world.

If you want to check out modern security-focused static analyzers, I suggest that you first get involved with some open-source or free tools such as CAT.NET for .NET (typically C#, VB.NET, and/or ASP.NET), find-sec-bugs (or the older LAPSE+) for Java Enterprise and JSP, and RIPS Scanner for PHP. You won't commonly find security-focused static analyzers that support dynamic languages, because they don't rely on a type system, but let me know if you are interested in support of Python, Ruby, or another dynamic language (or any other language) and I'll try to point you in the right direction. For starters, try Bandit (OpenStack project for Python code) and Brakeman Pro for Ruby.

Commercial security-focused static analyzers are meant for highly trained and specialized application security oriented developers. The cost of them assumes that someone will be running and analyzing these tools daily, as a full-time job, all year round. If you are interested in seeing quick results -- check out HPFOD -- but if you are interested to integrate these tools into a long-term, at-risk application portfolio for a large-installation -- check out Cigital ESP. There are also many application security boutiques and consulting shops that run and tune these tools for their clients. Depending on your locale and strategic direction, I would choose to partner with one regardless of anything else I mentioned, as they can be invaluable to success of an appsec program. Searching on LinkedIn for "application security consulting" should work if you don't where to go next.


Are there "LAN IPs" on the internet? I have a home-made web application and thought that an easy way to secure it's administration interface would be to simply reject all IPs that arent from 192.168... Is this viable? is it possible for someone to spoof LAN IPs on the Internet?

And if it's possible, wouldn't it be standard to add an iptables rule to reject all LAN IPs from the "internet interface"?

In practice this is likely to be a reasonable protection, but from an ideal standpoint you shouldn't rely on it.  Apart from anything else it disregards the possibility that an attacker can get access to a machine on your local LAN (e.g. if one of your systems gets infected by malware)

In terms of having iptables reject LAN IPs from the Internet, yep this is a standard practice known as Bogon Filtering


Security risks for a simple network configuration screen in android I am building an Android App that pulls chart information from a server where the connection is specified on this view

Ideally, the end user will put in a valid host and port resulting in business as usual. However, I've recently been looking at Cross site scripting attacks. The example provided to me was that if a web page has a place where a user enters text, and the text collected from the end user is echoed (php) back to the screen, an attacker could write code to the web page and have it executed when the text is echoed.

My question is this: Can something similar be done here? Could an attacker write a script, append parameters, or something else that could otherwise compromise the Mobile device or the server we are attempting to contact? Thanks in advance to any help.

From the UI snippet alone, we cannot tell much, but given your pseudo-code of:

http:// + {Whatever host they typed} + : {Whatever port they typed} + /path/

You might be in danger of someone crafting the following input:

http:// + {evil.com/evil_script.php?http://10.16.1.159} + : {8080} + /path/

In this case, the evil script now can input to your website (given certain conditions).


Is it a coincidence that the first 4 bytes of a PGP/GPG file are ellipsis, smile, female sign and a heart? As the title says, do those 4 bytes carry a meaning (I assume they do as apparently the smile changes depending on the key bitness)?

The two files below have been encrypted with the different keys, but within the same key those 4 bytes are always the same.

If these 4 bytes are always the same, is there any built-in way in PGP/GPG to prevent an attacker from knowing what file they may have obtained/intercepted, other than stripping these bytes in transit and re-creating them at destination?

Yes, it's a coincidence that the first bytes appear to you as these symbols. They are part of the OpenPGP message format specification (RFC 4880) and vary depending on the packet properties.

Let's create a file containing only those bytes and try to read it as a GPG message:

$ echo "\x85\x02\x0c\x03" > foo.gpg && gpg --list-packets foo.gpg
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 255, keyid 0AFFFFFFFFFFFFFF
    unsupported algorithm 255

The first byte (0x85 = 0b10000101) is the cipher type byte (CTB) that describes the packet type. We can break it up as follows:
1: CTB indicator bit
0: old packet format (see RFC 1991)
0001: public-key-encrypted packet
01: packet-length field is 2 bytes long
The second and third bytes denote the packet length (0x020c = 524).
The fourth byte (0x03) means it's in the version 3 packet format.

As you can see, these bytes are meaningful and not magic number constants that you can remove without losing information. If you cut them off, you are corrupting the GPG packet and it will require some guesswork to reconstruct it.

The bytes are shown as smileys and hearts because that's how your (probably DOS) terminal displays non-printable control characters. In character sets that originate from code page 437, low bytes outside the printable ASCII range are traditionally represented as icons. Here's the original CP437 on an IBM PC:

(Image source)