Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Security’ Category

(2019-11-21) Active Directory Security Scan Of Accounts (Part 5)

Posted by Jorge on 2019-11-21


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Account And Password Hygiene” related information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • Enabled (e.g. TRUE or FALSE)
  • Pwd Last Set On (e.g. <date/time> or "Must Chng At Next Logon")
  • Has Adm Count Stamp (e.g. TRUE or FALSE)
  • Delegatable Adm (e.g. TRUE or FALSE)
  • Does Not Req Pre-AuthN (e.g. TRUE or FALSE)
  • Has Sid History (e.g. TRUE or FALSE)
  • Has LM Hash (e.g. TRUE or FALSE)
  • Has Default Pwd (e.g. TRUE or FALSE)
  • Has Blank Pwd (e.g. TRUE or FALSE)
  • Uses DES Keys Only (e.g. TRUE or FALSE)
  • Has Missing AES Keys (e.g. TRUE or FALSE)
  • Pwd Rev Encrypt (e.g. TRUE or FALSE)
  • Pwd Not Req (e.g. TRUE or FALSE)
  • Pwd Never Expires (e.g. TRUE or FALSE)
  • Has Shared Pwd (e.g. TRUE – Domain Shrd Pwd Grp x Of y or FALSE)
  • Compromised Pwd (e.g. TRUE or FALSE)
  • Most Used Hash (e.g. <hash> (<count>) or N.A.)

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • PowerShell Module: LithnetPasswordProtection
  • PowerShell Module: DSInternals
  • LithNet Active Directory Password Protection Store With Banned Words And/Or Compromised Passwords/Hashes
  • Enterprise Admin Permissions, or at least "Replicate Directory Changes" and "Replicate Directory Changes All" for EVERY NC in the AD forest!
    REMARK: Script does check for Enterprise Admin role permissions!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_05_Account-And-Password-Hygiene-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

image

Figure 1e: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2a: Sample Output Of The CSV File Displayed In PowerShell GridView

image

Figure 2b: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – Account And Password Hygiene

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, IT Pro Tools, Passwords, PowerShell, Replication, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-18) Active Directory Security Scan Of Accounts (Part 4)

Posted by Jorge on 2019-11-18


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Permissions At Object Level” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • Protected Group Membership (e.g. <comma separated list of group account names> or "No Memberships")
    REMARK: With protected groups, the focus is ONLY on default AD Protected Groups (e.g. BUILTIN\Administrators", "<DOMAIN>\Domain Admins", etc.)
    REMARK: if protected groups are listed then any ACEs for those protected groups are NOT listed to prevent an overload of ACEs
  • ACE On AdminSDHolder (e.g. <comma separated list of objects with configured permissions> or "No ACEs")
    REMARK: If protected groups are listed then any ACEs for those protected groups are NOT listed to prevent an overload of ACEs
    REMARK: It will only look at explicit defined ACEs. Inherited ACEs are NOT listed to prevent an overload of ACEs
  • Powerful ACEs On Objects (e.g. <comma separated list of objects with configured permissions> or "No ACEs")
    REMARK: If protected groups are listed then any ACEs for those protected groups are NOT listed to prevent an overload of ACEs
    REMARK: It will only look at explicit defined ACEs. Inherited ACEs are NOT listed to prevent an overload of ACEs

The following ACEs are considered powerful:

  • Full Control
  • Password Reset Control Access Rights
  • Control Access Right In General
  • WriteOwner (Allows to write the owner and that allows to write the DACL)
  • Write DACL
  • Write Property In General
  • Write Property For “lockoutTime” (Unlocking Account)
  • Write Property For “msDS-AllowedToDelegateTo” (Adding/removing accounts for account based delegation)
  • Write Property For “msDS-AllowedToActOnBehalfOfOtherIdentity” (Adding/removing accounts for resourced based delegation)
  • Write Property For “servicePrincipalName” (Adding/removing SPNs)
  • Write Property For “userAccountControl” (Managing security/delegation settings, enabling/disabling account)

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • Basic User Permissions, Nothing Special!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_04_Object-Level-Permissions-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – Object Level Permissions Info

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation Of Control, IT Pro Tools, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-15) Active Directory Security Scan Of Accounts (Part 3)

Posted by Jorge on 2019-11-15


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Permissions At NC Level” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • DS Repl Chng Perms (e.g. "<comma separated list of domain DNs> (<Assigned Security Principal>)" or "No Perms")
  • DS Repl Chng All Perms (e.g. "<comma separated list of domain DNs> (<Assigned Security Principal>)" or "No Perms")
  • Migr SID History Perms (e.g. "<comma separated list of domain DNs> (<Assigned Security Principal>)" or "No Perms")

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • Basic User Permissions, Nothing Special!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_03_NC-Level-Permissions-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – NC Level Permissions Info

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation Of Control, IT Pro Tools, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-12) Active Directory Security Scan Of Accounts (Part 2)

