Locality Sensitive Hash (LSH) function to approximately match old passwords Recently, I ran across a website that requires me to change my password after X number of days had passed since I had last created one. Intelligently, the service made sure that the password did not (approximately) match any others that I had used before (something that clearly did not use permutations). However, I was intrigued by how it might of have done this, since my naive understanding at the time was that they would have to store plain-text in order to calculate a distance between two strings.

Trying not to assume the worst of the website (its run by a multi-billion dollar organization, for internal-employee use), I delved a bit more into methods that have been used. The first I pondered was sub-string hash comparison (I immediately threw this out due to the possible weakening of plain-text).  I thought they might do permutation-hashing (Again, threw this out because it matched approximates, and even with quite a few modifications, it appeared to do quite well).

That's when I ran across LSH as a concept. I thought it was a pretty cool idea, that allowed for some zero-knowledge-esque data comparison. That is, building a hash that has a high likelihood of matching things similiar to itself, but compresses and doesn't necessarily contain the information of the plaintext it was derived from.

Something along the lines of http://ixazon.dynip.com/~cmeclax/nilsimsa.html

  773e2df0a02a319ec34a0b71d54029111da90838cbc20ecd3d2d4e18c25a3025 spam1
  47182cf0802a11dec24a3b75d5042d310ca90838c9d20ecc3d610e98560a3645 spam2

  The nilsimsa of these two codes is 92 on a scale of -128 to +128. That means that 36 bits are different and 220 bits the same. Any nilsimsa over 24 (which is 3 sigma) indicates that the two messages are probably not independently generated.

Is this secure, and if not, is there a secure version of said method? Thank you.

