Pros and Cons of Centralized Authentication Providers

17 Jul 2025 - tsp
Last update 17 Jul 2025
Reading time 30 mins

Authentication systems and services are the gatekeepers of digital security, determining who can access an application or service. Approaches to authentication range from local, application-specific logins (each app managing its own usernames and passwords) to centralized identity providers that offer Single Sign-On (SSO) across multiple services. They also include variations like adding two-factor authentication (2FA) or using government-issued digital identities. Each approach has distinct security advantages and drawbacks. This blog article explores these pros and cons with a focus on security, comparing:

We will back up claims with credible sources from security research and expert organizations.

Internal Authentication (Standalone Systems) - Passwords and 2FA

In a decentralized or standalone internal authentication model, each application or service maintains its own user credentials and login process. Users might have separate usernames/passwords for each app. Many organizations historically used this model before the rise of single sign on solutions. Some internal systems now offer optional or mandatory two factor authentication (2FA) or multi factor authentication - for example, a company might implement FIDO U2F security keys or time based one-time codes (TOTP) on each of its internal applications independently.

Security Pros: The primary security benefit of keeping authentication siloed per application is compartmentalization. If one application’s user database or login mechanism is compromised, it does not directly grant access to other systems, since each uses separate credentials. In other words, there is no single master key that unlocks every account across the company or accross different services[1]. An attacker who exploits a vulnerability in one app can only impact that app’s users (barring password reuse - more on that below). This isolation limits the blast radius of a breach in a single system.

Additionally organizations retain full control over the authentication process in each app – they aren’t relying on third parties and are also not leaking information about usage patterns or other metadata. For especially sensitive or specialized systems, custom authentication logic or stricter policies can be applied without needing external integration. There is no dependency on outside identity services, so external outages or third-party breaches won’t directly lock users out of an internally-managed app.

When strong 2FA is added internally, the security of that individual application improves significantly. For example, implementing support for FIDO U2F security keys or other webauthn tokens (such as YubiKeys) within an app can make account access phishing-resistant and far more secure than password alone[2]. Hardware security keys carry unique cryptographic secrets and perform a challenge-response, making them virtually impossible to hack and immune to credential replay or phishing attacks[2]. In addition requiring presence of the user (pressing a button on the token, etc.) prevents automated attacks against those tokens. This means that even if a user’s password is stolen, an attacker cannot login without also having the physical device. Internal 2FA using authenticator apps also raises the bar for attackers, who must then steal a second factor - though as discussed later, not all 2FA methods are equally secure. In short, on an app-by-app basis, enabling 2FA can dramatically reduce the likelihood of account compromise on that particular service.

Security Cons: The decentralized internal model suffers from several significant drawbacks in practice. One major issue is the burden on users to manage many credentials, which often leads to poor security habits. Humans have limited capacity for memorizing dozens of strong, unique passwords. As a result, password reuse across sites is rampant - nearly 65% of people admit to reusing passwords on multiple services[3]. If each internal application requires a separate login, users are likely to recycle the same or similar passwords instead of using password managers for this purpose. This has dangerous consequences: if any one of those applications is breached and its password database leaked, attackers can try the exposed passwords on the other apps. Reused passwords mean esentially “if one account gets breached, everything else becomes vulnerable”[3]. In decentralized setups, one compromised app can thus lead to credential-stuffing attacks against the organization’s other systems. The lack of a unified identity increases the total number of “secrets” users and admins must safeguard, often exceeding what is realistically manageable.

From the developer/organization perspective, maintaining separate authentication logic in each application is error-prone and labor-intensive. Every additional login system is another piece of code that could contain vulnerabilities. A classic security principle is that more code means more potential bugs - each line is part of the attack surface[4]. Duplicating authentication code across multiple projects multiplies the opportunities for mistakes. In contrast, a single well-hardened authentication service can be more thoroughly reviewed and tested. It’s telling that in system design, decentralized authentication improves fault tolerance but introduces more complexity in managing consistency and security across distributed services.[1] In practice, not every app team will have the security expertise or resources to implement robust authentication on their own, leading to uneven quality. For example, one internal app might forget to hash passwords properly or might not enforce strong password rules, even if another app does - a weakest-link problem.