Posted by Jorge on 2019-11-12


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “Kerberos Delegation” related account information.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • Service Principal Name(s) (e.g. <comma separated list of SPNs> or "No SPNs")
  • Acc Based Deleg Type (e.g. "No-Acc-Deleg" or "Acc-Unc-Deleg" or "Acc-Con-Deleg-AnyAuthN" or "Acc-Con-Deleg-KerbAuthN"
  • Acc Based Deleg To (e.g. <comma separated list of SPNs> or "No Delegated SPNs")
  • Res Based Deleg For (e.g. <comma separated list of user account names with type and domain listed> or "No-Res-Deleg"

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • Basic User Permissions, Nothing Special!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_02_Delegation-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – Delegation Info

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, Delegation, IT Pro Tools, Kerberos AuthN, Kerberos Constrained Delegation, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-11-09) Active Directory Security Scan Of Accounts (Part 1)

Posted by Jorge on 2019-11-09


With the PoSH script made available through this blog post you can scan and check ALL accounts in the AD forest to get “basic” account information that is related to security.

Through LDAP queries, this PoSH script retrieves the following information for every account in the AD forest that is able to authenticate:

  • Domain FQDN (e.g. ‘IAMTEC.NET’)
  • Domain NBT (e.g. ‘IAMTEC’)
  • Domain DN (e.g. ‘DC=IAMTEC,DC=NET’)
  • Sam Account Name (e.g. ‘jorge’)
  • Account Name (e.g. ‘IAMTEC\jorge’)
  • Account Type (computer, inetOrgPerson, msDS-GroupManagedServiceAccount, trust (user), user)
  • User Principal Name  (e.g. ‘jorge@iamtec.nl’)
  • Display Name (e.g. Jorge de Almeida Pinto)
  • Enabled (e.g. TRUE or FALSE)
  • Locked (e.g. TRUE – At:<date/time> or FALSE – Never Locked or FALSE – Has Been Locked Before)
  • Account Expires On (e.g. <date/time> or NEVER)
  • Pwd Last Set On (e.g. <date/time> or "Must Chng At Next Logon")
  • Pwd Never Expires (e.g. TRUE or FALSE)
  • Last Logon Timestamp (e.g. <date/time> or NEVER)
  • Last Logon (RWDC) (e.g. <date/time> or NEVER Or NOT AVAILABLE (On ‘<FQDN RWDC>’)) <– THIS MEANS IT WILL QUERY EVERY DC (RWDC And RODC) In The AD Domain To Get The LastLogon Property From That DC! (Will be slow!)

When the script finishes, it produces a CSV report that contains every account in the AD forest that can authenticate (user, computer, gMSA, inetOrgPerson) and potentially be a threat, and it displays that CSV in a GridView automatically. The CSV can of course also be used in Excel if needed. With this information you may be able to remove or fix configurations and/or get an idea how things look like to mitigate risks as much as possible!

While the script is running it logs every to a log file. which is in the same folder as the script itself.

This script requires:

  • PowerShell Module: ActiveDirectory
  • Basic User Permissions, Nothing Special!

Scan/Check All Accounts In The AD Forest And Create The Report

.\Scan-And-Check-All-Accounts-In-AD-Forest_01_Basic-Info.ps1

The script has been tested in three different AD forests:

  • AD forest with a Single AD domain with less than 500 accounts and quite some account config
  • AD forest with a Single AD domain with approx. 150000 accounts and less account config
  • AD forest with Multiple AD domains (Forest Root Domain, Child Domain and Tree Root Domain) with approx. respectively 4000, 25000 and 12000 accounts and less account config

image

Figure 1a: Sample Output Of The Log File

image

Figure 1b: Sample Output Of The Log File

image

Figure 1c: Sample Output Of The Log File

image

Figure 1d: Sample Output Of The Log File

To open the CSV on another computer and display it in GridView, execute the following command:

Import-CSV <Full Path To The CSV File> | Out-Gridview

image

Figure 2: Sample Output Of The CSV File Displayed In PowerShell GridView

To get the script, see: Scan And Check All Accounts In AD Forest – Basic Info

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), AD Queries, Blog Post Series, IT Pro Tools, Last Logon Information, PowerShell, Security, Security, Tooling/Scripting | Leave a Comment »

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Posted by Jorge on 2019-08-01


Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

  • Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
  • Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
  • Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
  • Move service accounts in AD from regular service accounts to:
    • Group Managed Service Accounts if possible
    • …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
    • …and if that’s not possible keep using regular service accounts with long and unique passwords
  • If possible, increase the password length to a minimum of 15 characters for users
  • Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
  • Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
  • Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
  • Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
  • When using ADFS, implement extranet lockout policy
  • Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
  • Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
  • Decrease the use of passwords as much as possible by:
    • Implementing SSO
    • Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
    • Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

Additional Resources:

Hope this helps you!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN | Leave a Comment »

(2019-01-03) Some Phones Are Not That Good With Face Recognition

Posted by Jorge on 2019-01-03


Are you using face recognition to unlock your mobile phone?

And is that mobile phone on the following list?

It appears all the mobile phones on the list can be unlocked by using a picture instead of your face.

To be sure nobody access your personal data that easy, preferably and if possible use finger or a code to unlock the mobile phone

All the phones on the list titled “Toestellen ontgrendeld met een foto” can be easily unlocked with a photo of your face

All the phones on the list titled “Toestellen ontgrendeld met een foto, maar met betere beveiliging” can also be easily unlocked with a photo of your face but also provide more secure settings for face recognition

All the phones on the list titled “Toestellen die niet met een foto zijn te ontgrendelen” appear to be secure and face recognition is not fooled by a photo of your face.

From the dutch consumers authority:

https://www.consumentenbond.nl/veilig-internetten/gezichtsherkenning-te-hacken

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-

########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————-

Posted in Day-To-Day Stuff, Mobile Devices, Security | Leave a Comment »

 
%d bloggers like this: