Una política de contrasenyes hauria de dificultar el compromís dels comptes sense fer que el comportament segur sigui innecessàriament complicat. Les millors polítiques són clares, pràctiques i alineades amb la manera com realment treballa la gent. Fomenten contrasenyes llargues i úniques, donen suport als gestors de contrasenyes, requereixen autenticació multifactor allà on sigui convenient i eliminen regles antigues que empenyen els usuaris a comportaments previsibles.
\nAquest article explica què cal i què no cal fer en una política moderna de contrasenyes, què cal evitar, quines són les millors pràctiques, i proporciona una plantilla que pots adaptar per a la teva organització.
\nUna política de contrasenyes és un conjunt de normes que defineix com es creen, emmagatzemen, utilitzen, comparteixen, canvien i protegeixen les contrasenyes. S'aplica a empleats, contractistes, administradors, comptes de servei i, de vegades, també a clients, depenent dels sistemes inclosos.
\nUna bona política de contrasenyes hauria de respondre preguntes pràctiques:
\nL’objectiu no és crear el conjunt de normes més complicat. L’objectiu és reduir el risc real.
\nLa llargada és una de les millors defenses contra atacs per esbrinament o força bruta. Una mínima organizativa, igual per a tothom, sol ser més fàcil d’entendre que no pas regles diferenciades per a usuaris estàndard, administradors i casos especials. Un valor raonable és exigir almenys 16 caràcters per a tots els comptes d’usuaris humans. Com més llarga, millor, sobretot si els usuaris utilitzen gestors de contrasenyes o frases de pas generades aleatòriament.
\nEls usuaris haurien de poder crear contrasenyes molt més llargues que el mínim exigit. No posis límits baixos com 16 o 20 caràcters. Un màxim de com a mínim 64 caràcters és un bon punt de partida, i molts sistemes poden acceptar-ne més sense problema.
\nLes frases de pas han de ser acceptades si són prou llargues i no es basen en cites populars, lletres de cançons, noms de l’empresa o frases previsibles. Per exemple, una frase feta a partir de paraules aleatòries sol ser millor que una contrasenya curta amb substitucions forçades.
\nCada compte ha de tenir una contrasenya única. Reutilitzar contrasenyes és una de les raons principals per les quals una bretxa en un servei pot provocar la presa d’un compte en un altre. Els gestors de contrasenyes fan que les contrasenyes úniques siguin pràctiques perquè els usuaris no han de memoritzar totes les credencials.
\nLa teva política hauria d’autoritzar explícitament, i fomentar, l'ús de gestors de contrasenyes aprovats. Els usuaris han de poder enganxar contrasenyes als formularis d'accés, fer servir l'autocompleció i generar contrasenyes aleatòries. Bloquejar l’enganxat pot semblar una mesura de seguretat, però sovint produeix l’efecte contrari: fa que la gent eviti els gestors de contrasenyes.
\nLes contrasenyes s’han de rebutjar si apareixen en llistes conegudes de bretxes, llistes de contrasenyes habituals, o llistes de negats específiques de l'organització. Aquesta mesura és més útil que forçar la inclusió d’una majúscula, un número i un símbol.
\nL'autenticació multifactor (MFA) s'ha d'habilitar sempre que sigui tècnicament possible, especialment per a administradors, accessos remots, serveis al núvol, correu electrònic, gestors de contrasenyes, sistemes financers i altres sistemes crítics. La MFA no substitueix contrasenyes fortes, però redueix l’impacte de la filtració de credencials.
\nDóna preferència a MFA resistent al phishing, com passkeys, claus de seguretat física o autenticadors de la pròpia plataforma. Els autenticadors basats en apps solen ser millors que l’SMS. La MFA basada en SMS no s’ha d’utilitzar si hi ha cap altre mètode MFA disponible, ja que els números de telèfon poden ser interceptats, víctima d’un sim swapping, portats o abusats a través de processos de recuperació de comptes.
\nAixò no és teòric. El 2018, Reddit va anunciar que atacants havien interceptat l’autenticació de dos factors basada en SMS i accedit a sistemes interns: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. El 2021, Coinbase va informar que uns atacants van robar criptomonedes a almenys 6.000 clients aprofitant credencials i una feblesa en el procés de recuperació de comptes via SMS de Coinbase: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\nLes contrasenyes s’han de canviar quan hi ha indicis o una sospita raonable de compromís. Alguns exemples són phishing, malware en el dispositiu d’un usuari, exposició de credencials arran d’una bretxa, activitat d’accés sospitosa o divulgació accidental.
\nLes contrasenyes compartides s’han d’evitar quan es poden crear comptes individuals. Si resulta inevitable compartir credencials, aquestes s’han d’emmagatzemar en un gestor de contrasenyes aprovat, l’accés s’ha de limitar a usuaris autoritzats i, quan sigui possible, s’ha de registrar qui accedeix i quan.
\nEl restabliment de contrasenyes sovint és el punt més feble en la seguretat dels comptes. Els processos de restabliment han de verificar la identitat, expirar els enllaços de restabliment ràpidament, utilitzar tokens d’un sol ús i notificar l’usuari quan la seva contrasenya ha estat canviada.
\nExigir canvis de contrasenya cada 30, 60 o 90 dies sovint resulta en contrasenyes més febles. Els usuaris acostumen a fer petits canvis previsibles, com afegir un número o canviar l’estació de l’any. Les Directrius d’Identitat Digital del NIST van eliminar el canvi periòdic rutinari i només exigeixen el canvi si hi ha indicis de compromís. Vegeu secció 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Exigeix el canvi de contrasenya després de sospita de compromís, canvi de rol, recuperació de compte, o quan la contrasenya ja no compleix la política.
\nRegles com “ha de tenir majúscula, minúscula, número i símbol” no garanteixen força. Password1! compleix moltes regles de complexitat però és extremadament dèbil. Prioritza llargada, unicitat, aleatorietat i comprovació de llistes de bretxes.
Bloquejar la funció d’enganxar dificulta l’ús dels gestors de contrasenyes. Pot fer que els usuaris es decantin per contrasenyes més curtes que sigui fàcil de teclejar. Permet enganxar i autocompletar, excepte si hi ha un motiu de seguretat específic i documentat per no permetre-ho.
\nLes pistes de contrasenya sovint revelen massa informació. Si un usuari es pot recordar de la resposta gràcies a la pista, és possible que un atacant també pugui endevinar-la. Utilitza processos de restabliment segurs en comptes de pistes.
\nEls sistemes mai no han d’emmagatzemar contrasenyes en text pla ni en xifrat reversible. Les contrasenyes s’han de guardar amb un algoritme modern de hash per a contrasenyes, lent i amb sal, com ara Argon2id, bcrypt, scrypt o PBKDF2, segons les capacitats del sistema i requisits normatius.
\nAlgoritmes de hash ràpid d’ús general com MD5, SHA-1, SHA-256 o SHA-512 no són adequats per guardar contrasenyes pel seu compte. Són ràpids, la qual cosa facilita atacs per força bruta si la base de dades es filtra. Per més informació, consulta el nostre article sobre l’evolució del hash de contrasenyes.
\nNo s’han d’enviar contrasenyes per correu electrònic, xat, tiquets, documents ni captures de pantalla. Fes servir un gestor de contrasenyes amb opcions segures de compartició i control d’accés.
\nLes contrasenyes no han de contenir noms, dates de naixement, noms d’empresa, patrons de teclat, caràcters repetits ni substitucions habituals com @ per a i 0 per o. Els atacants proven aquests patrons d’entrada.
Utilitza requeriments fàcils d’entendre:
\nEls comptes d’administrador, comptes de servei i accés a producció requereixen controls més estrictes. Demana contrasenyes més fortes, MFA, accés limitat, monitorització i rotació immediata quan hi ha canvis d’accés.
\nNi la millor contrasenya compensa un excés de permisos. Els usuaris només han de tenir accés als sistemes i secrets estrictament necessaris per la seva feina.
\nDetecta patrons d’accés inusuals, viatges impossibles, intents repetits fallits, intents d’accés des de països nous i accessos fora dels horaris habituals. La política de contrasenyes ha d’anar acompanyada de monitoratge i resposta a incidents.
\nLa formació hauria de centrar-se en reutilització de contrasenyes, phishing, pàgines falses d’inici de sessió, fatiga MFA, compartició segura i com reportar sospites de compromís. Evita culpabilitzar els usuaris. Fes fàcil el comportament segur.
\nUna política de contrasenyes ha de ser entenedora. Si la política és massa llarga, ambigua o estricta, la gent buscarà maneres d’evitar-la. La millor política és la que pot complir-se i aplicar-se realment.
\nUtilitza la següent plantilla com a punt de partida. Adapta els apartats entre claudàtors per ajustar-los a la teva organització, sistemes, nivell de risc i requeriments legals.
\nPolítica de contrasenyes\n\nVersió: [1.0]\nResponsable: [Departament de Seguretat / TI]\nData d’entrada en vigor: [AAAA-MM-DD]\nCicle de revisió: [Cada 12 mesos]\n\n1. Propòsit\n\nAquesta política defineix els requisits per a la creació, ús, emmagatzematge, compartició i canvi de contrasenyes de [Nom de l’Organització]. L’objectiu és reduir el risc d’accés no autoritzat, robatori de credencials, ús fraudulent de comptes i pèrdua de dades.\n\n2. Abast\n\nAquesta política s’aplica a tots els empleats, contractistes, personal temporal, proveïdors de serveis i qualsevol altre usuari que accedeixi a sistemes, aplicacions, xarxes, serveis al núvol o dades de [Nom de l’Organització].\n\nLa política s’aplica a comptes d’usuari estàndard, comptes privilegiats, comptes de servei, comptes compartits i a qualsevol sistema on s’utilitzin contrasenyes per a l’autenticació.\n\n3. Requisits de creació de contrasenyes\n\nTotes les contrasenyes han de complir els requisits següents:\n\n- Els comptes d’usuaris humans han d’utilitzar contrasenyes de com a mínim 16 caràcters.\n- Les contrasenyes han de ser úniques i no poden reutilitzar-se entre comptes laborals o personals.\n- Les contrasenyes no poden contenir noms, noms d’usuari, noms d’empresa, dates de naixement, patrons de teclat, caràcters repetits o altra informació fàcilment endevinable.\n- No poden basar-se en frases conegudes, cites, lletres de cançons o substitucions previsibles.\n- Les contrasenyes no poden aparèixer a llistes conegudes de contrasenyes filtrades ni a llistes habituals.\n- Es poden incloure espais, símbols, números, lletres majúscules i minúscules.\n- S’admeten frases de pas sempre que siguin llargues, úniques i no basades en frases públiques o previsibles.\n\n4. Gestors de contrasenyes\n\n[Nom de l’Organització] exigeix o recomana fortament l’ús d’un gestor de contrasenyes aprovat per crear, guardar i compartir contrasenyes.\n\nEls usuaris poden utilitzar el generador de contrasenyes, l’autocompletat i la còpia-enganxat des del gestor aprovat. No s’han de guardar contrasenyes en navegadors, fulls de càlcul, documents, aplicacions de notes, correu electrònic, xats, captures de pantalla o eines no aprovades.\n\n5. Autenticació multifactor\n\nL’autenticació multifactor ha d’estar habilitada allà on sigui tècnicament possible, incloent però no limitant a:\n\n- Comptes de correu electrònic\n- Sistemes d’accés remot\n- Comptes de gestor de contrasenyes\n- Serveis al núvol\n- Comptes administratius\n- Sistemes financers, RRHH i altres crítics\n- Qualsevol sistema classificat com a [confidencial / crític]\n\nQuan sigui possible, cal utilitzar MFA resistent a phishing, com passkeys, claus de seguretat física o autenticadors de plataforma. Les aplicacions d’autenticació són preferibles a SMS. L’ús de MFA per SMS està prohibit si hi ha un altre mètode MFA tècnicament possible i només es pot fer servir quan no n’hi ha cap d’alternatiu més segur.\n\n6. Canvi de contrasenyes\n\nLes contrasenyes s’han de canviar immediatament si:\n\n- Es sap o es sospita que la contrasenya està compromesa.\n- L’usuari ha introduït la contrasenya en una pàgina sospitosa de phishing.\n- La contrasenya s’ha compartit amb una persona no autoritzada.\n- Es detecta malware o accés no autoritzat al dispositiu de l’usuari.\n- La contrasenya apareix en una bretxa de dades coneguda.\n- L’usuari privilegiat canvia de rol o de feina.\n- TI o Seguretat ho indiquen expressament.\n\nNo és necessari posar data de caducitat rutinària (expiració) a menys que la llei, regulació, contracte o limitació del sistema ho exigeixin. Les contrasenyes no s’han de canviar fent modificacions petites i previsibles respecte a l’anterior.\n\n7. Compartició de contrasenyes\n\nNo es poden compartir contrasenyes per email, xat, tiquets, documents, captures de pantalla, trucades telefòniques ni verbalment.\n\nNomés s’admeten credencials compartides quan no és tècnicament possible tenir comptes individuals o quan Seguretat / TI ho aprova expressament. Les credencials compartides aprovades s’han de guardar i compartir a través del gestor aprovat i amb accés limitat a usuaris autoritzats.\n\n8. Comptes privilegiats\n\nEls comptes privilegiats han d’utilitzar contrasenyes úniques i diferents de qualsevol compte d’usuari estàndard. Han de tenir MFA allà on sigui tècnicament possible i s’han de revisar regularment.\n\nS’han de canviar les contrasenyes privilegiades quan marxa un administrador, canvia de rol, ja no necessita accés o quan hi ha sospita de compromís.\n\n9. Comptes de servei i secrets d’aplicació\n\nLes contrasenyes de comptes de servei, claus API, tokens i secrets d’aplicació han de ser guardats en un sistema aprovat de gestió de secrets o gestor de contrasenyes.\n\nLes credencials de comptes de servei no poden estar incrustades al codi font, fitxers de configuració, imatges, documentació o scripts sense una gestió de secrets aprovada.\n\n10. Restabliment de contrasenya i recuperació de comptes\n\nEls processos de restabliment de contrasenya han de verificar la identitat de l’usuari abans de restablir l’accés. Els enllaços de restabliment i contrasenyes temporals han de ser d’un sol ús, caducar ràpidament i transmetre’s només pels canals aprovats.\n\nEls usuaris han de rebre notificació quan canvien o restableixen la contrasenya. Les contrasenyes temporals han de ser canviades en el primer inici de sessió.\n\n11. Controls tècnics\n\nEls sistemes que emmagatzemen o processen contrasenyes han de:\n\n- No emmagatzemar mai contrasenyes en text clar.\n- Guardar contrasenyes amb un algoritme de hash modern, salat: PBKDF2, scrypt, bcrypt o Argon2.\n- No fer servir MD5, SHA-1, SHA-256, SHA-512 ni altres hash ràpids d’ús general per guardar contrasenyes pel seu compte.\n- Protegir els punts d’accés d’autenticació amb limitació de ràtio o altres controls equivalents.\n- Rebutjar contrasenyes habituals, febles o compromeses conegudes.\n- Permetre enganxar contrasenyes des de gestors de contrasenyes.\n- Acceptar contrasenyes raonablement llargues, com a mínim 64 caràcters si és possible tècnicament.\n- Registrar esdeveniments d’autenticació rellevants per a la seguretat.\n\n12. Notificació de sospita de compromís\n\nEls usuaris han de notificar immediatament a [contacte Seguretat / TI] qualsevol sospita de compromís, phishing, missatges d’inici de sessió inusuals, peticions MFA inesperades o divulgació accidental de contrasenyes.\n\n13. Excepcions\n\nLes excepcions a aquesta política s’han de documentar, avaluar el risc, tenir una durada limitada i aprovar-se per la direcció de Seguretat / TI. Calen controls compensatoris si és possible.\n\n14. Aplicació i sancions\n\nEl no compliment d’aquesta política pot comportar retirada d’accés, formació obligatòria, mesures disciplinàries o altres accions d’acord amb les polítiques i lleis aplicables de [Nom de l’Organització].\n\n15. Revisió\n\nAquesta política s’ha de revisar com a mínim un cop a l’any o després de canvis importants als sistemes, amenaces, requisits legals o operacions del negoci.\nUna bona política de contrasenyes no consisteix a fer la vida difícil als usuaris. Consisteix a eliminar mals hàbits, facilitar gestors de contrasenyes, usar MFA i respondre ràpidament quan es produeix una exposició de credencials. Mantingues la política pràctica, aplicable i enfocada en atacs del món real com el phishing, credential stuffing, reutilització de contrasenyes i comptes compromesos.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Política de contrasenyes: què s’ha de fer, què no, bones pràctiques i una plantilla per copiar","description":"Descobreix què ha d’exigir una política de contrasenyes moderna, quines normes antigues cal evitar i copia una plantilla pràctica per a la teva organització.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"ca","langPathPrefix":"/ca"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}