The user experience friction in a non-SSO environment also indirectly harms security. Users required to log in separately to 5, 10 or 20 different tools each day may experience authentication fatigue. The effort of repeated sign-ons can tempt users to take insecure shortcuts (like writing passwords down, choosing simpler passwords or avoiding logging out). As one identity management analysis notes, high-friction sign-ins across many apps lead to security fatigue, and it’s unrealistic to expect users to rigorously follow best practices for every single account[5]. Inconsistent authentication UIs and rules between systems can also confuse users and lead to errors. Thus, the very absence of single sign-on can degrade security by pushing users toward convenience at the expense of safety.

Finally, while compromising one isolated app doesn’t automatically open others, attackers often do find ways to exploit the human element across systems (such as phishing the same user on multiple platforms or using data from one breach in social engineering for another). No central oversight means security incidents might be detected more slowly as well - an organization might not notice a credential stuffing attack on one low-profile internal tool until much later, whereas a centralized system monitoring all logins might catch suspicious activity early.

In summary local internal auth offers security silos - limiting single points of failure - and can be enhanced with strong 2FA on each app. However, it places a huge burden on both users and developers to maintain good security across many independent accounts. In reality, the decentralized approach often correlates with inconsistent protections, widespread password reuse and a greater total attack surface (multiple login systems to potentially exploit). Without SSO, the probability of a security lapse somewhere is higher, even if each individual account’s blast radius is smaller. The next sections look at centralized alternatives that address some of these issues, while introducing their own trade-offs.

External Identity Providers (SSO via Google, Facebook, etc.)

Instead of each application handling credentials, many services now allow “Login with …” an external identity provider (IdP) - for example, signing into a third-party app using your Google, Facebook, Apple or Microsoft account via mechanisms like OAuth 2.0 and OpenID Connect. In a corporate setting, an organization might use a centralized SSO server based on SAML or systems like Kerberos to authenticate users for all internal applications. Here, the authentication is centralized: the user has one primary account and with one successful login - often augmented by multi factor authentication - they gain access tokens to multiple applications. Each application gets a credential that identifies the user within it’s context and sometimes has attached scopes or limits. This dramatically reduces the number of credentials in play. It is essentially a federated identity model - trust is placed in the central provider to vouch for the user’s identity to each application. In addition using tokens issued by the central identity provider towards the specific services one can implement end-to-end authorization by requiring the token issued by the identity provider for example to guard APIs and database queries (i.e. even the application application during the query for a user is only capable of querying the users data via an API and not all users data because the token it has been issued only allows access to this users data).

Security Pros: The centralized SSO model can significantly improve certain security aspects: notably, it cuts down on password proliferation and enables consistent strong authentication. Users need to remember (and protect) only one core password (or passphrase) for the SSO account instead of many. This makes it easier to use a truly strong, unique password and to change it periodically, since there’s just one that unlocks everything. Supporting this, industry analysis finds that SSO reduces security risks related to passwords by requiring users to manage only one strong set of login credentials[6]. With fewer passwords to create and remember, the temptation to reuse passwords or choose weak ones is reduced[6]. For an organization, an SSO solution also allows uniform enforcement of security policies - for example password complexity rules, rotation policies and multi factor authentication can be implemented in one place and then apply to all integrated applications[6]. For example, if you add an MFA requirement like a one-time code or push approval to your central IdP, then every service using that SSO automatically benefits from that extra layer of security. This central management ensures no app is left with weaker login security due to oversight; security updates or patches to the auth system propagate everywhere at once.

Another advantage is that companies like Google or Microsoft have dedicated security teams and advanced defenses guarding their identity platforms, arguably far beyond what a small app development team could manage. By outsourcing authentication to a tech giant’s systems, smaller services gain the benefits of those companies security investments (anomaly detection, audits, etc.). For instance, Googles login infrastructure includes statistical risk analysis of each login attempt and supports phishing-resistant methods (security keys, phone prompts, etc.) which third-party apps can inherit by using Google SSO. Additionally, because the app itself never sees the user’s raw password, the app can’t accidentally leak or store the password. This means if the application’s database is compromised, there are no password hashes to crack or steal - user credentials remain with the IdP. As one observer notes, using external identity can shrink an application’s attack surface, since the app doesn’t handle credentials and a bug in the app won’t leak the master password database[6]. Overall, SSO centralization simplifies achieving a high baseline of security across many services - one tightly guarded gate instead of many flimsy ones.

Beyond password issues, SSO can also improve intrusion detection and response. With all logins flowing through a single system, suspicious patterns like login attempts from unusual locations, repeated failures or known-breached passwords can be spotted globally. Administrators have a single audit trail to monitor and can disable a compromised account in one step to immediately cut off access to all connected services[6]. This centralized visibility is a boon to incident response: imagine an employee’s account is suspected to be hacked - with SSO, security can block that one account and thereby protect every app, whereas in a decentralized setup they would have to scramble to lock the user out of each system individually and might miss some. Central IdPs also often provide convenient user lifecycle management (e.g. automatically deactivating access to all apps when someone leaves the organization), which prevents orphaned accounts lingering unmonitored in various applications[5].

Security Cons: The Achilles heel of centralized authentication is the creation of a single point of failure or single point of compromise. If an attacker manages to take over a users central SSO account, they instantly gain access to every application that trusts that identity. As an analogy, it’s like a master key - very convenient, but disastrous if stolen. “SSO lets users access multiple services with one login … convenient but risky: if the SSO system is compromised, an attacker can potentially get into multiple services at once.”[6]. Similarly, a weakness or misconfiguration in the SSO system itself can impact all connected apps simultaneously. The trade-off, therefore, is more severe consequences when something does go wrong. For example, in 2018, a flaw in how certain sites implemented federated login allowed attackers to log in as other users by forging Google sign-in responses (due to developers mis-validating the OAuth tokens)[7]. Such an error effectively meant a breach of the central IdP (or its protocol) translated to a breach of many websites at once. In a decentralized model, one app’s vulnerability wouldn’t directly affect others - but with SSO, if the central server fails or is compromised, it can impact all connected systems[1]. This inherent concentration of risk is the biggest downside to centralized providers.

Another concern is availability and dependency. Should the external provider experience downtime or if the integration breaks, users might be unable to log in anywhere. “If the SSO system experiences downtime, users may not be able to log in to any dependent applications or services.”[7] All eggs are in one basket; an outage at the IdP (or even an network or Internet connectivity issue reaching it) can effectively lock an organization or user out of multiple critical tools at once. Similarly, if a user’s account at the IdP is suspended or they lose access (say their Google account is unexpectedly locked), this cascade locks them out of all services tied to it. In contrast, separate logins provide redundancy - failure of one doesn’t immobilize everything.

Integration and implementation complexity is another drawback. While using an existing IdP saves each app from rolling its own auth from scratch, properly integrating SSO securely is not trivial. The OAuth/OIDC and SAML protocols have many subtle options and footguns. Security professionals have noted that “SSO is unexpectedly challenging to do correctly and consistently … there are thousands of small details to get right and lack of standardization can lead to vulnerabilities”[7]. For instance, if a developer doesn’t properly validate a SAML responses signature through every layer, an attacker could inject an old valid signature and bypass authentication. There have indeed been multiple academic studies uncovering logic flaws in real-world SSO implementations (both by IdPs and by apps integrating them)[8]. In short, the complexity of federated identity can introduce new security issues if not expertly managed. Smaller organizations using social logins might rely on the provider’s libraries (which is good), but a custom enterprise SSO setup must be configured with care.

There are also privacy and trust implications with third-party identity providers. Using “Login with Facebook/Google/…” means those companies get data about where you are logging in and have authority to identify an entity representing a given identity. Research has shown that identity providers can potentially track user activities across different apps and websites through SSO[8]. For example, Facebook might know you signed into X app and at what time, which raises privacy concerns if the IdP shares or uses that data for profiling. Additionally organizations have to trust the external provider’s security and policies. A breach of the IdP (though unlikely for giants like Google but its not impossible) would be catastrophic. Some users are also uncomfortable consolidating their personal social account with third-party services - if, say, your Google account is compromised by phishing, you’d lose not just email but also all the apps you used Google to log into. On the other hand, separating accounts (work vs personal) can mitigate that; e.g. one might use a dedicated corporate SSO separate from any personal accounts.

In summary, external and federated identity solutions greatly alleviate the password overload problem and tend to raise the baseline security (especially by enabling universal MFA and professional management of credentials)[6]. They simplify the user’s life and allow focus on protecting one account really well, rather than spreading effort thin across many. However, with that convenience comes high stakes: that one account’s compromise can be a single point of total failure[1]. The architecture also introduces reliance on the IdPs reliability and integrity. As one security writer succinctly put it, SSO is a “great convenience, but treat that central account like the crown jewels” - it must be guarded accordingly, ideally with strong MFA and vigilance.

