Data Recovery Case File · Trust, Practice & Honest Limits · Two Different Kinds of Lock
An Application Login Is Not the Same Thing as Encryption
This enquiry concerns a business record that outlived the machine holding it. A staff database on a standalone computer that has crashed, where the software can be reinstalled elsewhere but the old information cannot be reached — and "it was also password protected but we don't actually have the password any more." The answer depends on which kind of protection that was, and the two are frequently confused.
| Media | Internal drive of a standalone office computer — holding a business application database with an application-level access password not retained |
| Reported situation | Business application holding staff records in a local database · database held on a standalone computer · computer having crashed · application reinstallable on replacement hardware · existing records not retrievable · application password protection in place · password no longer held by the organisation |
| Fault class | Host failure with stored database files potentially intact — access control at application level distinct from encryption of stored content; disposition determined by which applies |
| Equipment used | Application-level access control distinguished from encryption of stored data · drive removed and read independently of the machine · imaged write-blocked before any interpretation · database files located and examined for encryption at rest · files delivered for import into a fresh installation where content proved unencrypted |
The decode: which kind of lock it is, and why that decides everything
What the first kind does: controls who may use the program. The application asks for a password before opening its interface, and refuses if it is wrong — but the data files sit on the disk in an ordinary readable form.
Why that kind is not an obstacle to recovery: the check happens inside the software. The files themselves are readable by anything that can open a file, so the database can be recovered from the drive and imported into a fresh installation.
What the second kind does instead: encrypts the stored content. The password derives a key, and without it the files are unreadable regardless of what reads them — the protection is in the data rather than in the program.
Why that kind is a genuine obstacle: there is no way past it, and we would not attempt one. Encrypted content without its key is not a hard problem but an impossible one, and any service claiming otherwise should be treated with caution.
Why the distinction is so often blurred: both present to the user as a password prompt. Nothing in the experience of being asked for a password indicates which is happening, which is why the answer here cannot be given before the files are examined.
How it is established: by looking at the database files themselves. Unencrypted records contain recognisable structure — field names, readable text, consistent formatting — while encrypted files are high-variability data with no pattern, and a few minutes of examination settles it.
Why this is legitimate work in either case: the organisation owns the machine, the software licence and the records. What is being recovered is their own data from their own hardware — and where content proves encrypted, the answer is simply that it cannot be recovered.
Why the machine crashing is the smaller problem: a computer that will not start is a host fault. The drive comes out and reads independently, so whether the machine can be repaired has no bearing on whether the database can be reached.
What is worth checking alongside: whether the software vendor offers a supported route for an organisation that has lost its own access credential. Many business applications have an administrative process for exactly this, and it is the proper first avenue.
What should follow regardless: a record of where the database lives and how it is backed up. A single standalone machine holding the only copy of a staff record is the arrangement that produced this, and it is worth changing.
On the bench
Application-level access control was distinguished from encryption of stored data — the first checking a credential within the software while leaving data files in ordinary readable form on disk, the second deriving a key from the password so that files are unreadable regardless of what opens them, with both presenting identically to the user as a password prompt. The distinction is established by examining the files: unencrypted records carry recognisable structure and readable text, encrypted files high-variability data without pattern.
The outcome
Access control distinguished from encryption, the drive read independently of the machine, and the database files examined for encryption at rest. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: it depends which kind of password it was. A login that guards the program leaves the files readable; one that encrypts the content does not, and in that case there is no route past it.
A business database behind a password nobody kept
Approach the software vendor first, since many business applications have an administrative process for an organisation that has lost its own credential — that's the proper avenue. Meanwhile understand that two quite different things present as a password prompt. A login that controls who may open the program leaves the data files on disk in ordinary readable form, so they can be recovered and imported into a fresh installation. A password that encrypts the stored content derives a key, and without it there is no route past it for anyone. Examining the files settles which you have.
Ask the vendor first — call Manchester Data Recovery on 0161 871 0788; access control distinguished from encryption of stored data, drive read independently, files examined for encryption at rest.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.