A locality-sensitive hash function by definition does not posess the avalanche effect (http://en.wikipedia.org/wiki/Avalanche_effect), which is a key property for a cryptographic hash function.  The properties desirable for LSH are essentially the opposite of what is desirable for a cryptographic hash function.

Effectively, storing the locality-sensitive hash of a password is hardly any better than storing the password in the clear.

A simple method that can be used to check if a password is similar to a previous one, without deviating from the recommended practice of only storing a salted cryptographic hash of the password, is to simply use some method to enumerate a bunch of similar passwords to a given password (e.g. altering, adding or removing a letter), and then for each previous password, compute the hash of each similar password with the appropriate salt to see if it matches.  If an extremely slow password hash is used, however, this method could be problematic.


Securely erasing personal data from Android phone before selling I have just sold online my old Nexus 5 (Android Lolipop) and need to post it tomorrow morning. I would like to make sure the new owner can't access my files.

What should I do?

Factory resets reset your phone to a stock like state but does not remove your data, just applications. This leaves some data behind. The best way to prevent this data from being recovered is to encrypt the phone, and use wipe data/factory reset from the recovery menu. This way you don't have to download a ton of data and you can be fairly certain your things are secure.

If you're not that worried, encrypting, and data/factory reset from the recovery menu is probably enough.

EDIT: Whoops forgot to mention why the recovery mode data/factory reset. It formats the user data areas as well as the application area, and is far more thorough/secure than the one inside of the android OS and will prevent you from download junk data. It just flat out gets rid of it.

To get to the recovery console on the Nexus 5 for resetting:

If your phone is on, turn it off.
Press and hold the Volume Down and Volume Up buttons, and then press and  hold the Power button at the same time until the phone turns on. You'll see the word "Start" with an arrow around it.
Press the Volume Down button twice to highlight "Recovery."
Press the Power button to start Recovery mode. You'll see an image of an  Android robot with a red exclamation mark and the words "No command."
While holding the Power button, press and release the Volume Up button once.
Press the Volume Down button twice to highlight "wipe data/factory reset" and press the Power button to select it.
Press the Volume Down button seven times to highlight  "Yes - erase all user data" and press the Power button to select it.
After the reset is complete, press the Power button to select the option to reboot your device.


What is the purpose of the Volume Master Key in BitLocker? From this FAQ, I understand that BitLocker uses the following keys to encrypt the hard-drive:

Full Volume Encryption Key (FVEK) (used to encrypt raw data; encrypted by the volume master key and stored on-disk)
Volume Master Key (VMK) (encrypted by a key protector and stored on-disk)
Key Protector (KP) (TPM or numerical password)

I don't understand what security value the VMK provides. Why not just encrypt the FVEK directly using KPs?

In any case, if a KP leaks, the FVEK can be obtained anyway?

I was wondering about the same thing myself, did some googling around, until found the answer here:
BitLocker : Update Volume Master Key and meaning of "keyed" vs "re-keyed"
Microsoft's docs

Basically, use of intermediate key (VMK between FVEK and KPs) is to allow the change of keys if KPs are compromised without the need of re-encrypting the (encrypted) data itself.
KPs compromised -> create new (KPs and) VMK -> encrypt old FVEK with new VMK

Then, attacker with old KPs will get to the old VMK and trying to decrypt the encrypted FVEK won't work (because it was re-encrypted with new VMK). Of course, depends how quick the attacker is and other circumstances.


Evaluate the signature of an X509 certificate in .NET This is my scenario:

A CA signs a certificate with its private key and sends it to a client via https response. From this response the client creates a X509Certificate2 class, that represents the certificate in .NET

X509Certificate2 myCert = new X509Certificate2(certBuffer);

I also have the CA's public key to verify the signature

RootCertificate.PublicKey.Key

I am now looking for a way to check if the signature is valid. How can I do that? The X509Certificate2 class doesn't seem to provide a way to access the signature field.

X.509 certificate validation is a complex process. With .NET, you are supposed to use the X509Chain class to perform such a validation, which entails path building, verifying signatures, revocation status, and a gazillion of other things. See this answer for an example.

X509Certificate2 also has a Verify() method, but that one checks the certificate with regards to the machine defaults: the user's trust store, the user's policies... which may or may not map well to your specific case. To have full control on the process, use X509Chain.

(Extracting the signature value, and the exact byte sequence which is signed, is not overly complex if you know a bit of ASN.1/DER, but the point is that there is much more to certificate validation than mere signatures. Doing things manually is a path which I have personally walked several times, and it entails a lot of suffering. Using the implementation already provided by .NET will save you a lot of time; and that implementation is X509Chain.)


When to request refresh token? JWT I am trying to implement JWT in a secure way in Node.js and I am unsure when to request the refresh token.
I got one access token and one refresh token. Both are saved in two httpOnly cookies. When the access token expires the refresh token should check for a new one.
Right now I have implented it so that if the refresh token fails to validate the access token (if (err)) It requests the refresh token. The refresh token is then checked against the database and issues a new access token as well as validate the user for the route.
Is this a correct way of doing it?
I read somewhere that the refresh cookie should be set to a specific path instead for more security, but if so how do you call it when the access token expires?

A few thoughts:

Cookies aren't a great place to put refresh tokens at all, really. They're not the worst, but it's more common to use Local Storage and only ever transmit them when you're using them. Of course, they are script-accessible that way, but HttpOnly is actually very minimally useful as a protection and you need solid protection against XSS anyhow. When you want to use the refresh token, you POST it to the relevant URL.

Relatedly, I hope your cookies have Secure on them and are set to the right domain; and are ideally also SameSite; those attributes are vastly more important than HttpOnly. Not that HttpOnly is bad, it just doesn't do much. You can totally take over a session via XSS even if you can't read the cookies.

You say

I have implented it so that if the refresh token fails to validate the access token

I assume you mean if the server fails to validate the access token. Refresh tokens aren't code, or usually even structured data; they can't validate or even be used to validate anything else.

The method you've described is simple, in a way - the client neither knows nor cares about the refresh token and just occasionally a request takes a little longer than usual and comes back with a new Set-Cookie header or two - but it does require putting all the security-sensitive values into cookies and sending them with every request, and it means never pre-emptively refreshing the access token.

For clients that actively refresh (e.g. by POSTing the refresh token to the server's /refresh endpoint), there's two ways to know when to do it:

Do it when a request comes back with access denied. This requires that the whole site's interaction with the server be script-mediated (done through XHR/Fetch) but that's common these days and you can put a common wrapper around that API which checks the error case for that specific problem and initiates a refresh.
Do it on a timer, e.g. 90 seconds before JWT with a 10-minute lifetime expires, or perhaps cut it even closer if you don't expect peoples' computers' clocks to be off by very much. Requires knowing when the session token will expire, but that's easy if you can either read the JWT directly (it's a plain-text field in the JWT) or if you simply note whenever you successfully authenticate or refresh and just setInterval at that time if there isn't one already running, or setTimeout each time.

If you want to go the client-opaque route (via cookies or similar) but still want to do pre-emptive refresh, that's pretty easy too. Your server simply checks the expiry time in the JWT when validating it - that's part of the validation process anyhow - and if it's within some small window of its expiry but still valid, the server also tries to refresh the access token while serving the request. This can be done asynchronously, possibly on another thread, to avoid slowing down serving the actual request. (If the token has already expired, you need to confirm a successful refresh before starting to actually serve the request, which will slightly slow things down depending on how long a refresh takes.)

Sending both the access token and the refresh token on every request isn't ideal, but from a practical perspective the security model of a web app or web service is already predicated on both the connection and the server being secure. As such, it's not a meaningful vulnerability to transmit the refresh token more often than needed. Additionally, it still lets you get the primary benefit of JWTs (stateless authentication and authorization data that doesn't require either tons of DB hits or load-balancer-unfriendly caching) while addressing their biggest weakness (difficulty of revocation/cancelation meaning their lifetimes need to be short and some other, longer-lived token needs to be use for periodic refresh).


Safe to store API keys in session? Scenario:

App is hosted on a shared server (hosting provider can see config files if they want to).
App must use an API key of a 3rd party service.

Considering this "tight budget" scenario, would it be better to enter the API key every login and store it in a session variable instead of storing it hard-coded (e.g., inside config.php)? Or what are better ways to store 3rd party API keys inside your software?

No, storing it in a session variable isn't going to protect you against your hosting provider stealing it.

The session variable will either be a cookie sent back and forth with every request or a server-side session. Either way the server has access to the key and anyone who controls the server does as well.

So it doesn't add security, sounds like a major inconvenience and could expose you to other threats (like leaking the cookie to a third party).

As a general rule of thumb, API keys should be accessible to whoever's gonna use them. If the server is the one using the key, the client has no business with it.

You could store it encrypted on the server and decrypt it with your login information upon login. It's still security theater, but at least it doesn't inconvenience you (the user) beyond the initial setup.


Does hashing a file consider its digital signature as well? I have a signed (using Windows signtool) executable which is hashed by SHA1 algorithm and encrypted using RSA. Now I like to verify the executable to avoid security vulnerabilities. For that I have an idea to get the hashing algorithm from the digital signature and hash the signed executable again and compare it with the decrypted Hash using the public key found in the certificate. Would both the hash be equal, since:

Decrypted Hash from in signature: Hashed only the binary
Hashing: Hashed the binary with digital signature.

I also really would like to clarify that ,can we retrieve encrypted hash from digital signature. If so how?

Update
I've just understood what you're actually asking. I'll leave the old answer below, just in case someone needs that.
 The Answer:
The signtool application allows you to specify an option named 'verify'. You don't need to get access to the encrypted hash value, it will verify it for you. It probably isn't possible to do it manually if you prefer. Maybe when you use the verbose mode at the signing time it will show you the hash value, in case you really want to see it.
Signing only the binary sounds like a good idea if there wouldn't be any metadata files/ configuration/ anything that doesn't compile. I didn't use Windows for a while, but maybe you can use makecat instead of signtool, I think it should allow bigger app sizes. Hope this helps.

 The old answer, explaining technical things:
It looks for me like you are trying to understand how digital signatures work and how you can implement the mechanism. If I'm wrong, please rephrase your question and try to explain step by step what you are doing, as for an algorithm pseudo-code. I will try to explain what I think you want to know.
When you sign a document: you can read the document (so it's not encrypted), you just want to make sure it's valid so you look for its signature and stamp. The signature and the stamp tell you if the document is valid/ verified. In the same way, when you use digital signatures, you always send 2 pieces of data: the executable in your case (not hashed, not encrypted, you can "read" it) plus the signature. So you have the executable, you don't have the signature.
To create the signature:

hash the executable. The executable is usually large so it would take a lot of time to encrypt it. Luckily, if you use a good hashing algorithm, there is an infinitesimal probability that 2 files will give the same hash string. So you can be sure enough that the hash represents your executable (even if it's just a meaningless string) and use it instead of using the whole executable further in this process.
generate a pair of private-public key. Your certificate will contain the public key and the private key must be kept secret. The nice thing here is that you can always encrypt with any of the public key or private key and decrypt with the other one. Never in a different way or with a different key. So if you know for sure that the public key belongs to someone (the certificate is trusted), then if they encrypt something with the private key, then you can decrypt it using the public one. If anyone else encrypted the data, because the private key is secret and they don't have access, whatever key they generated they use, you won't be able to decrypt it.
encrypt the hash with the private key generated at step 2. The value obtained here is your signature.

Now that you have both the file and the signature, send them to the other end or use them however you want. Once the information is received on the other end, how do they verify that it's valid? They have the document, they only want to be sure it wasn't changed by someone else. They also have the signature. So they follow the following steps:

decrypt the signature value using the public key (the certificate). If they cannot decrypt the value, then someone forged the signature (they changed that value with another one). If they can decrypt it, then they know the signature is the valid one. After decrypting, they obtain the hash value of the executable (step 1 above, when creating the signature). They know this hash value identifies the valid executable. This is the source of truth.
hash the received document (the executable) with the same algorithm as used when creating the signatures. When using a good hashing algorithm, no matter how many times you will hash the same document, the obtained hash value will always be the same. So if the document was not changed, the hash value will be identical with the one obtained at step 1. If they are not equal, it means that now when you hashed the received document, the hash value was different so the document was modified/ replaced by someone else. So you cannot trust it.
verify if the 2 hashes are equal (if they're not, as explained at step 2, the document is not the true one, it was modified by someone else). If they are equal, you can trust both the document and the signature.

This steps should also answer you how you will have the hash values being equal and how will receive the hash value from the signature value.
One last thing, please use secure algorithms, such as SHA-256 instead of SHA1 at the very least and eventually (not really necessarily) EC instead of RSA.


If I use a VPN such as IP Vanish on my office network, can they see If I use a VPN service such as IPVanish, will my browsing history appear in office logs. My office sometimes checks on User's network activity to monitor various things. Will using a VPN service hide my activity?
On occasion they've been known to use quite a bit of data...such as user's messages sent on sites.
Will using a VPN hide hosts visited (SSL can hide the request body, not the host itself)

Nothing is really safe, and from the sound of it, you're using a system that you don't control, to access systems the network administrator or management is trying to prevent access to. It's not in their best interest for any of these types of connections.

That being said, outside of any legal concerns that might develop (intellectual property transmission, etc) if it's your personal machine that you're using with VPN then you should have an encrypted channel to the IPVanish servers. That being said, since you don't control the network, you could be victim of a MITM attack if your company wanted to decrypt your traffic. There are systems such as SSL off-loaders that could be used and if you access the system via special access point or through a corporate proxy, then you could have other issues in regard to decryption. Additionally you'll want to watch out for DNS requests going through non-encrypted channels. If this is the case your company can see where you're going, they can't see what you're saying or sending.

If you're using a company computer, depending on the local laws they may be able to track everything you're doing via the use of keyloggers and snapshots of the system depending on what system is running, and whether they allow remote access and monitoring on that system.

If corporate policy is not to do this, then you're likely in violation of that policy. At any rate they will be able to see that you're connecting to a VPN over the corporate network's firewall (if they have IT who are savvy enough). Additionally they will likely feel any bandwidth the VPN connection is using, as all of your traffic will require more bits to transfer depending on the encryption level.


Should hashing algorithm used for X.509 certificate's signing match the algorithm used in the communication I've seen this but the related answers don't answer my question.
For TLS 1.2 is the hashing algorithm specified in an X.509 certificate's cipher suite used for the signature inside the certificate or the TLS handshake/communication process or both?
I'm in the process of replacing an old self-signed certificate used for WCF client/service authentication (not encryption) because it doesn't work with TLS 1.2 with SChannel.
The old certificate has the following parameters in the Details tab in Windows:
Signature algorithm: md5RSA
Signature hash algorithm: md5
Public key: RSA (1024bit)
Thumbprint algorithm: sha1
Is the Signature algorithm above the same as the hashing algorithm of the certificate's cipher suite or it's unrelated?
If it is then does it mandate the hashing algorithm used during the client server handshake / communication or is it just for the signature in the certificate itself or both?

The two are unrelated.  It's possible for the hash function used for the certificate signature to be different from the hash function used for data integrity during the TLS handshake.  However, SHA256 is often used for both nowadays, as earlier hash functions (e.g. SHA1, MD5, etc.) are thought to have weaknesses, and SHA256 is now widely supported for both uses cases.


Can windows domains be faked? Without the equipment and software (and knowledge yet) readily available to test myself, I've been wondering about the relationship between computers and domains in a Windows environment. Some information is available in answers like https://security.stackexchange.com/a/83380/58802, but I was thinking about other things, like:

What information, like the computer SID and stuff, IDs a computer to a domain?
I assume this information can be faked or replicated, but can it?
If so, is that a security issue?

Like, if I have a computer that's authorized for a certain domain, and wipe it clean, assuming I took note of whatever locally stored information that is relevant to the case, could I restore the authorization to the domain for my computer, without explicit privileges to administer the domain?

I was also thinking about the-other-way-around-scenarios:

How does a computer "identify" a certain domain?
Can the domain be "faked"?

I'm sort of asking if it's possible to trick a computer into "believing" it's on the supposed domain, but it's really not, enabling scenarios where inappropriate policies are forcibly applied and stuff.

I'm asking these questions in the interest of better understanding the security workings of a windows domain (and similar), even though it's really not my main area of competence, and I hope that someone with the proper knowledge will find educating in general to be good cause enough.

Thank you before hand.

The technology you are looking for is Kerberos. It allows for a secure, mutual trust between objects in an Active Directory (in your case - the AD controller and a host, member of the AD).

Microsoft has a few comprehensive reviews of how it works. This one is from 2009 but the concepts are the same.


Question about ipsec prevent SYN flooding attack how IPSec prevents SYN flooding attacks Like if A is sending packets to B using IPsec. Suppose B’s TCP ack gets lost, and A’s TCP retransmits the packet since it assumes the packet was lost. Will B’s IPsec implementation notice that the packet is a duplicate and discard it?

IPSec does not prevent SYN flooding. IPSec is a VPN at the network layer (i.e. IP) and not the transport layer (TCP, UDP). It will transport any IP packets and not look deeper. But since SYN is a capability of TCP and SYN flooding an attack thus at the transport layer a pure IPSec VPN will not detect SYN flooding.

Of course you could augment an IPSec VPN with additional software or hardware to detect such attacks the same way as you could augment plain (non-VPN) IP networks this way. Though it will not be possible to detect such attacks within the encrypted IPSec traffic but only in the decrypted traffic.


how can I bypass recaptcha while using python requests? How can I bypass the recaptcha on a website with python requests so that I don't have to solve it?

You asked a very interesting question that I am going to give an interesting answer too.
You can not bypass a recaptcha, unless as @schroeder stated, where there is a weakness or an option on the site where you can bypass it.  You might have to do some experimenting to see and find out if this is the case.
A more exact solution involves multiple requests, as well as requests to other websites.  First make a request that causes the recaptcha to appear.  Then take the received info and send a web request via python, to a re-captcha third party solving service, that accepts recaptcha question data from online requests.  Then from the answers you get back from them, send that as requests via python back to where it answers are sent for recaptcha questions.  This way you are solving the recaptchas by sending requests via python.  hYou still are not bypassing, however you are sending requests via python to get thru the recaptcha.
Another solution for python might be able to solve the recaptcha, and send a request so that the recaptcha is passed.  Basically when you solve a recaptcha, your results are sent via POST request.  Although not exactly a 100% answer to your question, but it does involve sending requests via python.
Solving the recaptcha in using python however would require intense machine learning, precise image recognition, and AI programing knowledge, most of those are probably still not yet at par 100% to successfully do every captcha.  Also, the recaptcha was designed also to be difficult for bots to solve even.


IP Restricted OTP like Web Admin Authentication Safe or Not I created a web admin panel with the following security implementation.

It is located on a sub directory of the web, which will trigger a 404 Error when tried to access (just like the link is broken or doesn't exist).
This (only if correct sub directory is opened) in turn sends an email to the administrator, with a url, which has a token.
The token is of 2 parts, one is a random md5 of 5 random 5 digit numbers, another one is a md5(strrev(md5(IP_ADDR))). The token is saved in the database by invalidating all the other sessions.
These tokens are separated by a _ sign.
When admin (or anyone) tries to access the URL, first the IP token is matched whether the same IP is accessing the URL. If not, 404 page is shown.
If yes, then the random token saved on database is matched against the one which was sent on mail. If this is also successful, the admin panel opens.
Any invalid try will show 404 error.
This token will automatically get invalidated for every 20 min, thanks to the cron job.

Provided, the email can only be opened by the administrator of the website.

What could be the flaws in this implementation? How can this be improved?

There is unlikely to be a single answer to this question as each may cover different flaws. Here are some, only concerning token derivation and use of 404:

The second part of the token can be directly calculated by any adversary as they know their own IP address. It can therefore be removed without reducing security.

The use of a hash in the first part of the token does not add any security value, but increases overhead (although likely negligible, it is still pointless). The point of the one-time password is that it is difficult for an adversary to guess the randomly-generated value; hashing the value does nothing to increase the difficulty as an adversary needs to guess the 5 original numbers or the hash.

The guess-space with the former is 1e25 values as one can simply concatenate all numbers. This is equivalent to log(1e25) / log(2) = 83.05 bits; you do not magically get MD5's 128.

Do you need to increase this? My guess would be that a brute force attack would sooner DOS you, but there is little harm in using more space so go for it.

The use of 404 errors is security by obscurity which is not security.


Certificates with no sysadmin skills? I am coming from a web application developer career, so no sysadmin skills. But I also like security topics.

I was wondering if after getting a certification such as GIAC, GPEN or EC Council CEH, or any other pentesting certification would make me legitimate or at least job-ready for the skills they are supposed to teach?

No, I don't think that the certification itself will make you legitimate and/or job-ready. However, you can learn a lot while preparing yourself for those exams. You haven't stated what you try to achieve, but by simply attaching a certification or two to your application, will not make you a great and experienced infosec guy, and every big/serious IT company knows this.

Don't get me wrong: It is definitely helpful in getting across your experience, but in the end there will be job interviews and you'll have to prove that you can stick up to the claims made in your CV. So, while it might be a good door-opener and a good foundation to start the discussion, you still will be asked about previous work experience, etc. Nobody will take it you for real, simply based on some certification attached to your application.

Unfortunately getting a decent system administrator is nothing you can learn and be done with it. It is a process of learning from mistakes you (and others) did. If you want to switch into this area (system administration, security) you should start small-ish, with some test setups / environments, read about it and shouldn't be too picky about any job.

I would argue, that Working in the infosec area is even more challenging. If you are seriously interested in it, just start to look into it, work through some material (there is a ton of it available) and try to apply it to some software you like. While doing this, you might get some attention from the company you want to work with, and applying for a job with them, might be become easier in the future.


Who uses linkability-based survellance - other than mil intelligence? Because of what I see as degrading internet conditions, security/privacy wise, I'm doing my own evaluation of how I need to react towards this in order to keep such crap out of my life, overall.
I'm not living my life in such a way that it is likely to happen. But I'd like to be a little more ready and informed for it than I am today, and at the same time reduce the digital target area if possible.

I'm not too concerned about being traceable by national military surveillance, or authorities in federal/unitary states, because I'm not in any way involved in stuff that would motivate them looking into me - certainly not as a primary object. Their logs of me will just forever sleep deep down their databases, probably never to be seen. My political convictions on surveillance policy overall, that's another discussion.

What I am concerned about, are private actors or organizations, partly in the shades, even some legit security firms, which could be targeting me, or can be hired by companies who .. for example, wish to get rid of their competition (me) using ugly methods, or simply take what I got or do extortion of several kinds (the opportunity makes the thief). Or I might just happen to step on the toes of an extremist organization (like Scientology etc) who will then be set to destroy my life, frame one for crimes etc. Overall some actor which decides to seriously mess up one’s life, take one's assets etc.

One way it is possible to find a person, or find out about a person, is by likability; to interconnect data stored in different systems and services through time, and build a 'digital paper trail' and/or profile from it. To reduce any risk of that, it would make sense to make this 'digital paper trail' difficult to compile, by adjusting one's usage of the internet and services in accordance. My question here is: To what degree?

Surveillance- and police authorities of nations use likability as part of what they do, but it is useful to them basically because they are hooked into lots of different databases and pools of recorded data, plus access to either logs or actors who will provide them with info that they don't immediately have their hands on.

But as mentioned, I'm not concerned about that. So in order to answer "To what degree", I'm trying to inform myself about what other actors in society - and how many - might have or get access to enough numbers of large database systems that likability would be a feasible option for them? Such linked information could then possibly be used, sold, or conveyed because of threats, or loyalty of different kinds. I imagine there could potentially be a lucrative market selling information of that kind, even if it is borderline illegal, sometimes even if strictly illegal.

Overall I’m trying to learn about what digital probing resources are there out there, legal or shady, for a determined but non-governmental actor with low morality and cash to spend? This, in order to answer to what degree would I need to adapt my internet service usage, in order to minimize the possibility of gathering a papertrail?

I'm not sure what your actual question is, but it seems these days a bunch of kids on 4chan can do a better job enumerating and uncovering your identity than most of the 3-letter government agencies.

  to what degree would I need to adapt my internet service usage, in order to minimize the possibility of gathering a papertrail?

The Tor project covers this in depth, but here are some obvious points to consider:

Always use an adblocker/noscript plugin. Social media sites and advertisers track your browsing patterns by tracking what assets of theirs you hit, and from what sites. This data can be subpoenaed.
Never use OAuth where it is presented as an option. You create a central map of all of your accounts on the Google/Facebook/etc database, which could be subpoenaed or enumerated via social engineering.
Never use the same identity twice. If I search for "Seraglio" in the context of paranoid anti-surveillance and/or conspiracy theories, I shouldn't be able to find other comments you've made about the subject or your interest in overthrowing the government. Every account you make should be disposable and created from an IP address/email address that has no connection to you.
Never use the same password twice (or, the corollary-- use only the most obvious, dumbest, easy-to-guess password possible: i.e. "password123"). Once a site gets popped and your password is known, if it happens to work on another site there's a high likelihood the two sites have an entity in common-- you.
Never use the same IP address twice. Use Tor for as much of your traffic as possible, and route across international borders wherever possible (if you can route through Russia or China, you're politically invincible). The guy that ran KickAssTorrents ultimately got busted because his domestic IP address on iTunes matched an IP address used to log into the KAT Facebook page (which means data got subpoenaed or leaked from both iTunes and Facebook).
Don't use avatars ever, especially on Gravatar (SE uses it). Don't even post a cartoon or video game illustration. Reverse image search can dig up everyplace it's ever been used, which helps the entity resolution process.
Try to stay off the grid. The credit bureaus track every address you've ever been associated with by virtue of all of your utility connections, credit applications and more. The good news is federal law mandates your consent, so if someplace says they're going to run a credit check on you, even if you're not trying to borrow money, your current whereabouts are being uploaded and updated the time of the request. Criminals regularly exploit this in the case of fraud, but either way this information is regularly subpoenaed.

Total anonymity is a myth (everything leaves a digital footprint, and the US government allegedly owns a not-insignificant portion of the Tor network), so the best you can hope for is to muddy the waters so much that nobody can see who you are through it. Think of it like money laundering, but for your identity.

Addendum:

  I'm not too concerned about being traceable by national military
  surveillance, or authorities in federal/unitary states, because I'm
  not in any way involved in stuff that would motivate them looking into
  me - certainly not as a primary object. Their logs of me will just
  forever sleep deep down their databases, probably never to be seen. My
  political convictions on surveillance policy overall, that's another
  discussion.

  What I am concerned about, are private actors or organizations, partly
  in the shades, even some legit security firms, which could be
  targeting me, or can be hired by companies who .. for example, wish to
  get rid of their competition (me) using ugly methods, or simply take
  what I got or do extortion of several kinds (the opportunity makes the
  thief). Or I might just happen to step on the toes of an extremist
  organization (like Scientology etc) who will then be set to destroy my
  life, frame one for crimes etc. Overall some actor which decides to
  seriously mess up one’s life, take one's assets etc.

You're being naive. Scientology, et al. have friends in high places.

The government may collect a bunch of data on you and do nothing with it, but APT actors are always targeting government and defense contractor assets, and if they get their hands on that data, then all bets are off as to what could be done with it.

Driving on the road, you're fairly anonymous-- only your license plate number is known to those around you. But if someone with a friend in LE gets them to run the plate, now someone you may have offended on the road has your name and home address.


JBoss Web vulnerabilities In my organization I found servers running JBoss Web/7.0.13.Final and JBoss Web/7.0.12.Final.

I could not find security vulnerabilities for this server's versions, but they seem old to me.

How can I find JBoss Web security vulnerabilities (CVEs, etc.)?
I understood that JBoss Web is based on Apache and Tomcat. Does JBoss Web version x.y.z has the same vulnerabilities as Tomcat x.y.z?

Notice that this is not the common general question about finding CVEs for some products, but specifically about JBoss Web. If one can find the CPE for JBoss Web vulnerabilities, or to give a reference to JBoss Web vulnerability - it will help. I could not find such vulnerabilities in NIST and all the classical resources.

You can check your applicationss vulnerabilities here (for example): cvedetails

or in the NIST's VDB

If you found some vulns, then you can test with some penetration testing tools. Most of time you can easily find an (if it exist) exploit for vulnerability in MetaSploit Database or in Google.

And for other question:
(RedHat)JBoss Web and (Apache)Tomcat doesn't same thing.

  Both JBoss and Tomcat are Java servlet application servers, but JBoss
  is a whole lot more. The substantial difference between the two is
  that JBoss provides a full Java Enterprise Edition (JEE) stack,
  including Enterprise JavaBeans and many other technologies that are
  useful for developers working on enterprise Java applications. Tomcat
  is much more limited. One way to think of it is that JBoss is a JEE
  stack that includes a servlet container and web server, whereas
  Tomcat, for the most part, is a servlet container and web server.

You can read more here

So no, both of them has different vulnerabilities.

More related information:
Most of time the vendors of software (if they notice vulns) will announce the issue after fix-patch release. If you working with mostly JBoss, then you should subscribe to RedHat's security newsletters. Its important to take care of security, I think this is the (mostly) fastest way to keep up-to-date my knowledges about vulnerabilities.

(English is not my mother tongue; please excuse any errors on my part.)


Is it ever possible to crack an encryption key character by character? In movies and TV shows, characters are often depicted using devices and applications that are able to determine an encryption key or passcode character by character (or digit by digit).  I am a programmer and think I have a decent idea of how encryption works in general but I'm not sure whether to take this as a simple way to display progress or if there is actually something to it.

Is this ever possible and if so what properties of an algorithm leave it susceptible to this kind of cracking?

If an encryption system allows for character-per-character cracking, then it is awfully weak, and should not be used.

Mathematically, block ciphers are defined as pseudorandom permutations. A block cipher works over the space of blocks of length n bits; such a space has size 2n. There are 2n! permutations over that space (that's a factorial, meaning that the number of possible permutations is huge). A secure block cipher is such that it is indistinguishable from a permutation selected at random, uniformly, in the space of possible permutations: each key is supposed to correspond to such a random choice of permutation, and, crucially, all choices for all possible key values are independent of each other.

What this means, in mundane words, is that for a secure block cipher, either you have the whole key, exact down to the last bit, or you have nothing. Contrary to Hollywood depictions, an "almost good" key does not result in a "blurry plaintext": if even one key bit is wrong, you should get random junk (that is, an output which is sufficiently indistinguishable from random junk that you cannot know whether you are close to the right key or not).

Of course, if the encryption system is weak, anything goes. @Mark cites a case of "splitting" (in WPS) which is an atrocious weakness that can, indeed, be exploited for faster attacks. Padding oracle attacks also work over a byte-by-byte leak which allows for byte-by-byte reconstruction of the plaintext (not the key, but still).

Another, more technical example, is the old PKZip stream cipher: an "homemade" stream cipher which turned out, with all the unavoidability of Death in a Greek tragedy, to be weak; the stream cipher relies on several internal "keys" which can be unravelled one by one. I encourage people interested in cryptography to study that example, because it demonstrates quite well the way a cryptanalyst thinks, and why mere accumulation of operations does not guarantee security; and the attack is light enough to be implemented in practice (total cost is around 238, which is within range of a few hours of computation on a PC with decent programming, not necessarily optimized assembly).

A lot of cryptosystems from before the computer era were breakable on a per-character basis, because they had to be executed by the human brain of the operators, and such tools are not good at using large values or doing a lot of operations. The classical transposition and substitution ciphers (a very large family) tend to fall to character frequency analysis, which is, indeed, a per-character break.


What are some interesting project ideas that use machine learning to solve issues in IOT security? I am interesting in IOT security and machine learning/deep learning. I am looking for good project ideas to work on.
example: http://projectabstracts.com/20138/a-malicious-pattern-detection-engine-for-embedded-security-systems-in-the-internet-of-things.html

IoT security is currently so poor that there are endless opportunities for improving the state of the art using machine learning.

First, pick an area of IoT that you're interested in.  I'd recommend you pick one where you already have existing systems you can leverage, and where monitoring/sniffing tools are widely available.  Do you have a home automation system?  Do you have a car with a CANBUS network?  Do you wear a personal health tracker?  Do you have web cameras monitoring your property?  It's easiest to start when you already know something about the domain you're trying to protect.

Next, develop a simple threat model.  Diagram the system's inputs and outputs.  Identify network protocols.  How is each trust boundary crossing step authenticated? How are the messages protected?  Make some assumptions and do some reading: if you think the devices are simple, and they talk to each other, they might be less secure than if they authenticate to a cloud server, therefore they might benefit from your tool's protection.

Now, see if you can insert some kind of sensor in between the devices and their controllers or clients.  For example, if they're connected via WiFi and use IP, you could attach a bro sensor to the network switch that connects them.  Commercial tools could help here; for example the Packet Squirrel might be a cheap way to sniff packets from the middle of an Ethernet cable.  If the devices talk via RF, can you use an SDR to monitor the airwaves?

The important thing to develop is the capability to collect traffic.  Also, take into account the ways you might analyze the traffic.  Is timing important?  Make sure your packet capture tool has precision timing capability.  Are electrical or RF characteristics important?  You might need  specialized equipment; or at least more sensitive than a $20 RTL-SDR dongle.

Once you have traffic in hand, start applying your analytic skills.  What kinds of patterns are normal?  What kinds of attacks show patterns that are abnormal?  Are there regular time-based packets, where fast or slow responses stand out?  Are there particular sequences of packets that you can consider normal or abnormal?  Can you train your neural network to be silent in the presence of normal traffic?  Can you come up with a generic solution that doesn't generate false positives on several systems, not just yours?  Most importantly, when you attack the system, does your neural network detect it?

Again, you'll probably have the most success if you start with something you already know and enjoy.  Good luck!


Does removing my security questions on Yahoo make me more secure? My Yahoo account was hacked and I am very worried about why. They said I was more secure after removing my additional security questions. Is that correct?

Disclosure: I work for AgileBits, the makers of 1Password, a password manager.

Security questions are terrible. In fact, pretty much everyone who studies these calls the insecurity questions.

First of all security questions are another way into your account. But let's compare their security properties with passwords.

Security answers are not secret

My mother's maiden name is not a secret. Nor is the street where I lived as a kid, nor are so many of the other things that are routinely asked. Sure, some of them may not actually be public knowledge, but if I have to use my father's middle name, I don't want to then be responsible for keeping that secret in the future.
Security questions are stored unencrypted

Passwords have to match exactly because they are typically hashed, but security questions are looked at by humans, so if I answered "walter" for my father's middle name (see, it is no longer a secret), I would be allowed back in with "Walter". But in terms of passwords almost doesn't count:

$ echo walter | shasum
95ea07881ac3ffe8602879232682052c3e93b6d8  -
$ echo Walter | shasum
f82f03f4a76873ff4ae41d6609b99f258a647b82  -

And so insecurity questions are stored unencrypted. Yahoo! did a nice job with using bcrypt to hash the passwords (making it harder for the people who stole those hashes to make guesses at passwords), but the thieves got the security questions.

This also means that the people who manage the system also know your security questions and answers. It's not just external thieves, but internal ones as well who can learn these.
Insecurity questions are even more likely to be reused than passwords.

The people who got hold of the insecurity questions (and answers) can now uses those answers to attack your account on other sites you use those answers for. If you give your father's middle name as "walter" on one site, you are likely to give the same answer to the same question on another.

This, of course, is true of passwords, which is why you should use a separate password for each site and service. If you used a decent enough password, than Yahoo!'s use of bcrypt will mean that many reasonably strong passwords will remain unguessed. So the bad guys may not know your Yahoo! password, but they do know your security question answers. (But do not use things that you would like to keep secret for security questions. Remember that in the best case only the people who operate the service will see them.
Security questions (answers) are less varied than passwords.

The most common 100 pets names are almost certainly going to be more common than the most common 100 passwords.

Almost all of the problems about security questions listed above are a consequence of what they are designed to do. They are designed to be things that you already remember (instead of a new thing you have to remember like a password. And you remember these things because they are the truth. So true things about you are less likely to be secret and there are many more ways to lie than to tell the truth. So the inherent problem with insecurity questions follow from their design.

I'm quoted in an a recent article at WIRED that covers these and points to other resources as well.


VPN - Unique client certificates? Currently installing the OpenVPN service on my Linux box and stumbled across this in a guide:

  All of our clients will also need certificates to be able to
  authenticate. These keys and certificates will be shared with your
  clients, and it's best to generate separate keys and certificates for
  each client you intend on connecting.

https://www.digitalocean.com/community/tutorials/how-to-setup-and-configure-an-openvpn-server-on-centos-7

May somebody please explain why it's important to generate a pair for each client? Are there security risks if, for example, 2 clients use the same pair? As far as I can remember, my school and workplace does offer one pair for all users if they want to use the VPN service.

You can authenticate based on certificate, username/password or by using a combination.

The reason why you do not want to use just a single certificate, without username or password, is that it will reduce your accountability as you can't pinpoint a single connection to a single person with certainty. You can use username and password as a measure to resolve this issue.

It's better  to implement a certificate per client as well as username/password. It will give you a form of 2 factor authentication setup (its effectiveness is debatable if stored on the same computer).

Something the client has: his certificate
Something the client knows: username and password


Why is end-to-end encryption still not default in mails? I am not a cryptographer. Maybe that is why I don't see the issues with integrating PGP into SMTP.

In my head: Lea requests the server of Luke's domain jedi.com to tell her the public key of luke@jedi.com (The request includes an encryption method perhaps). She gets back the key PUBLIC. Then she encrypts the message and Luke can decrypt it easily.

It's not that hard, why isn't it standard for years?

It's not that hard, why isn't it standard for years?

Because that would not have solved the problem that PGP is trying to solve.

PGP is an end to end encryption, so if there is any way for the SMTP server to subvert the encryption, then the scheme fails.

In the case of the scheme you proposed, suppose Alice (alice@charlie.com) wants to send a private message to Bob (bob@dave.com). Using the scheme you proposed, Alice's mail client or Alice's SMTP server fetches Bob's public key by making TLS connection to dave.com. This is fine as long as dave.com are honest and actually return Bob's public key. But dave.com could have been configured by dave.com's operator to return a forged public key created by Eve, or Eve could hack into dave.com and set this up. Now Alice's mail client/mail server would happily accept Eve's certificate, thinking the public key is Bob's. In this model, the operator of dave.com can intercept any of Bob's emails.

Now, as long as dave.com is honest, this still protects against third party spoofing. Why don't we do this anyway if this protects at least against third party snooping? Mainly because SMTPS also provides the same level of protection, while also being much simpler. If MITM by the mail server operator is not your concern, you can already very well secure your emails by ensuring you both uses SMTPS.

Note that the difficulty of end to end encryption isn't about fetching public keys. Most email client that supports PGP also supports automatically fetching public keys from LDAP or HPKP. The difficulty of end to end encryption is verifying the public keys.

There is no known method of verifying public keys that is fully transparent to the users and fully secure. Web of Trust or Certificate Authority model comes closest, but Web of Trust comes with a lot of caveats and Certificate Authority model relies on a third party to do the verification.


Ignoring broadcasts to 10.0.0.255 using iptables I'm trying to drop logging packets that are destined for 10.0.0.255 by using the following rules:

$IPTABLES -A OUTPUT  -d 10.0.0.255   -j DROP
$IPTABLES -A FORWARD  -d 10.0.0.255   -j DROP

It doesn't seem to work. Packages are still flowing through this rule and the DENY of them are getting logged at a later rule. Do I need to anything special when it comes to the broadcast addr.?

Edit: Here is the full rule I use that isn't working:

#
# Rule 2 (wlan0)
#
echo "Rule 2 (wlan0)"
#
# remove local broadcast
$IPTABLES -A FORWARD -i wlan0   -d 10.0.0.255   -m state --state NEW  -j DROP
$IPTABLES -A OUTPUT -o wlan0   -d 10.0.0.255   -m state --state NEW  -j DROP
$IPTABLES -A FORWARD -o wlan0   -d 10.0.0.255   -m state --state NEW  -j DROP

A bit dated, but I felt compelled to help expand the discussion/dialog by introducing the idea of blocking broadcast traffic by demonstrating the capabilities of IPTables to filter layer 2 information as well. Specifically, there's  the -m pkttype --pkt-type broadcast command line option.

Here is an example iptables ruleset that demonstrates this option as well as its resultant output:

IPTables: -m pkttype --pkt-type broadcast

iptables -F

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

iptables -A INPUT -m pkttype --pkt-type broadcast -d 10.0.0.255/32 -j DROP
iptables -A INPUT -j ACCEPT

iptables -A FORWARD -m pkttype --pkt-type broadcast -d 10.0.0.255/32 -j DROP
iptables -A FORWARD -j ACCEPT

iptables -A OUTPUT -m pkttype --pkt-type broadcast -d 10.0.0.255/32 -j DROP
iptables -A OUTPUT -j ACCEPT

RESULTS

[nick@sys]$ iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255          PKTTYPE = broadcast
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255          PKTTYPE = broadcast
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255          PKTTYPE = broadcast
ACCEPT     all  --  anywhere             anywhere

While a tangent, there is another interesting option to provide layer-2 filtering based on (source) MAC addresses, which isn't too useful in this case. However, it is interesting if nothing more than to know of its existence. This is the IPTables -m mac --mac-source  command line option. Practically-speaking this option is declared to make sense on INPUT and FORWARD chains (and not the OUTPUT chain). The concept would likely be of more interest for an ACCEPT, versus a DROP or REJECT, action. In the following brief example I ACCEPT broadcasts from the default gateway, but block all others. In this example I pretend the MAC address of the default gateway is: 00:F0:10:03:15:42.

IPTables: -m mac --mac-source

iptables -F

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

iptables -A INPUT -m mac --mac-source 00:F0:10:03:15:42 -d 10.0.0.255/32 -j ACCEPT
iptables -A INPUT -m mac ! --mac-source 00:F0:10:03:15:42 -d 10.0.0.255/32 -j DROP
iptables -A INPUT -j ACCEPT

iptables -A FORWARD -d 10.0.0.255/32 -j DROP
iptables -A FORWARD -j ACCEPT

iptables -A OUTPUT -d 10.0.0.255/32 -j DROP
iptables -A OUTPUT -j ACCEPT

RESULTS

[nick@sys]$ iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             10.0.0.255          MAC 00:F0:10:03:15:42
DROP       all  --  anywhere             10.0.0.255          MAC ! 00:F0:10:03:15:42
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.0.0.255
ACCEPT     all  --  anywhere             anywhere

In this second example I fully realize that the NOT (i.e., '!') notation for the second INPUT rule isn't necessary; however, it is also a neat feature that can be of some use in this question if selective rejection (or acceptance) is desired.


Making an encrypted SMS app (Android) From my limited googling I've noticed that a lot of the mainstream encrypted messaging apps all are either (or a combination of!) closed-source, run through an uncontrolled third-party server, use a proprietary algorithm, or use out-dated algorithms. In my opinion, this is just straight up unacceptable.

My plan was to build an open-source skeleton app that implements a basic messaging UI, then build a system that handles custom encryption algorithms by way of open-sourced plugins.

I'm hoping that by using a plugin system, users are free to choose which algorithm to use and that the plugins themselves will be facing serious scrutiny by the general security community.

Why I'm posting this here: I currently know very little about how to properly handle encrypted data. What are the weak points in this implementation? How does one enforce open-source plugins?

General notes:

I know that SMS from a service provider counts as a third-party service. I'm thinking of including functionality to point the app at a server of your choice, so you have more control over your channels of communication (though I guess your ISP can still track meta-data and what-have-you)
Initially, my plan is to only support in-person key exchanges (or whatever method of authentication is required). Over time, if the app proves useful and used then the custom server implementation mentioned above could be used for remote authentications

You are reinventing the wheel. I don't think the state of art really warrants creating a new app from scratch (OTOH if you want to do so for other reasons, like practising creating an app, then go for it).

Note that with secure encryption, the third-party server wouldn't be able to snoop on the conversations (albeit it would be able to record metadata). And if it is open-source, you could replace the server quite easily with your own one.

It would be interesting that you detailed the apps you evaluated along the reasons you had for  discarding them, as I suspect the panorama is not so bad.

  I'm hoping that by using a plugin system, users are free to choose which algorithm to use and that the plugins themselves will be facing serious scrutiny by the general security community.

You need a baseline. You can easily end up with users split by their election of incompatible plugins. It is also generally accepted that most layman people make poor security decisions.

What you propose is right as a design, but you could simply offer a single secure algorithm, then upgrad the app with a stronger one when needed.

If the user can point the apps to a server of their choice, how are they going to communicate? Does everyone need to set the same server? What if I have several contacts in disjoint ones? Are you going to design a federated service?

Working on top of SMS has some nice properties, but it also means you have to fit everything at the sms, keep track of the contacts that have the program installed and thus should have the communication encrypted. And that they did not uninstall it or change the terminal. This was a problem for TextSecure (which ended up removing encrypted sms) or even Blackberry when people change terminals.

  the custom server implementation mentioned above could be used for remote authentications

I don't see a mention of that custom server implementation for remote authentication in your question, but I should note that remote authentication is IMHO the weakest part on most of these messaging apps (unlike their encryption itself -when they do have end-to-end encryption-) as the server could quite easily vouch for someone completely different.

Using ids other than telephone numbers (like a key fingerprint) would be slightly more annoying, but preferable in both security and privacy terms.


How can a website find my real IP address while I'm behind a proxy? I just wonder how some website like WhatIsMyIP find out what your real IP address is, even if you use proxy server. It said :

  Proxy Detected

and then they give your real IP address.

Is it possible they use JavaScript to send HTTP request for not using web browser proxy settings(How could it be implemented by Java) or there is some magic technique?

There are several ways:

Proxy headers, such as X-Forwarded-For and X-Client-IP, can be added by non-transparent proxies.
Active proxy checking can be used - the target server attempts to connect to the client IP on common proxy ports (e.g. 8080) and flags it as a proxy if it finds such a service running.
Servers can check if the request is coming from an IP that is a known proxy. WhatsMyIP probably has a big list of these, including common ones like HideMyAss.
Web client software (e.g. Java applets or Flash apps) might be able to read browser settings, or directly connect to a web service on the target system (bypassing the proxy) to verify that the IPs match.
Mobile app software can identify the client IP. Example: PhoneGap plugin


Which one is best, host or guest encryption? Can anyone please tell me which option is better, I mean whether I should encrypt my data at virtual machine level or guest level in cloud? I tried to investigate it but did not find best solution so i thought to start discussion here. Actually I was to protect my guest data but I am not sure what are the possible pros and cons if I apply encryption at one these two options.
It might have nothing to do with practical implementation but it will give us idea about problems that can happen. So to summarize the discussion:

What are the possible pros and cons while implementing encryption at virtual machine or host level?

Any help in this regard will highly be appreciated.

You should do it on a guest level. The main reason for this is that your storage will often not be on the host but on an external storage appliance. Also the flexibility of virualization is is that you can migrate your guests between hosts quite easily, this would be lost if you perform encryption at host level.


How does web site defacement monitoring actually work? I wish to outsource a web site defacement monitoring services to a third party and am wondering how does this type of monitoring work? If my front page has a lot of dynamic components, eg image changes, how can such monitoring detect that it is actually a real hack and not my web editors changing the page for legitimate business purpose?

The problem here is with dynamic pages, because with static you could do a CHECKSUM comparison.

With dynamic you could:

Add HTML meta tag with validation code and checks if it's on page.
Track key elements that allow you to identify major changes, such as in defacements.

I found this website that taks more about some of the ways you can use.


Recognise tool by which file was encrypted I have file with extension *.encrypted. Can you give me some advice how to recognise by witch tool was this file encrypted? It´s not encrypted by some ransomware but by some encrypt tool. When I open the file using a notepad, I can see this: M%Ý~ÝÀ©üŒ]ÏùfB€d€N¯à’ßÌ•¤Ü]ñåo

Unless the application encryption sticks "something" (header, a magic token, etc...) on the header in general it is not possible to know which was the application that makes the encryption.


If an attacker has the ability to modify data transferred over an Internet connection, can he or she affect TLS? Now that Google, Twitter, and some other sites require a TLS connection to access their sites, when you go to http://www.twitter.com it redirects to https://www.twitter.com/. If an attacker had access to your Internet line, could he or she have the connection running over HTTP with a fake version of Twitter?

If a user nearly never checks for a secure connection on sites, and they type "twitter.com" which first checks "http://www.twitter.com/" and not "https://www.twitter.com/", could an attacker modify the HTTP connection to create a fake Twitter website without the user noticing? I'm assuming browsers try the HTTP version first rather than the HTTPS version first, but if I'm wrong please let me know.

Yes, and this is exactly what the SSL Strip attack did, while using the unsecure HTTP connection it transparently turned all HTTPS links in to HTTP links and proxied the connection, if you did not notice that you where not on a HTTPS connection you could easily send confidential data over a unsecure connection.

As a web site admin you can combat this by setting HTTP Strict Transport Security, what this does is once you connect to the site once all future connections to that site will be via HTTPS till the header expires or the client's cache of HSTS sites is cleared, any attempts to connect to HTTP will automatically be redirected to HTTPS.

However this does not protect you if the clients very first connection to your site was intercepted, but it does help you in situations like you describe in your question where the browser tries HTTP if you don't have any prefix added1, HSTS will automatically force that HTTP link in to a HTTPS link if the site is stored in the client's HSTS cache.

1: It is not that the browser that automatically checks for HTTPS if it can't find HTTP. The way it works is the HTTP page will just be a redirect page to the HTTPS page if you hit it.


Providing password review results to auditors The IT Security department is getting audited and the auditor had approached our IT Security team and requests to see results of the password review process, which compares existing database of passwords which are hashed and custom salt against the password policy requirements. If I am not wrong, I should not be providing them these results. Am I correct?

The auditor requested the results of the password review process.

This seems a perfectly reasonable request. The result of the password review process is not a list of all passwords, but rather the information that you have gathered from the process. It could look something like this:

During the password review process, 1292 passwords were audited. 1171 of those passwords were personal passwords, and 121 passwords were for service accounts.
Out of 1171 personal passwords

58 passwords were found on publicly available leaks
25 passwords could be cracked within 24 hours
additional 7 passwords could be cracked within a week

The remaining 1081 passwords (~92.31%) could not be cracked within one week using a cloud computing platform.
[... more stuff goes here ...]
In order to improve the situation, measures will be taken to compare user passwords to known leaked passwords and reject the password in this situation.

This way, the auditor can be reasonably certain that you actually conducted a password review process. For a more in-depth audit, the auditor may want to see more documents regarding the process, such as your requirements for a secure password, how the cracking was conducted, etc.
However, no serious auditor would ever require to see plaintext passwords.


Client code tampering detection I have a server in a trusted environment. This server handles requests from clients in an a non-trusted environment. I'd like to authenticate each request and to know if the client code has been tampered or not.

Client software is installed in a secure environment and if I generate some 'secret' (nonces or pseudo-random numbers) and don´t store it in the client, it can assume to be safely-kept.

I thought about using a modified one time password (OTP) with the secret generated at installation time. I could include time syncronization at the client machines as a requirement. The OTP secret key would be derived from the client software md5 hash and maybe some form of hardware id at installation time.

Is there a industry standard way of doing what I want? I really dislike the idea of rolling my own, since I'm hardly qualified to do that.

What you are trying to do is a great challenge and currently isn't possible.  There has been some discussion about using TPMs to provide a vendor locked trusted environment that could be used as the basis of such a system, but the problem currently is that an untrusted system can not prove itself trustworthy since any inspection a trusted system could do could be faked.  You have to have some trusted subsystem on the client that can do the validation actively.  When all you have is a request from the client, you lack the access and level of trust necessary to achieve your goal.


How does Ransomware use vssadmin.exe with admin privileges I am doing some research about Ransomware and their methods. In many articles they write that the ransomware performs vssadmin.exe to delete shadow copys. And I found following Information about how they bypass the problem that admin privileges are needed:

  "As this program (vssadmin.exe) requires Administrative privileges to run, some ransomware will inject themselves into processes that are running as an Administrator in order to avoid a UAC prompt from being displayed."

My question is, how do they inject themselves into those processes? Any Links or Information about this would be great.

There are many process injection techniques, there is no standard way used in all ransomware.

Some of these techniques:

Classic Dll Injection Via Createremotethread And Loadlibrary.
Portable Executable Injection (Pe Injection) Process Hollowing (A.K.A
Process Replacement And Runpe)
Thread Execution Hijacking (A.K.A    Suspend, Inject, And Resume
(Sir))
Hook Injection Via Setwindowshookex
Injection And Persistence Via Registry Modificatio (E.G.
Appinit_Dlls, Appcertdlls, Ifeo)
Apc Injection And Atombombing
Extra Window Memory Injection (Ewmi) Via Setwindowlong
Injection    Using Shims Iat Hooking And Inline Hooking (A.K.A
Userland Rootkits)

The following link describes all of the above techniques.


ASLR in Ubuntu 11.10 In many of the exploits I see nowadays, brute forcing is a common method of bypassing ASLR on 32 bit machines. However, many of these exploits crash the current process, for example, PHP. Isn't the process re-randomized as soon as it crashes and wouldn't this prevent brute force attacks?

I am not aware of a single exploit that using "brute forcing",  the chances of this working on a 64 bit linux system is about 1 in 16^8th,  which would never happen.

The most common forms of ASLR bypass are Heap Spraying and ROP chains (and there are others).  ROP chains being by far the most popular method for exploits found in the wild (which basically means found in metasploit).


Are there any tools/methods to probe a web app from diffferent IPs? I am currently reading "Metasploit: The Penetration Tester's Guide" and I came across the following paragraph in the book (in the 1st  chapter)

  During intelligence gathering, you attempt to identify what protection
  mechanisms are in place at the target by slowly starting to probe its
  systems. For example, an organization will often only allow traffic on
  a certain subset of ports on externally facing devices, and if you
  query the organization on any- thing other than a whitelisted port,
  you will be blocked. It is generally a good idea to test this blocking
  behavior by initially probing from an expendable IP address that you
  are willing to have blocked or detected. The same holds true when
  you’re testing web applications, where, after a certain threshold, the
  web application firewalls will block you from making further requests.

I can imagine doing this using the Tor network or may be a proxy (or may be a bot  network, provided you have one :-P ) but honestly, I am not aware of any tools by which I could scan a web app, and if I get blocked, I could generate a new IP and do the scan again.  Are there any tools/methods which let me do so. Please pardon my lack of knowledge, it really feels like a foolish question but I don't know if such tools/methods exist.

I have read the book, and I also have a good example of a web app blocking traffic from certain IPs ..

You can spoof your source IP address the way you want but you won't get any response because once the forged TCP/UDP packet reaches your target (assuming it makes it through firewalls) the reply will be sent to that FORGED IP address and it will never reach you.

You will have better results using TOR as you mentioned!


Secure onion router setup I would like to setup a Raspberry Pi as an onion router, but I have some questions about it.

At home I am using a Fritz!Box to connect to the outer world (to the net of my ISP). Would it make any sense to put the RasPi behind such an router when it runs as onion router.

(I would like to still be able to access this obscure outer world outside the Tor network with other devices - depending on the sense and security at the same time or at different times but without time consuming reconfigurations.)

How should I setup certain firewalls (in general and for this certain case)? (Firewalls on terminal devices as well as on the routers)

@Edit:
I am not sure if it is a good idea to change the question - the question shows that I have a certain lack of expertise in the topic. I saw/googled other questions concerning TOR that had negative votes but showed that I am not the only one with certain problems to understand the context. I think it is important to keep this questions for people who are new to the topic as I am. (For example I wasn't sure in which way a TOR Router and a relay node correlate and also about the exact rules I am able to apply - can an relay node which I use as entry node prohibit other users to exit the TOR network. Would it be suspicious when I am the only user accessing and exiting the network over this node? I mean I know how Mixes/Mix-Networks work but I have several knowledge gaps concerning TOR and as I am not in a community where I can ask people in person I will sometimes ask imprecise questions.

I basically ask these questions to fill my knowledge gaps and to understand which risks are there and how to prevent them. Just knowing about the algebra and certain security/authorization/authentication/encryption/signing/anonymization-protocols and even formal methods to find vulnerabilities in protocols doesn't really help in practice.

The first thing that comes to mind from a network security stand point is ensuring you have a solid DMZ in place. The DMZ is the ideal network location for you to separate your internal home devices from your devices that you would like to speak directly to the internet.

Your network stack would look something like this:

ISP
MODEM
Firewall/Router (Or firewall then router if using separate equipment)
DMZ
Firewall (same options as number 3)
Your internal network

By using this kind of set up, you reduce your risk of internal impact to your private network devices which should NOT serve information to the internet. Even if your DMZ is compromised, attackers would then need to traverse an additional firewall and router system to get to any of your personal data.

Now, you can technically use the Fritz!Box to setup a DMZ and have a single router configuration. This would be a cheaper alternate to setting up two different routers and having to configure your network hops from router to router. Instructions are below:

https://en.avm.de/service/fritzbox/fritzbox-7581/knowledge-base/publication/show/131_Setting-up-a-DMZ-with-the-FRITZ-Box/

My only concern is that most consumer grade routers today fail security tests regularly, and I'm not sure that you'd want one single point of compromise for your entire network. Then again, I like tinfoil hats a lot and they tend to keep me employed!

Finally, opening yourself up to Tor traffic can be exciting, but it also invites scrutiny from governments that you may not want. You are also allowing illicit traffic to flow through your network, even if that's something you're otherwise against. There are many ethical issues to sort through as you become a member of the Tor relay. That's not to say all people who work on Tor are bad (in fact there are many legitimate uses), but it is still something to consider.


Are there any tell-tale signs of self-hacking? After the Mt.Gox crash, and also keeping in mind recently published attacks on Target and Neiman Marcus, one is led to believe that sometimes so-called hacking is perpetrated by insiders.

What are the tell-tale signs of an insider-led compromise as opposed to break-in by outsider threats? Please limit your arguments to digital forensic evidence from the affected systems, and not from suspects' personal computers/mobiles etc.

Is it realistically possible to cover the traces of insiders in a compromise completely?

The only reliable evidence of an internal person attacking your systems is if you catch them with their fingers on the keyboard.

People often suspect insiders because they have spent an extraordinary amount of money building extremely sophisticated defenses, and they simply cannot imagine a hacker being able to navigate them.  They have grandiose releasing processes that assure that only code that has passed through QA will be released into production.  They have firewalls blocking attackers, NDIS scanners looking for attacks, anti-virus tools at all the endpoints, and DLP tools to watch for data exfiltration activities.  They have all the right processes, best practices, projects, plans, spreadsheets, audits, and endless checklists.

Meanwhile, the hacker doesn't know about any of this stuff.  They simply exploit a hole, and escalate their privileges; then laterally move about the network using stolen credentials appearing like any other legitimate user.  Eventually they find their way to a machine that contains valuable information.  They either use customized, modified tools that don't trigger AV or NDIS scanners, or they use the OS's own tools already present on the victim's machines.  Once they find the data they're looking for, they encode their stolen goods to avoid DLP tools, camouflage it to make it look like ordinary traffic, and ship it out.

When you've invested so much in building a security system that appears formidable, it's hard to believe that the attacker can be anything but an insider.  Instead of leaping to the assumption that it's an inside job, it's your duty to keep digging until you find the actual trail.

Your best bets are going to be searching through independent logging servers, ones where the attacker may not have had access to corrupt the logs.  Once you've identified the credentials, track back to the machines where those credentials were used, looking for the evidence of the attack.  Router, NDIS, or firewall logs are also going to be helpful.


Can we track sniffers in a network? It is very simple to launch Wireshark in monitor mode and listen to connections in the host network.

I have come across a program called SniffDet. Is it an all round solution for finding sniffers on a network or is there a better program/way to do it which I am missing out?

NMAP has a sniffer-detect script built-into it, it's probably the most simple solution out there. I have seen no comparison of the two tools on their effectiveness.

Note that all these solutions do is try and find interfaces running promiscuous mode, there are many ways to sniff a network which would leave no traces at all, for instance taps and spans.


This protocol is vulnerable, but why? I know that the following authentication protocol is vulnerable, but I can't understand why.

A and B share a secret key K (64 bits)
R1 and R2 are two 64 bit numbers

A-->B: I am A
B-->A: R1
A-->B: Hash((K+R1) mod 2^64), R2
B-->A: Hash((K+R2) mod 2^63)

My thinking is that the two hashes don't line up, but I don't know that that would make this protocol have a major vulnerability.

Most obviously, it's subject to replay.

Mallory can sit on the line and keep watching authentications R1 and recording Hash((K+R1) mod 2^64).  Any time an old R1 appears, she can reuse the hash she saw earlier.

Similarly, if R2 appears that was seen earlier as an R1, she has a 50% chance that Hash((K+R2) mod 2^63) will be the same (i.e. if (K+R2) mod 2^64 has a most significant bit of 0).


Upgrading security of hashed passwords Let's say we have a database with usernames and passwords, where the passwords are naively secured using a single round of SHA-1 (such as was kinda best practice a number of years ago).

Now, let's say we wish to upgrade the security of the credential storage, but users must remain blissfully unaware that any change is taking place.

Obviously, we don't have the passwords in plaintext, but I am considering just treating the sha1(password) as if it was the plaintext password, and secure on top of that.

Here's my thinking:

Generate random salt per user (128 bit)
Replace "username","sha1(password)" in the database with "username","salt","bcrypt(salt,sha1(password)),iterations=20000"
Change the validation-code to validate passwords by first doing sha1, then bcrypt the result with the salt n times, and then check.

Are there any glaring faults in this strategy?

While not perfect, is it reasonable to say that this vastly improves the security of the users passwords, in the case of a breach?

With this scheme you are certainly making an attacker’s life harder. Here is the general attack algorithm for cracking bcrypt-protected plaintext passwords:

Obtain hashes (obviously)
Generate candidate passwords for password cracking tool
Perform the cracking attempt

And here is the attack algorithm for cracking your sha1-hashed-than-bcrypted passwords:

Obtain hashes
Generate candidate passwords for password cracking tool
Calculate corresponding SHA-1
Perform the cracking attempt

So, as you can see, the attacker must perform one cheap additional step to crack the password. So, your scheme should provide at least the same security level as using bcrypt to protect plaintext passwords.

As a small bonus, you are getting scheme which is not implemented out-of-box in common cracking tools. It will make password cracking even harder if the attacker is not very sophisticated and will not be able to figure out hashing scheme. But this feature is security by obscurity, so it is better to expect that attacker will know all about your password hashing approach.


Is there any serious vulnerability or danger if the hard-disk gets disconnected often? I'm using a Lenovo machine which runs ubuntu 16.04 which is installed in an external Seagate Hard Disk  (of size 1 TB). Sometimes (happens from the beginning of installation) the hard-disk gets disconnected and all the applications partially works or breaks. Reinserting the hard disk does not solve this problem and the only option for me will be to switch the system off and then switch it on.

If I have my browse opened, I would still be able to browse the net, as long as the browser does not close. Or if I resize the browser by dragging it using a mouse pointer, it breaks and I would be forced to close it.

I don't know if this doubt of mine is purely delusional or reasonable but for some reason I believe if the machine goes to that state, there is a chance it could send my passwords/other information to the servers it is currently connected to (that is raw ram memory). Is it true? If not, is there any other potential vulnerability in such a state?

Moreover, if someone wants to access my system badly and knows that my system gets disconnected often from its hard disk and assuming I have a fixed IP address, will he be able to gain access to the raw ram memory? (this question is purely hypothetical, because I don't have a fixed IP in my home)

I suspect you're asking the wrong the question, but I'll answer what you asked first: You shouldn't have to worry about any security vulnerability caused by the issue you're having. Imagine you're using your favorite text editor (vim) to write a note. You attempt to save it and the program goes through the following "thought process":

  "Oh no, I can't save this document because the hard
  drive vanished. I'll just send the user's password to a remote
  destination instead."

It just doesn't make sense for a program to do that. Even if the program is a virus/malware, it still wouldn't make sense to do that. Malware would just send the password regardless of whether the hard drive is connected or not.

Perhaps a better question would be:

  My computer's hard drive is frequently getting disconnected. Is it possible that this is caused by some unknown virus/malware on my machine?

Anything's possible, but in this case I think Occam's Razor applies (the simplest solution is usually the correct solution): most likely you have a hardware issue. Sounds like a loose cable or connector.

Futhermore, disconnecting a hard drive does not suddenly make your memory more vulnerable. It's either vulnerable to begin with, or it's not. A crashing program won't open up security holes that didn't already exist. That being said, here's some further reading on how program crashes could pose a risk, but realize the attacker would already have to gain access to your machine first.


Crack a single http cookie and gain access to a random user's account! I was looking for lots of information about cookies recently. What attracted me the most was the fact that cookies come in all forms and can be hijacked through arp poisining and spoofing on the local network or wirelessly.

I did not see one case that I would like to ask about.

Can a potential hacker literally crack and enumerate a random's user cookie and throw back the cracked cookie.

we assume that the website gets a lot of traffic and has many users signed in at the same time.

In case we want to be secure from this kind of attack we may log off the user after a certain period of time or globally use an https certificate but this isn't the main theme here.

Protecting against enumerating valid session cookies is easy: just make the search space too large for an attacker to have any hope of finding another valid value this century. For example, if the cookies are cryptographically secure [pseudo-]random 128-bit values, there could be a billion (~2^30) unique active sessions at once (that never expire) and you could have a botnet of a billion compromised IoT devices each sending a thousand requests a second (for a total of ~2^40 guesses/second), and it would still, on average, take you around 450 million years to find the first valid token. 128 bits isn't even that long, either; a mere 16 bytes of data.

This works even if the session tokens aren't just random blobs of data but contain some predictable information, so long as the unpredictable part has enough entropy. For example, a JSON Web Token (JWT) contains a chunk of plain-text data (base64-encoded, but that's trivial to decode and provides no security) and then a signature (either an asymmetric signature or a MAC). Let's assume it uses an HMAC with SHA-256 and a 256-bit key; the heat death of the universe would arrive long before you could have any hope to brute-force that key, even if you could set every computing device on the planet today to doing nothing but working on it.


how to get sites original ssl cert when using company firewall that returns its own ssl cert I would like to download a website's SSL certificate but can only see my cooperate firewall SSL certificate.

Question: When all traffic that flows to my computer from the network have the same ssl signature (due to firewall) is there a way to see the actual site signature? Is there a way to view the actual SSL certification before it is modified?

I know I can go through a proxy and download it that way but I don't want to have to do this work around... Is there a way to inspect the site to find it's cert?

No.

The firewall configuration you are describing does a SSL MITM. The certificate at the source website is processed by the proxying device, then discarded, it doesn't reach your own computer. This means you can't see the certificate that was provided to the proxy. You need to trust that it was the right one and it was validated correctly (in some cases, it would not validate them properly, leading to the final users being less secure).

That's the reason Extended Validation, HSTS, etc. are disabled by that configuration with a local MITM. You can't know which certificate was presented. In fact, note it may not even have been an original certificate (e.g. the page you are shown is an interstitial).

If you need to inspect the site certificate, you will need not to connect through the MITM firewall (getting an exception, connecting through a VPN, etc.).


Password hashing on both client and server : what are the risks concerning hash composition (collisions and reversing)? There are plenty of question addressing the "client / server : where to hash ?", but i have not found anything about my particular question : considering a server_salted_hash(client_salted_hash(password)), using HTTPS, What are the risks concerning hash collisions, or is there other even more serious risks than them ? (of course, considering

As I remember in school, and readings about security good practices, a main reason about not composing hash function is it "paradoxally" weaken it by potentially increasing the number of collisions, or easing reversing it.

Thus, I would like to know if there are any security flaws introduced by such a system ? (that wouldn't be if I hash only on backend)

Supposing I use salt on both hash, are there some combinations of hash you would recommend, or advise against ?

If you use the correct hash functions, chances of collisions are negligible. This remains the case if you hash repeatedly. The question Strength of multiple hash iterations? explains:

  There's a catch: increasing n also slightly increases the odds that a random password gives the same result as the right password due to hash collisions, and is thus a false but accepted password; however that remain very unlikely, in the order of n·2−256 for practical values of n, and can be entirely ignored in practice.

I would recommend using a slow, well-known password hashing function, such as PBKDF2, scrypt, bcrypt, or Argon2.


Just Works Bluetooth Low Energy Security I have been puzzled the past couple days about bluetooth low energy security.

My situation:

I am looking at what it might take to secure unpaired BLE connections.

In some cases, and essentially this main use case, a mobile device (Android) may want to connect to several different peripherals randomly at different times throughout the day. By 'randomly' I mean I am walking by one if I have a dozen scattered around my apartment and I personally don't know exactly which one without physically checking.

The process of physically accepting a pair request seems unnecessary and quite time consuming. I don't what to walk in the room the first time and have to manually pair each device, that would be insane if I had 100+ devices. Note that these devices don't necessarily have to be connected at the same time, but could. Also note that I understand this isn't generally the main use case of the typical peripheral to mobile communication considering the max connected devices at one time is 7.

These peripheral devices have no I/O thus the Numeric Comparison, Passkey Entry, and Out of Band  connection methods don't seem to be the ones that I'm looking for. It seems that Just Works should work, however there doesn't seem to be security support for it. Anyone with a sniffer would be able to read all communication.

It seems I may be asking too much of Bluetooth LE and will have to figure out another means--maybe in the application layer?

if you want to have encrypted communication on bluetooth layer, you will need a pairing process. Just Works is the most simple one but using Android or iOS you will still need to press a button at least on phone side.

A basic idea of the bluetooth pairing process is that no predefined keys are necessary. Therefor, the user can secure the connection between two devices out of the box.

From you post above, some questions arise:

Do you need encryption or authentication?
What is the sense of encryption in your use case if any device is able to connect, encrypt and communicate?
What level of security do you need? Security
against professional atackers or against someone accidentally
connecting to your device with a BLE scanner app?
Do you actually need encryption or signing?

Dependent on your requirements, there are different solutions. To my knowledge, BLE encryption without pairing is not possible (with usual smartphones).

You could install predefined encryption keys and encrypt data in your application. But then, you have another problem: How to distribute the keys? And if one device is hacked, how do you revoke keys? If all devices share the same key, your whole system is broken if one device is hacked.


How does sslsniff sign a certificate with a leaf certificate in trust chain? In my opinion, signing a certificate with a leaf certificate in trust chain need to know the private key in left certificate. However, sslsniff has no way to know the leaf certificate's private key. So how can it work? Am I missing something?

signing a certificate with a leaf certificate in trust chain need to know the private key in left certificate.

It is true that signing a certificate needs the private key of the issuer (signers) certificate. But it also needs to have a certificate as signer which can be used as CA, i.e. where basic constraints allow use as CA. This is usually not true for leaf certificates.

  Am I missing something?

You are missing that sslsniff used a specific bug in IE as described on its website:

  This tool was originally written to demonstrate and exploit IE's vulnerabilityto a specific "basicConstraints" man-in-the-middle attack. While Microsoft has since fixed the vulnerability that allowed leaf certificates to act as signing certificates,...

Which means because of this bug it was possible that an attacker could use an easily and legally to obtain leaf certificate issued by a publicly trusted CA for the attackers website to sign other certificates so that they get accepted by IE. Since in this case the attacker had of course the private key to its own certificate the signing was no problem. The problem instead was that IE accepted built the trust chain by using the attackers certificate as intermediate in the path to a trusted root CA even though the basic constraints in the attackers certificate allowed it to be used as CA.


Should I use SHA-512 with many rounds or bcrypt/scrypt I am currently using SHA-512 with 100000 rounds because of the easier implementation. The algorithm generates passwords from a service (e.g amazon) and a master password. Would I benefit from switching to bcrypt/scrypt?

Based on clarification from the OP, I will change my answer.

So you're doing something equivalent to:

sha-512x100000("stackexchange.com"|"master password")

... that's really not a great idea. Your choice of hash function is not your biggest problem here. As an attacker, once I crack one of your passwords and recover the master password, it becomes trivial for me to crack all your other accounts.

I would suggest you switch to using passwords derived from /dev/random, or using a proper password manager.

ORIGINAL ANSWER

Yes, please do not use SHA-X hash functions for password hashing. You'd be better to switch to something designed to be a password hashing function.

SHA-2 hashes (which include SHA-224, SHA-256, SHA-384, and SHA-512) were designed for performance: it was part of the design requirement that software and hardware implementations of these hash functions be as fast as possible. Assuming that your server is using a software implementation of SHA-512 and the attacker trying to brute-force the passwords is using either a GPU rig, or dedicated SHA-512 hardware, then you are giving the attacker an advantage over you because they can perform guesses with much higher efficiency than the server can generate the hashes in the first place.

In short, SHA hashes are designed to be fast - especially in hardware. A very bad property for a password hashing function.

bcrypt, scrypt, and to a lesser extent PBKDF2, are designed to be slow and inefficient in hardware -- very good properties for password hashing functions.

Of those three (bcrypt, scrypt, and PBKDF2) it looks like scrypt is the most modern and the best choice. Though, from the results of the 2013 - 2015 Password Hashing Competition, it seems that Argon2 (and the runner-ups Catena, Lyra2, yescrypt and Makwa) blow scrypt out of the water, so use one of those if you have it available.