Government Digital Identity Systems (e.g. ID Austria, etc.)

Many governments have introduced centralized national digital identity programs to enable citizens to authenticate to both public and private services. Examples include Austria’s ID Austria (successor to the Handy-Signatur mobile ID), Germany’s nPA (neuer Personalausweis) card, India’s Aadhaar, etc. These systems typically provide each citizen with a verified digital identity - often protected by PIN, passwords and a second factor like a smartphone app or smart card - which can be used to log in to government portals (taxes, health, etc.) and sometimes partnered commercial services. Government IDs often also enable digital signatures with legal equivalence to handwritten signatures. In essence, these are highly centralized, high-assurance authentication providers, usually mandated or strongly encouraged for interactions with the state.

Security Pros: Government-backed IDs generally employ strict security measures and verification processes by design, since they handle sensitive data and important transactions. For instance, to obtain ID Austria, one must undergo an identity verification (linking to an official document or in-person check), yielding a high level of identity assurance that typical commercial providers may not require[9]. The authentication mechanisms tend to be robust: ID Austria, for example, builds on the prior mobile-phone signature system and Bürgerkarte and supports FIDO Level 2 certified devices (like smart cards or hardware keys) in addition to mobile app authentication[9]. FIDO2 Level 2 certification mandates hardware-backed security with a restricted OS, meaning only secure hardware tokens or environments can be used - this is a strong security feature since it excludes easily phishable factors[10]. Indeed, Austria’s integration of YubiKeys and smart cards was touted as “greatly enhancing security … setting the standard for secure online authentication and digital signatures”[9](#ref9)]. When using a compliant hardware token, a user’s digital signature is produced in a way that is protected against tampering or forgery[9](#ref9)], offering non-repudiation. This level of security is difficult to achieve with just passwords.

Another advantage is consistency and coverage: a single government ID can be used across many services, meaning citizens don’t juggle multiple accounts for various agencies - reducing the password reuse issue in the public sector context. Similar to corporate SSO, this centralization allows the government to enforce one high standard of security across all its e-services. Users only need to secure one primary account (i.e. keep their ID Austria PIN and second factor safe) to protect all their e-government interactions, ideally making it easier to educate and support citizens in security best practices. The government can also rapidly deploy security updates or require MFA for that one system, instantly benefiting all usage of it.

Moreover, having a unified ID can improve auditability and fraud detection in government transactions. If every action (filing a tax return, signing a contract, etc.) is tied to the same verified identity, it’s easier to trace and combat identity fraud. The centralized system can monitor for anomalous usage patterns (e.g., a sudden access from abroad on a citizen’s account might raise a red flag across all services). Some argue that digital IDs, if well-implemented, actually increase security compared to fragmented paper documents or multiple login schemes, because they can employ modern cryptography and strong user authentication uniformly[9](#ref9)].

Security Cons: Despite their strengths, government ID systems come with serious security and privacy concerns. One major issue is that they effectively create a universal key to a citizen’s digital life, without room for separation of contexts. The same ID that logs you into the tax office might also authenticate you for health records, voting or even private banking services. This concentration means if the government ID account is compromised, an attacker could impersonate you across a very broad range of services, potentially with devastating consequences. Unlike choosing to use different passwords or even different social logins for different sites, with a national ID you are often forced into one identity for everything. There is no ability to compartmentalize risk by using, for example a separate “work ID” and “personal ID” - the ID Austria “does not allow separation of concerns between domains like having a distinct ID for work versus for private matters,” as some critics have observed. In other words, one identity compromise could expose highly sensitive capabilities (like signing legal documents or financial transactions) that you might have wanted walled off from a compromise of, for example your account on a less critical service that also accepts the national ID.

Furthermore, the requirement to use consumer devices (like smartphones) as authentication factors in many digital ID schemes is viewed by some security experts as a weak link. ID Austria, for example, supports a mobile app as one factor for login[10]. While convenient, smartphones are general-purpose devices known to have many vulnerabilities and malware threats. In fact, security specialists often note that “smartphone-based authentication … is vulnerable to phishing attacks, SIM swapping and inherently malware”[2]. Malware on a user’s phone could potentially intercept one-time codes or even tamper with the digital ID app if the device isn’t well-secured. In addition many devices fTPMs are actually crackable via software vulnerabilities. There is also a fear (especially among privacy advocates) that mandated government apps could be an avenue for state surveillance malware. This might sound speculative, but consider that authoritarian regimes have abused mandatory apps to spy on citizens and even in democracies, police malware has been a contentious issue[11]. The mere presence of a government-required app on millions of phones introduces an attractive target for sophisticated attacks by state or criminals. If an advanced spyware (like the well known Pegasus tool) infects a phone, it can covertly take control of the device, monitor communications and potentially abuse authenticated sessions[12]. Pegasus has been used to steal data from phones without any user click[12], which illustrates why relying on smartphones for the most sensitive authentications can be problematic - the phone’s security might be the weakest link despite strong encryption in the ID system itself.

A concrete example of a systemic vulnerability in a national ID scheme occurred in Estonias e-ID program often lauded as a secure digital identity pioneer. In 2017, researchers discovered a cryptographic flaw - the ROCA vulnerability - in the chips of approximately 750.000 Estonian ID smart cards[13]. This weakness theoretically could allow an attacker to derive the private signing keys and impersonate citizens digital signatures without the physical card[13]. While exploitation was complex and no known incident of fraud is publically widespread known, the incident forced a nationwide credential update and showed that a single technical flaw can jeopardize a large populations credentials at once. As the Estonian case showed, “the reported vulnerability could facilitate using the digital identity for identification and signing without having the physical card and PIN codes”[13]. Such a mass impact issue is less likely in decentralized setups where different systems use diverse technologies - but in a centralized ID, homogeneity means one flaw hits all. The scope of data in government systems also raises concern: for example, the Chaos Computer Club warned in Germany that planned central health IDs would store “master data for all citizens … in unencrypted form for use in authentication,” (besides many other problems with the system where gaining access was pretty easy) creating a rich target for attackers if not properly secured[14].

Beyond pure security exploits, privacy and civil liberties issues loom large. A single ID that people must use for many purposes can enable extensive tracking and profiling of citizens activities. If not carefully firewalled, various government agencies or even private partners could aggregate data via the common identifier. Advocacy groups point out that some countries have expanded their digital ID databases beyond the initial scope, integrating them with broader surveillance infrastructures[15]. In the extreme, a digital ID could become a tool for social control - for instance, if accessing everyday services requires it, the government could theoretically monitor or even restrict individuals activities by toggling their digital identity status. While many IDs exist within EUs GDPR and eIDAS regulatory frameworks (which include privacy safeguards), skeptics note that centralizing identity inherently increases the risk of misuse if proper legal protections (and as one knows they can change quickly as soon as technical solutions are in place) aren’t enforced[15]. Even on a usability note, requiring a government ID for broad uses can exclude or inconvenience those who mistrust the system or who prefer not to link their personal civil identity everywhere.

In summary, government-centric identity systems like ID Austria show how centralization can achieve high security standards (with strong cryptography, hardware second factors, etc.) and provide authoritative identity proof, which is crucial for things like legally signing documents[9]. However, these systems also centralize risk to an extreme degree: one identity that one cannot change to rule them all means one identity to steal for total access. The reliance on user-side technology (smartphones or cards) introduces practical vulnerabilities and the inability to segregate identities for different facets of one’s life poses both security and privacy dilemmas. As the Open Government Partnership noted, inadequate safeguards in digital ID deployments can lead to data breaches and even facilitate surveillance or harassment if abused[15]. Careful design, oversight and giving users some control (for instance, allowing hardware tokens instead of just a phone) are key to mitigating these concerns.

Also keep in mind that it does not matter what is written in the laws today. If you have a system in place that is capable of performing widespread tracking or control and an authoritarian government takes over the rules are changed very quickly. Solutions that have no technological safeguards in place are inherently unsafe.

Summary

Method Pros Cons Key Risks Ideal Use Case
Internal Authentication (per app) - High compartmentalization
- No third-party dependency
- Full control over auth logic
- Can be hardened with strong 2FA		 - Credential sprawl and password reuse
- Security varies per app (weakest link)
- High dev/maintenance overhead
- Poor user experience (auth fatigue)		 - Reused credentials enabling credential stuffing
- Inconsistent 2FA usage
- Harder to monitor breaches		 Small apps or highly isolated systems where data silos are required and usage is infrequent
External Identity Providers (SSO via Google, corporate SAML, etc.) - Fewer credentials to manage
- Unified policy enforcement (MFA, lockout)
- Easier onboarding/offboarding
- Central logging and monitoring
- Offloads risk of storing passwords		 - Single point of failure
- Provider outages lock out users
- Misconfiguration risk
- Privacy concerns (tracking via logins)		 - Compromised SSO = access to all
- OAuth/SAML bugs or token injection
- External trust assumptions		 Organizations seeking ease of use, uniform policies, and scalable secure access across many services
Government Digital ID (e.g. ID Austria) - High assurance identity verification
- Legally binding digital signatures
- Strong MFA (smartcards, FIDO2)
- Universal access to state services		 - Extreme centralization of risk
- One identity for all contexts (no separation)
- Smartphone-based MFA vulnerable
- Privacy and surveillance concerns		 - Full identity takeover = civic and legal control
- Tech monoculture leads to systemic vulnerabilities		 Verified digital identity for public services, taxes, e-signatures; not ideal for universal daily logins

Conclusion

Authentication approaches fall on a spectrum between fully decentralized and fully centralized and each comes with trade-offs in security. Internal, siloed authentication for each application limits the blast radius of any single breach and avoids a monolithic failure, but it often fails in practice due to human factors (password reuse, inconsistency) and higher aggregate complexity (multiple systems to secure)[1,3]. Adding 2FA improves any method’s security; however, scattered 2FA implementations still rely on users and developers to do everything right every time, which is a tall order.

Moving to centralized identity providers and SSO yields significant security upsides: uniform enforcement of strong authentication, fewer credentials to manage (reducing password-related vulnerabilities) and easier oversight[6]. But it also concentrates risk - the SSO account or service must be fortressed, since its compromise is all the more catastrophic[1,6]. The mantra for SSO is often “make it easier for users, but plan for that one account to be heavily targeted.” Robust MFA (preferably phishing-resistant methods like FIDO2 keys or push prompts tied to the device) is almost a necessity to secure a central IdP and organizations should have monitoring on the IdP to catch abuse quickly.

With third-party social logins, security can be as good as those providers make it - often very strong - but it requires trusting an external entity with both security and some amount of data about your logins[8]. Users and organizations should weigh convenience vs. privacy there. It can be a sensible choice to offload authentication to a reputable provider (many websites have decided that the risk of storing passwords themselves is greater than the risk of outsourcing authentication). Still, one should enable available protections on those accounts (like Googles or Facebooks 2FA) to reduce the chance of a takeover.

Government digital IDs represent the far end of centralization - a single immutable identity for myriad uses. They underscore the classic security dilemma: high walls but a deep moat if breached. The security technology in these systems can be top-notch (smartcards, certified devices, etc.), raising the cost for attackers significantly[9]. At the same time, the impact of a failure - whether technical or due to account takeover - is much higher and these systems raise broader questions of trust, privacy and autonomy. It’s crucial that governments implement strong legal and technical safeguards (like not allowing unlimited tracking, providing redress mechanisms and giving users secure options like hardware tokens)[15,10]. Users of such systems should be extra vigilant about securing their devices and credentials, as the stakes are not just a single account but potentially one’s digital civic life. In addition supporting legal signatures and access to all systems at once without prior activation for a given usage means that even though one may just have registered an account to check on ones retirement savings an attacker who has compromised the ID can manipulate ones tax declaration, hijhack ones identtiy known to the government, can sign loan applications and much more.

In summary centralized authentication offers a double-edged sword: improved security efficiency and consistency versus increased impact of failures[1]. The optimal solution often lies in a balanced approach: implement centralized SSO inside an organization to help users and raise overall security, but do so in a way that avoids single points of catastrophic failure - for example, requiring multi-factor auth, using risk-based authentication and partitioning especially sensitive systems in separate identities. Similarly, embrace the convenience of a national digital ID for verified identity when appropriate, but maintain separate credentials for different professional and personal areas or less-trusted services, thereby limiting exposure. In all cases, security is as strong as the weakest link - and centralization tends to strengthen many links while making one link (the central node) absolutely critical.

References

This article is tagged:

Data protection policy

Dipl.-Ing. Thomas Spielauer, Wien (webcomplains389t48957@tspi.at)

This webpage is also available via TOR at http://rh6v563nt2dnxd5h2vhhqkudmyvjaevgiv77c62xflas52d5omtkxuid.onion/

Valid HTML 4.01 Strict Powered by FreeBSD IPv6 support